tailscale / caddy-tailscale

A highly experimental exploration of integrating Tailscale and Caddy.
Apache License 2.0
392 stars 40 forks source link

Add funnel support #26

Open AstraLuma opened 9 months ago

AstraLuma commented 9 months ago

Allow the use of funnel to be specified per-binding in the Caddyfile.

kernelb00t commented 9 months ago

Yes, this is very useful, consider this use case:

How can you get vaultwarden AND docuseal to the web, without opening ports? With the default limitations with the tailscale CLI, you will have only 3 ports available, and your address name will look like server1.net-work.ts.net:8080. This does not look professional to people who don't knows Tailscale, and will be reticent to click on the link. For Bitwarden this is less an issue, because that's your passwords and not others, but for DocuSeal, people will just think this guy want to send me a malware. This would allow more stability and containerize more of the parts of software that touches Internet, to limit threats in case of an hypothetical breach in Tailscale's CLI and daemon, even if very unlikely.

This is also very practical, to allow versioning of configs (not as simple as removing/re-adding funnel and serve configs).

willnorris commented 4 months ago

Just leaving myself some notes on this....

This should be doable by using tsnet.ListenFunnel. One challenge we'll run into is that ListenFunnel always returns a tls listener. For caddy, we don't want that because caddy is handling the TLS connection. From the funnel node's perspective it should look the same, but we need to instruct tsnet to not wrap the listener in a tls listener. We can probably just define a new FunnelOption that says that the TLS connection is happening elsewhere and to not wrap the listener.