WireGuard vs Tailscale vs Headscale: cuál elegir

WireGuard frente a Tailscale: respuesta breve

WireGuard frente a Tailscale no es una elección entre dos protocolos, porque Tailscale es WireGuard. Tailscale utiliza el mismo cifrado y el mismo túnel, y añade un plano de control: un servidor de coordinación que intercambia claves públicas, asigna direcciones, atraviesa NAT (traducción de direcciones de red) y aplica una política de acceso. La elección consiste en decidir cuánto de esa coordinación quiere administrar usted mismo.

Hay tres respuestas claras. Use WireGuard sin componentes adicionales cuando tenga un servidor y unos pocos clientes que se conecten a él. Use Tailscale cuando quiera que todas las máquinas puedan comunicarse entre sí sin mantener archivos de configuración. Use Headscale cuando quiera esa malla, pero no quiera que un tercero conserve la lista de nodos.

Lo que realmente aporta el plano de control

WireGuard sin más no tiene descubrimiento. Cada par es un bloque de texto que se escribe manualmente: una clave pública, una línea AllowedIPs y un Endpoint si se puede acceder a ese par. Añadir una máquina a una red de diez implica editar diez archivos de configuración, porque cada extremo necesita la clave del otro. Por eso casi todas las implementaciones de WireGuard autohospedadas usan una topología en estrella: un servidor con una IP pública y clientes que sólo se comunican con él.

Un plano de control elimina la edición manual. Cada nodo se registra una vez, recibe una dirección del rango 100.64.0.0/10 CGNAT (NAT de grado de operador) y obtiene las claves públicas de los nodos a los que puede acceder. El túnel sigue siendo una conexión directa de WireGuard entre dos pares, y el tráfico nunca pasa por el servidor de coordinación. El servidor sólo transporta metadatos: qué nodos existen, qué clave pertenece a cada uno y quién puede comunicarse con quién.

De ahí se derivan tres funciones concretas.

Travesía de NAT. Dos portátiles detrás de dos routers domésticos no tienen una IP pública que permita conectarlos directamente. Tailscale usa STUN (utilidades de descubrimiento de sesiones para NAT) para descubrir la dirección y el puerto externos de cada lado. Después, ambos lados envían paquetes al mismo tiempo, de modo que cada router ve primero un flujo saliente y acepta la respuesta. Si esto falla, el tráfico usa un relay DERP, que es un relay cifrado operado por Tailscale. Los datos siguen cifrados de extremo a extremo a través del relay, porque este nunca tiene las claves. Ejecute tailscale status y cada línea de par mostrará direct o relay. Ejecute tailscale netcheck para ver qué relay está más cerca y si la red permite UDP.

Rotación de claves con caducidad. Las claves de WireGuard nunca caducan. Una clave emitida hace tres años sigue funcionando indefinidamente, salvo que se elimine manualmente el bloque del par. Tailscale hace caducar las claves de los nodos. Desde julio de 2026, el periodo de caducidad predeterminado en un tailnet nuevo es de 180 días. Una máquina que no vuelva a autenticarse deja de conectarse. Puede desactivar la caducidad por dispositivo para un servidor o un router de subred en el que nadie vaya a iniciar sesión.

Políticas en lugar de enrutamiento. En WireGuard sin más, AllowedIPs es a la vez la tabla de enrutamiento y la lista de control de acceso. Por tanto, «alice puede acceder a la base de datos» debe expresarse como un rango de IP. Tailscale mantiene un archivo de políticas independiente, en el que las reglas especifican usuarios, grupos y etiquetas. Una regla puede indicar que tag:laptop puede acceder a tag:db en el puerto 5432 y a ningún otro recurso. La regla sigue siendo válida aunque una máquina obtenga una dirección nueva.

Lo que le cuesta el plano de control

