when crafting an ingress YAML file by hand its easy to write the following by mistake:
```yaml
ingress:
- hostname: https://example.com
service: http://localhost:50100
- service: http_status:404
```
`cloudflared` would report the error: `Hostname cannot contain a port`
this confused me for a few minutes before i compared two configs and saw my mistake. this change introduces a check prior to port splitting to see if the hostname contains a protocol and reports a relevant error
We take advantage of the JWTValidator middleware and attach it to an
ingress rule based on Access configurations. We attach the Validator
directly to the ingress rules because we want to take advantage of
caching and token revert/handling that comes with go-oidc.
This reverts commit d4d9a43dd7.
We revert this change because the value this configuration addition
brings is small (it only stops an explicit cyclic configuration versus
not accounting for local hosts and ip based cycles amongst other things)
whilst the potential inconvenience it may cause is high (for example,
someone had a cyclic configuration as an ingress rule that they weren't
even using).
It is currently possible to set cloudflared to proxy to the hostname
that traffic is ingressing from as an origin service. This change checks
for this configuration error and prompts a change.
For WARP routing the defaults for these new settings are 5 seconds for connect timeout and 30 seconds for keep-alive timeout. These values can be configured either remotely or locally. Local config lives under "warp-routing" section in config.yaml.
For websocket-based proxy, the defaults come from originConfig settings (either global or per-service) and use the same defaults as HTTP proxying.
This change extracts the need for EstablishConnection to know about a
request's entire context. It also removes the concern of populating the
http.Response from EstablishConnection's responsibilities.
To use cloudflared as a socks proxy, add an ingress on the server
side with your desired rules. Rules are matched in the order they
are added. If there are no rules, it is an implicit allow. If
there are rules, but no rule matches match, the connection is denied.
ingress:
- hostname: socks.example.com
service: socks-proxy
originRequest:
ipRules:
- prefix: 1.1.1.1/24
ports: [80, 443]
allow: true
- prefix: 0.0.0.0/0
allow: false
On the client, run using tcp mode:
cloudflared access tcp --hostname socks.example.com --url 127.0.0.1:8080
Set your socks proxy as 127.0.0.1:8080 and you will now be proxying
all connections to the remote machine.
- Move packages the provide generic functionality (such as config) from `cmd` subtree to top level.
- Remove all dependencies on `cmd` subtree from top level packages.
- Consolidate all code dealing with token generation and transfer to a single cohesive package.
added ingress.DefaultStreamHandler and a basic test for tcp stream proxy
moved websocket.Stream to ingress
cloudflared no longer picks tcpstream host from header
- extracted ResponseWriter from proxyConnection
- added bastion tests over websocket
- removed HTTPResp()
- added some docstrings
- Renamed some ingress clients as proxies
- renamed instances of client to proxy in connection and origin
- Stream no longer takes a context and logger.Service
andrew
João "Pisco" Fernandes
Devin Carr
Sudarsan Reddy
João Oliveirinha
Igor Postelnik
cthuang
Adam Chalmers
Lee Valentine
Areg Harutyunyan