Nuno Diegues 0ab6867ae5 TUN-4947: Use http when talking to Unix sockets origins
Right now the proxying of cloudflared -> unix socket is a bit of
a no man's land, where we do not have the ability to specify the
actual protocol since the user just configures "unix:/path/"

In practice, we proxy using an HTTP client.
But it could be that the origin expects HTTP or HTTPS. However,
we have no way of knowing.

So how are we proxying to it? We are configuring the http.Request
in ways that depend on the transport and edge implementation, and
it so happens that for h2mux and http2 we are using a http.Request
whose Scheme is HTTP, whereas for quic we are generating a http.Request
whose scheme is HTTPS.

Since it does not make sense to have different behaviours depending
on the transport, we are making a (hopefully temporary) change so
that proxied requests to Unix sockets are systematically HTTP.

In practice we should do https://github.com/cloudflare/cloudflared/issues/502
to make this configurable.
2022-02-02 19:33:30 +00:00
2021-11-12 17:38:06 +02:00
2021-11-12 17:38:06 +02:00
2021-11-12 17:38:06 +02:00
2021-11-12 17:38:06 +02:00
2020-07-08 14:39:28 +00:00
2021-11-12 17:38:06 +02:00
2022-01-28 15:10:37 +00:00

Cloudflare Tunnel client

Contains the command-line client for Cloudflare Tunnel, a tunneling daemon that proxies traffic from the Cloudflare network to your origins. This daemon sits between Cloudflare network and your origin (e.g. a webserver). Cloudflare attracts client requests and sends them to you via this daemon, without requiring you to poke holes on your firewall --- your origin can remain as closed as possible. Extensive documentation can be found in the Cloudflare Tunnel section of the Cloudflare Docs. All usages related with proxying to your origins are available under cloudflared tunnel help.

You can also use cloudflared to access Tunnel origins (that are protected with cloudflared tunnel) for TCP traffic at Layer 4 (i.e., not HTTP/websocket), which is relevant for use cases such as SSH, RDP, etc. Such usages are available under cloudflared access help.

You can instead use WARP client to access private origins behind Tunnels for Layer 4 traffic without requiring cloudflared access commands on the client side.

Before you get started

Before you use Cloudflare Tunnel, you'll need to complete a few steps in the Cloudflare dashboard: you need to add a website to your Cloudflare account. Note that today it is possible to use Tunnel without a website (e.g. for private routing), but for legacy reasons this requirement is still necessary:

  1. Add a website to Cloudflare
  2. Change your domain nameservers to Cloudflare

Installing cloudflared

Downloads are available as standalone binaries, a Docker image, and Debian, RPM, and Homebrew packages. You can also find releases here on the cloudflared GitHub repository.

User documentation for Cloudflare Tunnel can be found at https://developers.cloudflare.com/cloudflare-one/connections/connect-apps

Creating Tunnels and routing traffic

Once installed, you can authenticate cloudflared into your Cloudflare account and begin creating Tunnels to serve traffic to your origins.

TryCloudflare

Want to test Cloudflare Tunnel before adding a website to Cloudflare? You can do so with TryCloudflare using the documentation available here.

Deprecated versions

Cloudflare currently supports versions of cloudflared 2020.5.1 and later. Breaking changes unrelated to feature availability may be introduced that will impact versions released prior to 2020.5.1. You can read more about upgrading cloudflared in our developer documentation.

Version(s) Deprecation status
2020.5.1 and later Supported
Versions prior to 2020.5.1 No longer supported
Description
Cloudflare Tunnel client (formerly Argo Tunnel)
Readme 40 MiB
Languages
Go 90.9%
Python 7.6%
Cap'n Proto 0.6%
Makefile 0.5%
Shell 0.3%
Other 0.1%