El servidor de coordinación conoce su red. Almacena la clave pública de cada nodo, el nombre de cada nodo, las direcciones asignadas y la política. Con Tailscale alojado, ese servidor pertenece a una empresa que no está bajo su control. Sus paquetes no son legibles para esa empresa porque las claves privadas de WireGuard permanecen en sus máquinas, pero la estructura de su red sí queda visible para ella. Además, su capacidad para conectarse depende de que el servicio esté disponible y de que su cuenta cumpla las condiciones del servicio. La importancia de este riesgo depende de lo que un servidor de coordinación comprometido o una cuenta de identidad robada pueda hacer realmente con la información que almacena. Por eso conviene leer el modelo de confianza de Tailscale en su totalidad.

Hay un segundo coste que es fácil pasar por alto. Tailscale ejecuta un daemon en cada máquina, por lo que ahora debe mantenerlo actualizado en todas ellas. WireGuard básico en Ubuntu 24.04 es un módulo del kernel que se distribuye con el sistema y se actualiza junto con el kernel.

El tercer coste es la facturación. En julio de 2026, el plan Personal es gratuito y permite dispositivos ilimitados para un máximo de 6 usuarios. Standard cuesta $8 por usuario al mes y Premium cuesta $18 por usuario al mes. Un hogar sigue siendo gratuito. Un equipo de diez personas no. Superar ese límite depende del número de usuarios, no del número de dispositivos. Conviene leer qué incluye realmente el plan gratuito antes de invitar al séptimo usuario.

Cuándo es la opción adecuada usar WireGuard sin una capa adicional

Use WireGuard sin una capa adicional cuando la topología sea realmente de concentrador y radios. Un VPS con una IP pública, tres o cuatro dispositivos que se conectan a él y ningún requisito de que esos dispositivos se comuniquen entre sí. La configuración cabe en una pantalla, no hay ningún daemon que actualizar, ninguna cuenta que perder y ningún servicio externo entre usted y el servidor.

También es la opción adecuada si quiere entender la capa sobre la que se basa todo lo demás. Alojar su propia VPN WireGuard en un VPS explica la generación de claves, wg0.conf, el reenvío de IP, NAT y los fallos del handshake. Todos esos mecanismos siguen funcionando por debajo de una tailnet. Si todavía está valorando la opción anterior, WireGuard frente a OpenVPN describe los cuatro casos en los que OpenVPN conserva una ventaja.

La instalación es breve:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

WireGuard sin una capa adicional deja de ser práctico cuando cada dispositivo debe poder comunicarse con todos los demás. Una malla completa de N nodos necesita N veces N menos un bloque de peers. Con seis dispositivos, son treinta bloques que debe mantener sincronizados manualmente. Además, una entrada AllowedIPs duplicada desvía el tráfico del peer que la tenía primero sin mostrar ningún error.

Cuándo Tailscale es la opción adecuada

Elija Tailscale cuando las máquinas cambien de red. Portátiles conectados a redes de hoteles, un teléfono con datos móviles o un servidor doméstico detrás de un router que no controla. Estos son precisamente los casos que WireGuard básico gestiona mal, porque ninguno de los dos extremos tiene un endpoint público estable que se pueda poner en Endpoint.

La instalación del cliente se realiza con un comando del instalador oficial:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

tailscale up muestra una URL. Ábrala, inicie sesión y la máquina se unirá a la red. No hay ninguna clave que copiar ni ningún puerto entrante que abrir, porque el daemon establece una conexión saliente con el servidor de coordinación y la mantiene abierta. Por eso un nodo de Tailscale también funciona en una red cuyo firewall no controla.

Después, dos configuraciones realizan la mayor parte del trabajo útil. Un router de subred anuncia una LAN completa en la red, para que no tenga que instalar el cliente en cada dispositivo:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

La ruta permanece inactiva hasta que la aprueba en la consola de administración. Es una medida deliberada: un nodo no puede inyectar una ruta en su red por sí solo. Los clientes Linux también necesitan sudo tailscale set --accept-routes, porque Linux no acepta rutas anunciadas de forma predeterminada. Por eso, una ruta que parece aprobada en el servidor no hace nada en un portátil Linux hasta que configura ese valor. Si ese es el diseño que necesita, ejecutar un router de subred en un VPS explica el paso de aprobación y la configuración del reenvío en el orden que evita dejar una ruta a medio configurar.

