mijolabs / tailscale-caddy-docker

Secure access to Vaultwarden and other self-hosted containerized services with Tailscale and Caddy.
8 stars 0 forks source link

Is the public DNS part of this even necessary? #1

Closed the-arkhive closed 6 months ago

the-arkhive commented 6 months ago

Why is is necessary to go through the whole business with Cloudflare DNS? Couldn't I simply handle all of that with my local DNS?

This is the closest I've found to the setup I want, but falls just short by including any use of public DNS. Tailscale is handling all the interdevice connectivity, why do I need to configure anything that is public facing?

Currently I can access my web servers with their ports over HTTP

tailscaleDeviceName:####

This works okay, but I would like to clean up the experience.

Ideally I would like to be able to visit

service.tailscaleDeviceName

By my understanding this is where the reverse proxy comes in, sorting out all the ports I have servers running on, and giving them proper subdomains. If I wanted I could then use my PiHole for local DNS to turn that URL into whatever I want.

I feel like I am misunderstanding something, but at the same time what I want sounds so feasible.

Sorry this isn't a super clear question, your setup is just the closest I've come to what I'd like mine to looks like.

mijolabs commented 6 months ago

Hi,

I have set up public DNS to enable Caddy to manage the TLS certificate(s). As my device is only accessible via Tailscale and my LAN, a HTTP-01 challenge wouldn't be able to reach the device so we need to use the DNS-01 challenge instead. This method requires the DNS to be public.

Also, having the DNS public allows me to reach my domain from any Tailscale-authenticated device, from anywhere (e.g. my laptop when I'm at the coffee shop, or from my phone when I'm visiting my parents). I suppose I could edit the hosts file on each and every device I use (not sure if that's even possible on my phone), but that would be tedious. I have however configured my LAN router to point my domain directly to the LAN IP of my device, so when I'm at home all my devices bypass the Tailscale requirement.

A self-signed certificate may be sufficient for your use case. I'm pretty sure Caddy supports management of those, too. Just be aware of the disadvantages of self-signed certs. Another option to look into, which I haven't tried yet, could be Tailscale's MagicDNS in combination with the automatic HTTPS feature. I believe you'd have to use a *.ts.net domain though, and it probably doesn't support wildcard domains either.

the-arkhive commented 6 months ago

Thanks for the info. I think for simplicity's sake I'll move forward with cloudflare DNS as I already have a domain with them. Long term I might look into stripping that out though. Either way I am running into an issue trying to build the caddy image.

Following the instruction exactly from your post results in this error.

=> ERROR [docker-proxy builder 2/2] RUN xcaddy build     --with   0.3s
------
> [docker-proxy builder 2/2] RUN xcaddy build     --with github.com/lucaslorentz/caddy-docker-proxy/v2     --with github.com/caddy-dns/cloudflare:
0.218 exec /bin/sh: exec format error
------
failed to solve: process "/bin/sh -c xcaddy build     --with github.com/lucaslorentz/caddy-docker-proxy/v2     --with github.com/caddy-dns/cloudflare" did not complete successfully: exit code: 1

I'm happy to move this into a different issue if you'd like to track this error outside of my question about DNS

EDIT: I'm assuming it's because I don't have an API token entered, but I'm also unclear on exactly where that token needs to come from. In my cloudflare account I get find the "Get your API token" in the overview page for my domain, but clicking on it prompts me to select the type of token I need to make. Am I intended to just use my global API key? If so the error from above persists even after entering my global API key into the .env file.

mijolabs commented 6 months ago

Hi,

You'll need the API token configured for the DNS-01 challenge flow to get a certificate issued, but it isn't needed at this point when building the image.

I think the issue may be due to building the image for a different architecture than you are using. The Dockerfile specifies --platform=linux/arm64/v8, so if you're on something else you have to specify that instead. You can Google for what to use for your platform, or you may even be able to simply omit that whole argument and it might auto-detect your platform for you.