Tailscale - Deploying with Docker and Portainer

README.md

Just thought I'd put together some detail on deploying Tailscale using Docker and Portainer. These bits-and-pieces are available elsewhere, but not together, so hopefully this will save someone a bit of time if you'd like to add Tailscale to an existing Docker install:

Here's my annotated recommended docker-compose, to use with Portainer-Stacks. Note that I'm not using a pre-made Auth Key. I started that way, but realized it was very easy to simply check the Portainer log for the tailscaled container once the stack is running. In that log you'll see the standard Auth link that you can use to authorize the container. This way you don't need to create a key in advance, or create a reusable key that introduces a security risk:

version: '3.9'
services:
  tailscale:
    image: tailscale/tailscale
    container_name: tailscaled
    cap_add:
      - NET_ADMIN
      - NET_RAW
    environment:
#      - TS_HOSTNAME=${TS_HOSTNAME} # Usually not necessary for your hostname to be the same name on the tailscale network
#      - TS_AUTHKEY=${TS_AUTHKEY} # Generate auth keys here: https://login.tailscale.com/admin/settings/keys
#      - TS_ROUTES=${TS_ROUTES} # Creates a subnet router for Tailscale. Use your subnet's CIDR in the form: 192.168.1.0/24
#      - TS_ACCEPT_DNS=${TS_ACCEPT_DNS} # Set to false for Pi-hole Docker setups
      - TS_SOCKET=${TS_SOCKET} # Specifying the /var/lib/tailscale/tailscaled.sock location allows use of standard Tailscale commands 
      - TS_EXTRA_ARGS=${TS_EXTRA_ARGS} # Add any other supported arguments in the docker commandline style: e.g. --advertise-exit-node
      - TS_STATE_DIR=${TS_STATE_DIR} # Required to create a persistent container state that will survive reboots
    volumes:
      - /data:/var/lib # Creates a tailscale directory under /data for persistence
      - /dev/net/tun:/dev/net/tun
    network_mode: host
    restart: unless-stopped

These are the minimum environment variables you'll want to define in the Portainer-Environment section:

TS_SOCKET=/var/run/tailscale/tailscaled.sock
TS_EXTRA_ARGS=--accept-routes
TS_STATE_DIR=/var/lib/tailscale

With these variables, you'll be able to exec into the container to run commands like "tailscale version" and "tailscale status". Your container will accept routes advertised by a designated node, and your setup (including authorization) will persist across reboots.

It seems that it works one way only. tailscale devices >>> server but no server >>> tailscale devices

Makes sense, as Docker containers can't modify resolv.conf on the host. If you want that capability as well, you'd likely need to install Tailscale directly on the host. I've done that in at least one instance where I needed access from inside a container, to a remote device that could only be reached via my Tailnet. But, at least in my case, having access to my servers via my Tailnet and the servers being able access whatever resources they need via my LAN has worked well.

Ok understood, then I guess docker is not a good solution for me, I have to be able to access other devices from the tailscale host. Thanks anyway. I thought I could install tailscale via docker instead of normal way and have bidirectional connection but I see it is not possible.

Basically I wanted to install tailscale with docker in a NAS and being able to communicate from and to it.

@kraizelburg les say your LAN is 192.168.1.0/24 When you install tailscale on your nas, regardless of vendor nas, in your compose file you would set - TS_ROUTES=192.168.1.0/24.
Now lets pretend your NAS LAN IP is 192.168.1.100.

Now if your in the coffee shop or on your phone or somewhere that is not the 192.168.1.0/24 network, and you have tailscale installed and --accept-routes set, than you can just go to http://192.168.1.100 as if it was on your network.

Under the hood the tailscale client on your device does a lookup on the tailscale network and sees that its allowed to forward 192.168.1.0/24 traffic to the instance installed on your nas.

That instance ALREADY has access to the nas, and simply redirects the traffic to http://192.168.1.100. This will work for any device on your LAN now. Unless the individual device is blocking traffic, etc.

This works flawlessly.

Heads up... Recent updates to containerd require moving the TUN mapping over to devices...

    volumes:
      - /data:/var/lib
    devices:  
     - /dev/net/tun:/dev/net/tun