Un nodo de salida envía todo el tráfico de un cliente a través de una máquina. Este es el comportamiento de túnel completo que normalmente se entiende por «una VPN»:

sudo tailscale set --advertise-exit-node

Ese flag es la parte sencilla. convertir un VPS en un nodo de salida explica los pasos posteriores: aprobar la ruta en la consola de administración y corregir el comportamiento de DNS e IPv6 que, de lo contrario, hace que el tráfico salga por la ruta incorrecta. Si lo que quiere alcanzar es un único servicio web y no una red completa, servir y usar Funnel coloca HTTPS delante de un único puerto local, sólo dentro de tailnet o abierto a Internet pública.

Cuándo Headscale es la opción adecuada

Headscale es una implementación de código abierto del servidor de coordinación y se ejecuta en un VPS que usted controla. Los clientes oficiales de Tailscale se conectan a él en lugar de al servicio alojado:

sudo tailscale up --login-server https://headscale.example.com

Todo lo relacionado con la ruta de datos permanece sin cambios. Sigue siendo WireGuard y sigue funcionando directamente entre pares cuando la red lo permite. Lo que cambia es que la lista de nodos, las claves y la política se almacenan en un archivo SQLite de un disco que usted controla. Nadie externo puede ver la estructura de su red, deshabilitar su cuenta ni facturarle por usuario.

El coste es que requiere trabajo adicional. Ahora administra un servicio HTTPS público. Esto implica un nombre DNS, un certificado y un proxy inverso que reenvíe correctamente las actualizaciones de WebSocket. Usted es responsable de su disponibilidad. Si el servidor de coordinación deja de funcionar, los nodos nuevos no pueden registrarse y los nodos existentes no pueden conocer los cambios. Headscale también está por debajo de la versión 1.0 y sus versiones menores han incluido cambios incompatibles, por lo que debe leer el registro de cambios antes de cada actualización. Ejecutar Headscale como su propio servidor de control de Tailscale explica la instalación, config.yaml, las claves de preautenticación y los puertos que debe abrir.

Hay una limitación que suele descubrirse tarde. Headscale no incluye la red global de relays de Tailscale. Cuando dos pares no pueden conectarse directamente, debe habilitar el relay integrado en su propio servidor o indicar otro en la configuración. Ese relay será un único servidor en una única región, no una flota distribuida por todo el mundo. Los pares situados al otro lado del planeta notarán la diferencia. Si prefiere no montar esa parte por su cuenta, alojar NetBird por cuenta propia es la otra opción para mantener el plano de control dentro de su infraestructura, ya que su inicio rápido levanta conjuntamente los servicios de gestión, señalización y relay en un solo VPS.

Cómo decidir de una vez

Pregunte cuántas máquinas deben comunicarse entre sí. Si la respuesta es que todas sólo se comunican con el servidor, WireGuard sin más componentes requiere menos software para obtener el mismo resultado.

Pregunte si las máquinas tienen direcciones públicas estables. Si la mayoría está detrás de NAT que usted no controla, necesita un plano de control, porque la perforación de NAT es la parte difícil y no merece la pena reconstruirla.

Pregunte quién puede conocer la topología de su red. Si la respuesta excluye a empresas externas, o el número de usuarios hace que la facturación por usuario resulte costosa, ejecute Headscale y acepte que ahora administra el servidor de control. Si la facturación es lo que impulsa el cambio, haga los cálculos antes de comprometerse con la migración, porque lo que realmente paga un equipo de su tamaño depende de cuántas personas tienen cuentas y no de cuántas máquinas ejecuta, y esas dos cifras rara vez coinciden.

