What is Tailscale and why it changed the way machines connect
Published on 2026-09-12 by frfrand
Una VPN sin servidor central por el que pase el tráfico: cómo funciona el modelo de malla sobre WireGuard, qué resuelve que una VPN clásica no, y cuándo no conviene.
A classic VPN has a central server through which all traffic passes. It works, and it has two problems that become noticeable as the team grows.
The first is latency: two machines in the same city send their packets to a server that may be on another continent, just to come back. The second is that this central server is a bottleneck and a single point of failure.
Tailscale tackles this with a different model.
The idea: control goes one way, data another
Tailscale builds a mesh network over WireGuard. Each machine you install gets its own address within your private network and connects directly to the others.
The coordination server exists, but it does not see your traffic. Its job is to distribute public keys and help two machines find each other. Once they have found each other, they communicate directly.
That separation between control plane and data plane is the whole trick. The central service can go down and established connections keep working.
The difficult problem it solves
Two machines behind home routers cannot connect directly: neither accepts incoming connections. It is the same NAT we discussed when looking at IPv4.
Tailscale uses NAT traversal techniques: both machines start sending packets outward at the same time, coordinated by the central server, and take advantage of the fact that the router leaves the return path open for what it itself initiated.
It works on the vast majority of networks. When it doesn't work (some corporate NATs are especially hostile), there are relay servers that forward encrypted traffic. It's slower, but the connection doesn't drop. The user doesn't know which of the two paths they are using.
What feels different
You install the client on your laptop, on your server, and on a colleague's server. Each one receives a stable address.
From there, that address works the same whether the machine is in the office, in a café, or in another country. It can be used in a configuration file, in a connection string, in a script. It doesn't change when the network changes.
That is what is hardest to achieve with a traditional VPN, and what is most appreciated in day-to-day use.
It also brings access control by rules: you define which machine can talk to which and on which port, in a file, in a single place, instead of replicating firewall rules on every server.
When it's not worth it
If you need to inspect traffic. Being peer-to-peer, there is no central point to look at. For some compliance requirements, that is an impediment.
If you don't want to depend on an external service. The control plane belongs to a third party. There is an open-source alternative (Headscale) that can be self-hosted, but then you have something to maintain again.
If all you need is to access a server. For that, SSH with keys is enough, and there's no need to add a layer.
How it is similar to what we do
The underlying idea is the same one we apply among ArduMaker VPSs: that machines can see each other without any of them having to be exposed to the Internet, and that access is defined in one place instead of being replicated on every server.
The difference is the scope. Tailscale is excellent for including laptops and people spread around the world. The tunnels between VPSs solve the server-to-server segment, which is where constant traffic lives and where you don't want to depend on a third party. Both coexist well.