Latest / Linux Server Admin with Fexingo: Sysadmin, Bash, and Server Engineering / How to Use Linux Server Remote Access with Tailscale
Transcript
- Lucas: Let me start with a problem I ran into last week. I have a small Linux server at a colo facility — runs some monitoring, a few databases, nothing huge — and I needed to SSH in from a coffee shop on a guest Wi-Fi network that blocked pretty much every port except 80 and 443. Luna: So your standard OpenVPN or WireGuard setup on port 1194 was dead on arrival. Lucas: Exactly. I couldn't change the firewall on the coffee shop router, and I didn't want to expose SSH to the open internet, even with key auth. That's when I finally tried Tailscale seriously. And I have to say — it solved the problem in about ten minutes. Luna: Tailscale is that mesh VPN built on top of WireGuard, right? I've seen it pop up more and more for server access, but I haven't used it in production. Lucas: That's the one. It creates a WireGuard tunnel, but handles the key exchange and NAT traversal through a coordination server. You install their agent on every machine — your laptop, your server — and they get a private IP on a shared overlay network. It works over UDP, but if UDP is blocked, it falls back to DERP relays over HTTPS, which is why it worked on that coffee shop Wi-Fi. Luna: So the coffee shop blocked UDP entirely, but Tailscale just routed through their relay servers over TCP 443. Lucas: Exactly. The relay adds a bit of latency — maybe twenty to fifty milliseconds — but for an SSH session you don't notice it. And once you're in, you can SSH to the server's Tailscale IP, which is a 100.x.x.x address, not exposed to the public internet at all. Luna: That's the part I like — no open ports on the server's firewall. The server only connects outbound to Tailscale's coordination server, so there's no inbound listening port to attack. Lucas: Right. That's a huge security improvement over traditional VPNs. With OpenVPN, you're listening on a port, and even if it's hardened, it's still an attack surface. With Tailscale, the server initiates an outbound connection to Tailscale's coordination server, and then the tunnel is established. There's no open port to scan. Luna: Does that mean you can't use it if the server is behind a firewall that blocks all outbound traffic except on specific ports? Lucas: It needs outbound HTTPS access to coordinate.tailscale.com and a few other endpoints. If your server is in a locked-down environment that only allows outbound on, say, port 80 and 443, you're fine — Tailscale uses HTTPS for coordination and can relay over 443. But if outbound access is completely blocked, then you'd need a different solution. Luna: What about the setup? Is it as simple as running a curl command and a systemd service? Lucas: Pretty much. On Ubuntu 24.04, I did curl -fsSL https://tailscale.com/install.sh | sh, then sudo tailscale up. That opens a browser window for authentication through Google, Microsoft, GitHub, or whatever identity provider you link. Once you authenticate, your server appears in your Tailscale admin console. You can then SSH to it using the hostname or the Tailscale IP. Luna: And you don't need to manage any keys yourself. Tailscale handles the WireGuard key exchange through that coordination server. Lucas: Yes. And because it's built on WireGuard, the actual encryption is solid — it's using the Noise protocol framework, same as modern WireGuard. The coordination server can't decrypt your traffic because it never has access to your private keys. The keys are generated on each device and only the public keys are sent to the coordinator. Luna: That's the zero-knowledge claim, right? Tailscale's servers can see which devices are talking to which, but not the contents of the traffic. Lucas: Exactly. The metadata — source, destination, timestamps — is visible to Tailscale, but the payload is encrypted end to end with WireGuard. If you're really paranoid, you can even self-host the coordination server with Headscale, which is an open-source implementation of the Tailscale control server. Luna: Let's talk about a practical server use case. Say you have a server running at a remote data center, and you want to access not just the server itself, but also services on its local network — like a printer or a NAS that doesn't have Tailscale installed. Lucas: That's where subnet routing comes in. You can advertise routes from your server to the Tailscale network. For example, if your server is on a local subnet 192.168.1.0/24, you run tailscale up --advertise-routes=192.168.1.0/24. Then in the admin console, you approve those routes. Now any device on your Tailscale network can reach 192.168.1.x through the server as a gateway. Luna: That's powerful. So you don't need to install the Tailscale agent on every single device on that subnet — just one server acts as a router. Lucas: Right. But there's a security consideration. You need to make sure you trust all the devices on your Tailscale network, because they'll have access to those subnets. You can use ACLs — access control lists — in the admin console to restrict which Tailscale users or devices can reach those routes. The ACLs are defined in a json like policy file, which is something you'd want to learn if you're running this for a team. Luna: So you can say, only the sysadmin group can access the subnet routes, but all users can SSH to the server itself. Lucas: Exactly. ACLs are a big differentiator from a simple WireGuard setup. With plain WireGuard, you have to manage allowed IPs in each config file, and it gets messy with more than a few peers. Tailscale gives you a central policy that's easier to audit and modify. Luna: What about exit nodes? That's another feature I've seen — routing all your internet traffic through a specific node. Lucas: That's useful if you want to appear as if you're browsing from the server's location. For a sysadmin, it can be handy for testing — you can route traffic through a server in a different region to see how a web app behaves. Or if you're on a public Wi-Fi and want all your traffic to go through your home server. To set it up, you run tailscale up --advertise exit node on the server, then approve it in the admin console. On your client, you can then select that exit node in the Tailscale client. Luna: One thing that's often overlooked is MagicDNS. Can you explain that? Lucas: Sure. By default, each device on your Tailscale network gets a 100.x.x.x IP. MagicDNS gives each device a hostname like 'myserver.tailnet-name.ts.net' that resolves to that IP. So instead of remembering 100.124.35.12, you can just SSH to myserver. It's a small thing, but it makes a big difference when you have dozens of servers. Luna: And you can also set custom DNS names if you run your own DNS server. Lucas: Yes, you can integrate Tailscale with a split DNS setup. For example, you can make your internal domain, like 'internal.example.com', resolve to Tailscale IPs only when you're connected to the Tailscale network. That's a bit more advanced, but it's documented well. Luna: Let's talk about pricing. Tailscale is free for up to three users and up to a hundred devices, right? Lucas: Correct. For a small team or a homelab, that's plenty. The free plan includes all the features we discussed — subnet routing, exit nodes, ACLs, MagicDNS. The paid plans add things like multi-user accounts, group sync from identity providers, and device approval workflows. For most server admin use cases, the free tier is sufficient until you scale beyond three human users. Luna: What about performance? I've heard that Tailscale can add a bit of overhead compared to direct WireGuard. Lucas: The overhead is minimal. Since the underlay is WireGuard, the encryption performance is essentially the same. The coordination server only handles the initial handshake and NAT traversal — it's not in the data path once the tunnel is established. The only extra latency comes from the DERP relays if you're behind a restrictive NAT. In my experience, the latency is usually under ten milliseconds for a direct peer to peer connection. Luna: So when would you not use Tailscale? Are there scenarios where traditional VPN is still better? Lucas: Good question. If you need to route all traffic from a whole network — like a full site to site VPN — Tailscale's mesh model might not be the best fit. You can do subnet routing, but it's designed for individual devices, not for routing entire subnets with complex routing tables. Also, if you need to comply with regulations that require you to control the entire VPN infrastructure yourself, you might prefer a self-hosted WireGuard or OpenVPN setup. But for most remote server access needs, Tailscale is simpler and more secure. Luna: And if you want to go fully self-hosted, there's Headscale, which we mentioned earlier. Lucas: Right. Headscale is a great option if you want the same user experience but don't want any dependency on Tailscale's infrastructure. You run the coordination server yourself. It's a bit more work to set up, but it's gaining popularity in the self-hosted community. Luna: Before we wrap up, I want to touch on something you mentioned earlier — the ease of setup. I think that's the real win here. A lot of sysadmins avoid setting up a VPN because it feels like a project, not a quick fix. Lucas: Exactly. And that's the value of tools like this. They lower the barrier to good security practices. I've seen people leave SSH exposed on port 22 because they couldn't be bothered to set up OpenVPN. With Tailscale, there's no excuse. You can have a zero-trust network in ten minutes. Luna: You know, that kind of practical utility is exactly why we keep this show ad-free. We don't want to interrupt the signal with sponsor spots. If you find episodes like this useful and want to support that choice, you can buy us a coffee at buy me a coffee dot com slash fexingo. No pressure, just a way to keep things independent. Lucas: Yeah, and we mean that. It's a small gesture that goes a long way toward keeping the content about what works, not what pays. So thanks to anyone who does. Luna: Alright, back to Tailscale. Lucas, you mentioned that the free plan supports up to a hundred devices. That seems like a lot for a single sysadmin. Lucas: It is. But consider a homelab with ten VMs, a few Raspberry Pis, a laptop, a phone, and a server at a colo — you can easily hit thirty devices. The hundred-device limit gives you room to grow. And each device counts separately, so if you have a laptop and a phone, that's two devices. Luna: One last thing — any gotchas? Things that surprised you when you first started using it? Lucas: One surprise was that by default, Tailscale lets all devices on your network talk to each other. That's the mesh philosophy — every node can reach every other node. But if you're setting up a server that should only be accessed by specific people, you need to configure ACLs. I initially forgot to do that and had a development server accessible to everyone on my Tailscale network. Not a disaster, but not ideal. Luna: So the default is permissive, which is fine for a personal network, but for a team you need to lock it down. Lucas: Exactly. And once you set up ACLs, they're enforced at the coordination server level, so even if a device is compromised, it can't bypass the ACLs. That's a strong security model. Luna: Alright, any final tips for someone trying Tailscale for the first time on a Linux server? Lucas: Start with a single server and your laptop. Install Tailscale on both, authenticate, and verify you can SSH using the Tailscale IP. Then enable MagicDNS so you can use hostnames. Once that works, consider adding subnet routing if you need access to other devices behind the server. And definitely spend ten minutes learning the ACL syntax — it's your main control layer. Luna: Good advice. And if you run into trouble, the Tailscale community forums are quite active. Lucas: They are. And the documentation is excellent — they have guides for everything from Raspberry Pi to Kubernetes. This is one of those tools that, once you try it, you wonder why you didn't earlier. Luna: That's a good note to end on. Thanks, Lucas. Lucas: Thanks, Luna. See you next time.