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é aporta realmente el plano de control

WireGuard sin configuración adicional no tiene descubrimiento. Cada peer es un bloque de texto que se escribe manualmente: una clave pública, una línea AllowedIPs y una línea Endpoint si se puede acceder a ese peer. 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 de concentrador y radios: un servidor con una IP pública y clientes que sólo se comunican con él.

El plano de control elimina esa edición manual. Cada nodo se registra una vez, recibe una dirección del rango 100.64.0.0/10 CGNAT (carrier grade NAT) 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 peers, y el tráfico nunca pasa por el servidor de coordinación. El servidor 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.

Atravesar NAT. Dos portátiles detrás de dos routers domésticos no tienen una IP pública en común. Tailscale usa STUN (session traversal utilities for 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 recurre a un relay DERP, que es un relay cifrado administrado por Tailscale. Los datos permanecen cifrados de extremo a extremo a través del relay, porque el relay nunca tiene las claves. Ejecute tailscale status y cada línea de peer 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, a menos que elimine manualmente el bloque del peer. Tailscale hace caducar las claves de los nodos. Desde octubre de 2026, el periodo de caducidad predeterminado en un tailnet nuevo es de 180 días. Una máquina que no se haya vuelto a autenticar 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 configuración adicional, AllowedIPs es al mismo tiempo 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 cuyas 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. Esa regla sigue siendo válida 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 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 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

¿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.