Headscale y Tailscale: una VPN en malla para equipos distribuidos

Llevamos años sin abrir puertos en el router de la oficina para dar acceso a nuestras máquinas. Y dormimos mejor por ello.

El problema de partida lo tiene cualquier empresa con equipos repartidos: un NAS en la oficina, servidores de desarrollo, los portátiles del equipo en sitios distintos. ¿Cómo se hablan entre sí de forma segura sin dejarlas a la vista de todo internet? La respuesta clásica era una VPN corporativa con un punto central; la que usamos nosotros es otra, y cambia bastante cómo se piensa todo lo demás.

De un túnel central a una malla

En una VPN clásica hay un punto central, normalmente un servidor o un cortafuegos, al que todos se conectan. Todo el tráfico pasa por ahí. Es lo que se llama un esquema en estrella, y tiene dos problemas evidentes: ese punto es un cuello de botella, y si cae, nadie se habla con nadie.

En una red en malla, cada dispositivo se conecta directamente con los demás. Tailscale funciona así, sobre WireGuard: el tráfico entre dos máquinas va cifrado de extremo a extremo y, cuando es posible, circula directamente entre ellas. Para quien lo usa es transparente: la máquina remota responde como si estuviera en la red local. Se abre el NAS, se entra por SSH a un servidor, se llega a un servicio interno, sin acordarse de que hay una VPN por debajo.

Lo importante no es la herramienta, sino el cambio de modelo. Dejas de pensar en “el túnel” como algo frágil que hay que mantener vivo y empiezas a pensar en una red donde cada nodo es parte de ella. Eso condiciona cómo montas el resto: qué servicios publicas, a quién das acceso y cómo lo revocas.

Qué hace el plano de control (y por qué importa quién lo aloja)

En una red en malla, el tráfico no pasa por un servidor central, pero alguien tiene que coordinar: saber qué dispositivos forman parte de la red, repartir las claves y decir a cada uno cómo localizar a los demás. Eso es el plano de control (o servidor de coordinación).

Con Tailscale, ese servidor lo pone Tailscale, como servicio gestionado. Es cómodo y funciona muy bien. La contrapartida es que la lista de tus dispositivos y la forma de tu red viven en el servicio de un tercero.

Headscale es una implementación de código abierto, independiente de Tailscale, de ese servidor de coordinación. Los dispositivos siguen usando el cliente de Tailscale, pero hablan con un servidor que alojamos nosotros. El resultado, en nuestro caso:

• Control total sobre quién está en la red y con qué permisos.
• Sin coste por usuario, porque no hay un servicio de pago por detrás.
• Nuestra topología no vive en un servicio externo, que es algo que valoramos más cuanto más crece lo que hay conectado.

No es un detalle técnico menor para una consultora que lleva infraestructura propia y de clientes: es una pieza menos que depende de que otra empresa mantenga sus condiciones.

Lo que hay que tener en cuenta

Cuando el plano de control es tuyo, es tuyo también el problema si falla. Hay que pensar dónde vive ese servidor, cómo se protege, cómo se actualiza y qué pasa con la red si hay que reconstruirlo. Ese servidor tiene que poder ser alcanzado por los dispositivos de la red, así que es la pieza a la que más atención conviene prestar, y por eso mismo la que más nos interesa tener bajo control.

En nuestro caso lo tratamos como la pieza más delicada de toda la red. Un reinicio no corta nada, porque el tráfico va directo entre los equipos y el servidor solo coordina; pero si estuviera caído mucho tiempo, la red entera se resentiría. Por eso cualquier cambio en su configuración pasa por el control de versiones, con su historial, y nunca se toca a mano en el servidor.

Además, Headscale es un proyecto independiente: su evolución va por un camino propio y algunas funciones del servicio gestionado de Tailscale pueden no estar, o llegar de otra forma. Conviene revisar qué necesitas antes de decidir.

Un caso concreto: cerrar la puerta de administración

Donde más se ha notado ha sido en el acceso de administración a los servidores. Decidimos cerrar el acceso de administración desde internet en todos los servidores Linux que llevamos, propios y de clientes, y que pasara solo por la red privada. Una puerta que no existe es una puerta que nadie puede probar. El orden importaba: primero dar de alta en la malla los servidores que todavía no estaban (doce, de veinticuatro), comprobar que se llegaba a cada uno por ese camino y dejar preparado un acceso directo para cada uno; y solo entonces cerrar en el cortafuegos la entrada pública, servidor a servidor, para no quedarnos fuera de ninguno. En los servidores más sensibles lo hicimos coordinando el momento del cambio.

Al terminar, los veinticuatro servidores se administran solo a través de la red privada. Para quien trabaja con ellos, el cambio es casi invisible: se conecta igual que antes, con otro nombre.

¿Merece la pena alojar el plano de control uno mismo?

Para la mayoría de las pymes, probablemente no. Si lo que necesitas es que tus máquinas se hablen de forma segura, el Tailscale gestionado cubre ese caso con muy poco esfuerzo, y ese esfuerzo ahorrado vale dinero.

Para nosotros sí compensa, por una razón que no es técnica: alojamos nuestras cosas por principio, queremos el control del plano de control y asumimos el mantenimiento que eso lleva. Si ese razonamiento no es el tuyo, la opción gestionada es perfectamente buena. Lo que sí nos parece que vale para todos es el cambio de enfoque: pensar en malla, no en túnel.

Dónde encaja con el resto

Esta red es lo que permite que el resto de la infraestructura (control de versiones, contenedores, almacenamiento) no tenga que dar la cara a internet. Cómo hemos llegado a ese conjunto y qué nos ha costado mantenerlo lo contamos en infraestructura propia para una pyme, y las razones de fondo para alojar lo nuestro en por qué elegimos el self-hosting. Aquí dejamos solo la parte de la red.

Lo que nos llevamos

Una VPN en malla cambia el punto de partida: en vez de proteger un perímetro con puertas abiertas, no hay puertas que proteger. Y alojar tú el plano de control es una decisión de principio más que técnica: tiene sentido si ya has decidido llevar tu infraestructura, y no lo tiene si solo buscas que las máquinas se vean entre sí.

Si tienes equipos o servidores repartidos y no tienes claro cómo conectarlos con seguridad, podemos revisarlo contigo: lo tienes todo en sistemas y cloud o puedes escribirnos por contacto.