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.

Qué le aporta realmente el plano de control

WireGuard básico no tiene descubrimiento. Cada par es un bloque de texto que usted escribe a mano: una clave pública, una línea AllowedIPs y una Endpoint si ese par es alcanzable. Añadir una máquina a una red de diez implica editar diez archivos de configuración, porque cada lado necesita la clave del otro. Por eso, casi toda implementación de WireGuard autohospedada es de tipo estrella: un servidor con IP pública y clientes que solo 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 CGNAT (NAT a nivel de operador) 100.64.0.0/10 y se le informan las claves públicas de los nodos a los que tiene permiso para acceder. El túnel sigue siendo WireGuard directo entre dos pares, y su tráfico nunca pasa por el servidor de coordinación. Lo que el servidor transporta es metadatos: quién existe, cuál es su clave y quién puede hablar con quién.

De esto se derivan tres aspectos concretos.

Recorrido de NAT. Dos portátiles detrás de dos routers domésticos no tienen una IP pública entre ellos. Tailscale utiliza STUN (utilidades de recorrido de sesión para NAT) para descubrir la dirección y el puerto externos de cada lado; luego, ambos lados envían paquetes al mismo tiempo para que cada router vea primero un flujo saliente y acepte la respuesta. Cuando esto falla, el tráfico recurre a un relay DERP, que es un relay cifrado operado por Tailscale. Sus datos permanecen cifrados de extremo a extremo a través del relay, porque este nunca posee las claves. Ejecute tailscale status y cada línea de par mostrará direct o relay. Ejecute tailscale netcheck para ver qué relay es el más cercano y si su red permite UDP en absoluto.

Rotación de claves con caducidad. Las claves de WireGuard nunca caducan. Una clave que usted emitió hace tres años funciona para siempre a menos que elimine el bloque del par manualmente. Tailscale, en cambio, hace caducar las claves de los nodos y, a fecha de octubre de 2026, el periodo de caducidad predeterminado en una nueva tailnet es de 180 días. Una máquina que no se ha reautenticado deja de conectarse. Puede desactivar la caducidad por dispositivo para un servidor o un router de subred donde no habrá nadie presente para iniciar sesión.

Políticas en lugar de enrutamiento. En WireGuard básico, AllowedIPs es la tabla de enrutamiento y la lista de control de acceso al mismo tiempo, por lo que "alice puede acceder a la base de datos" debe expresarse como un rango IP. Tailscale mantiene un archivo de políticas independiente donde las reglas nombran usuarios, grupos y etiquetas. Una regla puede indicar que tag:laptop puede acceder a tag:db en el puerto 5432 y a nada más, y esa regla persiste aunque una máquina obtenga una dirección nueva.

Qué costes le impone el plano de control

El servidor de coordinación conoce su red. Contiene 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 está fuera de su control. No puede leer sus paquetes, porque las claves privadas de WireGuard permanecen en sus máquinas, pero sí puede ver la estructura de su red. Además, su capacidad para conectarse depende de que el servicio esté disponible y de que su cuenta mantenga un estado válido. La importancia de este riesgo depende de lo que un servidor de coordinación comprometido o una cuenta de identidad robada pudiera hacer realmente con la información que contiene. Por eso conviene leer completo el modelo de confianza de Tailscale.

Hay un segundo coste que es fácil pasar por alto. Tailscale es un daemon en cada máquina, así que ahora debe mantenerlo actualizado en todas ellas. WireGuard estándar en Ubuntu 24.04 es un módulo del kernel que se incluye con la distribución y se actualiza junto con el kernel.

El tercer coste es la facturación. En octubre de 2026, el plan Personal es gratuito con dispositivos de usuario 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 sobre todo del número de usuarios, no del número de dispositivos, con una excepción: los servidores y otros dispositivos etiquetados tienen su propia cuota. Todos los planes incluyen 50 recursos etiquetados y, en octubre de 2026, la página de precios indica un coste de $1 al mes por cada recurso adicional. Conviene leer qué incluye realmente el plan gratuito antes de invitar al séptimo usuario o etiquetar el servidor número cincuenta y uno.

Cuándo es adecuada la opción de WireGuard sin servicios adicionales

Use WireGuard sin servicios adicionales 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 sola 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 construye todo lo demás. Alojar una VPN WireGuard en un VPS explica la generación de claves, wg0.conf, el reenvío de IP, NAT y los fallos del handshake. Las claves y el handshake siguen funcionando por debajo de cualquier tailnet. El reenvío de IP vuelve a ser necesario cuando un nodo de una tailnet actúa como router de subred o nodo de salida. Si todavía está considerando la opción anterior, WireGuard frente a OpenVPN explica 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 servicios adicionales deja de ser práctico cuando cada dispositivo debe comunicarse con todos los demás. Una malla completa de N nodos necesita N por N menos uno bloques de peers. Con seis dispositivos, son treinta bloques que deben mantenerse sincronizados manualmente. Además, una entrada AllowedIPs duplicada desvía el tráfico silenciosamente del peer que la tenía primero. No se muestra ningún error.

Cuándo Tailscale es la opción adecuada

