Allow configuration of port for tsnet to facilitate direct connections when run in containers

[chrishoage]

I am having much difficulty making consistent direct connections to services hosted from a caddy-tailscale docker container which reside only on my tailnet.

Other containers which use tailscaled directly allow me to specify a port which I can expose and allow direct connections when running in userspace mode inside a docker container.

My proposal is allowing the configuration of the Port field in tsnet to allow for these udp ports to be exposed to the internet to facilitate direct connections to these tsnet nodes on the tailnet. Since the ports are otherwise randomized it doesn't seem feasible to know what ports to expose.

https://github.com/tailscale/tailscale/blob/ff095606ccff083160eb01a8a4cc062cacfe1a33/tsnet/tsnet.go#L119-L122

The simplest solution is to add an additional field for the <node_name> conflagration option

e.g.

{
  tailscale {
    my_node {
      port 41647
    }
  }
}

However, allowing for a range in the global config would make it much easier to expose the range via docker

{
  tailscale {
    port_range "41642-41649"
  }
}

If the range is exhausted while building the config struct this is an error.

I have done a decent amount of experimenting with my tailnet and my conclusion this is an issue unique to caddy-tailscale (or tsnet more specially) when run inside a docker container and not on the host directly. Running the container in "host" network mode is not an option as then I lose out on docker networking (e.g. a docker proxy network, etc)

If there is something I'm missing with ensuring direct connections to nodes hosted via caddy-tailscale please feel free to close this issue (and perhaps let me know what I am missing)

[chrishoage]

I have made a commit which implements this chrishoage@a26a499

{
{
  tailscale {
    auth_key {$TS_AUTHKEY}
    ephemeral false
    state_dir /data/tailscale
    port_range {
      start 41650
      end 41655
    }
    node-name {
      port 41665
    }
  }
}

I added tests, but I'm not an experienced go developer so I'm unsure if the quality is good enough for a pull request. Let me know if I should upstream this!

it can be built with

xcaddy build v2.8.4 --with github.com/tailscale/caddy-tailscale=github.com/chrishoage/caddy-tailscale@a26a499346f839f321f78b643a87c501f1ca3b49

[willnorris]

Passing through tsnet's Port option makes sense, and I'm happy to do that. Feel free to open a PR with that change, or I can handle it myself... either way.

I'm not quite as clear on how the port range would be used. If you're mapping ports from the host into the container, don't you already know the port ahead of time in order to setup that mapping? Or is it in an env variable that you could pass into the caddy config?

[chrishoage]

Feel free to open a PR with that change, or I can handle it myself... either way.

I will open a PR soon - probably this weekend!

I'm not quite as clear on how the port range would be used. If you're mapping ports from the host into the container, don't you already know the port ahead of time in order to setup that mapping? Or is it in an env variable that you could pass into the caddy config?

I'm going to be honest - it's mostly "lazyness"

The idea is you dedicate a range of ports in your Caddyfile, then you set up docker to expose the same range of ports.

Now I can add and remove bind tailscale/my-node interface bindings to (mostly, depending on the size of the range you dedicated) your hearts content with out having to go and update the exposed ports.

If you feel this is not valuable I can remove it from the PR before I open it. I personally exposed 4 different nodes in a single caddyfile and I didn't want to have to think too hard about what node got what port. I just wanted it to pick from the bucket I gave it.

Anyway as mentioned, it's not critical to have and happy to remove it before up-streaming the changes.

[willnorris]

Let's start with the single Port option, since that is a really clean mapping to the options tsnet already exposes. We can always add a range later if needed.