Puede cambiar de decisión sin mucho coste. Como el plano de datos usa el mismo protocolo en las tres opciones, pasar de WireGuard sin más componentes a una malla coordinada sólo requiere instalar el cliente, no rediseñar la arquitectura, y pasar de Tailscale a Headscale consiste en volver a registrar cada nodo en otro servidor de inicio de sesión.

Lo que ninguno de los tres ofrece

Ninguno es un firewall. Un túnel decide qué paquetes se transportan, no qué servicios están a la escucha. Un servidor accesible a través del túnel sigue siendo accesible desde Internet en cualquier puerto que haya dejado abierto, así que mantenga las reglas del firewall UFW en el VPS en funcionamiento. El archivo de políticas de Tailscale limita a qué nodos pueden acceder los demás, pero no afecta a la interfaz pública.

Ninguno proporciona autenticación por servicio, ni registra mediante auditoría lo que hizo un usuario después de conectarse. Considere los tres como mecanismos de transporte y configure las comprobaciones de inicio de sesión en la aplicación.

FAQ

¿Tailscale es simplemente WireGuard con pasos adicionales?

Tailscale usa el protocolo WireGuard para el plano de datos, por lo que el cifrado y el túnel son los mismos. Añade la coordinación: intercambio de claves, asignación de direcciones, recorrido de NAT mediante relays STUN y DERP, caducidad de claves y un archivo de políticas que identifica usuarios en lugar de rangos de IP. WireGuard sin extensiones deja esas tareas a su cargo. Se vuelven difíciles cuando las máquinas cambian de red.

¿Mi tráfico pasa por los servidores de Tailscale?

Normalmente, no. Los peers se conectan directamente una vez que el servidor de coordinación los ha presentado, y tailscale status muestra direct en esas líneas de peers. Si no se puede establecer una ruta directa, el tráfico usa un relay DERP y la línea muestra relay. Incluso en ese caso, el relay transporta paquetes cifrados y no conserva sus claves privadas de WireGuard, por lo que no puede leer el contenido. Ejecute tailscale netcheck para comprobar si su red bloquea el tráfico UDP que necesitan las conexiones directas.

¿Puedo usar Headscale con las aplicaciones oficiales de Tailscale?

Sí. Headscale usa el mismo protocolo de control, por lo que los clientes oficiales se conectan con sudo tailscale up --login-server https://headscale.example.com. Las aplicaciones de escritorio y móviles también pueden configurarse con un servidor de inicio de sesión personalizado, aunque la opción está en un lugar diferente en cada plataforma. Las aplicaciones móviles son las que tienen más probabilidades de necesitar una versión específica. Pruebe primero con un teléfono antes de migrar toda la red.

¿Necesito abrir puertos para Tailscale o Headscale?

Un cliente de Tailscale no necesita ningún puerto entrante, porque inicia la conexión con el servidor de coordinación y la mantiene abierta. Un servidor Headscale autohospedado sí necesita puertos entrantes: 443 para el protocolo de control, 80 si usa un desafío de certificado HTTP-01 y 3478/udp sólo cuando habilita el relay integrado. WireGuard sin extensiones necesita que su puerto UDP de escucha, normalmente 51820, esté abierto en el servidor y en cualquier firewall de red independiente que gestione su proveedor.

¿Cuál de los tres es más rápido?

El rendimiento es el mismo, porque los tres transportan paquetes mediante WireGuard. La diferencia aparece en el establecimiento de la conexión y en la calidad de la ruta. WireGuard sin extensiones, con un Endpoint correcto, se conecta directamente en todos los casos. Tailscale y Headscale se conectan directamente la mayoría de las veces y usan un relay cuando la red bloquea la perforación de NAT; una ruta mediante relay añade latencia. Mida su propia ruta con tailscale ping <node>, que informa de si la ruta es directa o usa un relay, o con iperf3 a través del túnel. Si ese valor es muy inferior a la velocidad de su línea en una ruta directa, el problema no está en la elección entre los tres. La causa habitual es una discrepancia de MTU de ruta, que se comporta igual con o sin un plano de control.