Elija Tailscale cuando las máquinas cambian 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 sin más resuelve mal, porque ninguno de los dos extremos tiene un endpoint público estable que pueda incluirse 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 incorporará. No hay que copiar ninguna clave ni abrir ningún puerto entrante, 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 ajustes cubren la mayor parte de los usos. Un router de subred anuncia una LAN completa en la red, de modo que no tiene 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. Esto es deliberado: un nodo no puede inyectar por sí solo una ruta en la red. Los clientes Linux también necesitan sudo tailscale set --accept-routes, porque Linux no acepta rutas anunciadas de forma predeterminada. Por tanto, una ruta que parece aprobada en el servidor no hace nada en un portátil Linux hasta que establezca ese ajuste. Si esta es la configuración que necesita, ejecutar un router de subred en un VPS explica el paso de aprobación y los ajustes de reenvío en el orden que evita que la ruta quede parcialmente configurada.

Un nodo de salida envía el tráfico normal de Internet de un cliente, es decir, todo lo que no se dirige ya a otro dispositivo del tailnet ni a una ruta de subred aprobada, a través de una máquina. Este es el funcionamiento de túnel completo que normalmente se entiende por «una VPN». En Linux necesita los mismos ajustes de reenvío IP mostrados arriba antes de anunciarlo:

sudo tailscale set --advertise-exit-node

Esa opción es la parte sencilla. convertir un VPS en un nodo de salida explica lo que sigue: aprobar la ruta en la consola de administración y corregir el comportamiento de DNS e IPv6 que, de otro modo, 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, publicar y funnel coloca HTTPS delante de un único puerto local, sólo para el tailnet o abierto a Internet público.

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 peers no pueden conectarse directamente, debe habilitar el relay integrado en su propio servidor o indicar otro en la configuración. Ese relay se ejecuta en un único servidor y una única región, no en una flota distribuida por todo el mundo. Los peers situados al otro lado del planeta notan 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 juntos los servicios de gestión, señalización y relay en un único VPS. Sin embargo, NetBird no es un servidor de Tailscale compatible directamente como Headscale: publica sus propios clientes y utiliza su propio modelo de políticas. Por tanto, consulte cómo se diferencian NetBird y Tailscale en las reglas de acceso y los relays antes de elegirlo en lugar de Headscale.

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 componentes adicionales 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 volver a implementarla.

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 el coste es el factor decisivo, haga los cálculos antes de comprometerse con la migración, porque lo que realmente paga un equipo de su tamaño depende principalmente de cuántas personas tienen cuentas y no de cuántas máquinas ejecuta, hasta que sus servidores etiquetados superan los 50 incluidos en todos los planes; 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 los tres casos, pasar de WireGuard sin componentes adicionales a una malla coordinada sólo requiere instalar el cliente, no rediseñar la arquitectura; pasar de Tailscale a Headscale consiste en volver a registrar cada nodo en un servidor de inicio de sesión diferente.

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

¿Es Tailscale solo WireGuard con pasos adicionales?

Tailscale utiliza el protocolo WireGuard para la ruta de datos, por lo que el cifrado y el túnel son los mismos. Lo que añade es coordinación: intercambio de claves, asignación de direcciones, recorrido de NAT mediante STUN y relays DERP, caducidad de claves y un archivo de políticas que nombra usuarios en lugar de rangos IP. Esas son las partes que WireGuard básico le deja a usted, y son las que se vuelven difíciles cuando las máquinas se mueven entre redes.

¿Pasa mi tráfico por los servidores de Tailscale?

Normalmente no. Los pares se conectan directamente entre sí una vez que el servidor de coordinación los ha presentado, y tailscale status muestra direct en esas líneas de par. Cuando no se puede establecer una ruta directa, el tráfico recurre a un relay DERP y la línea muestra relay. Incluso entonces, el relay transporta paquetes cifrados y no posee sus claves privadas de WireGuard, por lo que no puede leer el contenido. Ejecute tailscale netcheck para ver si su red está bloqueando el tráfico UDP que necesitan las conexiones directas.

¿Puedo usar Headscale con las aplicaciones oficiales de Tailscale?

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

¿Todavía necesito abrir puertos para Tailscale o Headscale?

Un cliente de Tailscale no necesita ningún puerto de entrada, porque marca hacia el servidor de coordinación y mantiene esa conexión abierta. Un servidor Headscale autohospedado sí necesita puertos de entrada: 443 para el protocolo de control, 80 si utiliza un desafío de certificado HTTP-01 y 3478/udp solo cuando habilita el relay integrado. WireGuard básico necesita su puerto de escucha UDP, normalmente el 51820, abierto en el servidor y en cualquier firewall de red independiente que ejecute su proveedor.

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

El rendimiento es el mismo, porque los tres mueven paquetes con WireGuard. La diferencia aparece en la configuración de la conexión y en la calidad de la ruta. WireGuard básico con un Endpoint correcto se conecta directamente siempre. Tailscale y Headscale se conectan directamente la mayor parte del tiempo y recurren a un relay cuando la red bloquea el "hole punching", y una ruta a través de un relay añade latencia. Mida su propia ruta con tailscale ping <node>, que informa si la ruta es directa o a través de un relay, o con iperf3 a través del túnel. Si ese número resulta muy inferior a la velocidad de su línea en una ruta directa, la elección entre los tres no es lo que le está afectando, y la causa habitual es una discrepancia de MTU en la ruta que se comporta de la misma manera con o sin un plano de control.