WireGuard, Tailscale o 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 usa 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 válidas. Use WireGuard sin componentes adicionales cuando tenga un servidor y unos pocos clientes que se conecten a él. Use Tailscale cuando quiera que cada equipo pueda acceder a los demás sin mantener un archivo de configuración. Use Headscale cuando quiera esa malla, pero no quiera que un tercero almacene la lista de nodos.

Lo que realmente aporta el plano de control

WireGuard puro no tiene descubrimiento. Cada par 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 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 de concentrador y radios: un servidor con una 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 100.64.0.0/10 CGNAT (NAT 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 transporta metadatos: qué nodos existen, qué clave pertenece a cada uno y quién puede comunicarse con quién.

De ahí se derivan tres aspectos concretos.

Recorrido 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 recorrido de sesiones para NAT) para descubrir la dirección y el puerto externos de cada extremo. Después, ambos extremos 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 relé DERP, que es un relé cifrado gestionado por Tailscale. Los datos mantienen el cifrado de extremo a extremo a través del relé, porque el relé nunca tiene las claves. Ejecute tailscale status y cada línea de par indicará direct o relay. Ejecute tailscale netcheck para ver qué relé 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 funciona indefinidamente, a menos que se elimine manualmente el bloque del par. Tailscale caduca las claves de los nodos. En julio de 2026, el periodo de caducidad predeterminado en una tailnet nueva 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ítica en lugar de enrutamiento. En WireGuard puro, 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, donde 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. Esa regla sigue siendo válida aunque una máquina obtenga una dirección nueva.

El costo que implica 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. La empresa no puede leer sus paquetes porque las claves privadas de WireGuard permanecen en sus máquinas. Sin embargo, puede ver la estructura de su red, y su capacidad para conectarse depende de que el servicio esté disponible y de que su cuenta mantenga un estado válido.

Hay un segundo costo que es fácil pasar por alto. Tailscale se ejecuta como un daemon en cada máquina. Por tanto, debe mantenerlo actualizado y aplicar parches en cada máquina. WireGuard directamente 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 costo es la facturación. En julio de 2026, el plan Personal es gratuito con 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 grupo familiar sigue siendo gratuito. Un equipo de 10 personas no.

Cuándo WireGuard básico es la opción adecuada

Elige WireGuard básico 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, no hay ninguna cuenta que perder y ningún servicio externo se interpone entre tú y el servidor.

También es la opción adecuada cuando quieres entender la capa sobre la que se construye todo lo demás. Alojar tu propia VPN WireGuard en un VPS explica la generación de claves, wg0.conf, el reenvío de IP, NAT y los errores de handshake. Todos esos mecanismos siguen ejecutándose debajo de una tailnet. Si todavía estás evaluando 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 básico deja de ser práctico en cuanto cada dispositivo debe acceder a todos los demás. Una malla completa de N nodos necesita N veces N menos un bloque de pares. Con seis dispositivos, son treinta bloques que deben mantenerse sincronizados manualmente. Además, una entrada AllowedIPs duplicada desvía el tráfico silenciosamente desde el par que la tenía primero, sin mostrar ningún error.

Cuándo Tailscale es la opción adecuada

Elige 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 controlas. Estos son exactamente los casos que WireGuard sin más gestiona mal, porque ninguno de los dos extremos tiene un endpoint público estable que puedas configurar en Endpoint.

La instalación del cliente requiere un solo comando del instalador oficial:

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

tailscale up muestra una URL. Ábrela, inicia sesión y la máquina se incorpora. No tienes 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 controlas en absoluto.

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 tengas 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 apruebas en la consola de administración. Esto es intencionado: un nodo no puede inyectar una ruta en tu 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 todavía no hace nada en un portátil Linux hasta que configuras ese ajuste.

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 al que normalmente se refiere la gente cuando dice "una VPN":

sudo tailscale set --advertise-exit-node

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 administra. Los clientes oficiales de Tailscale se conectan a él en lugar de usar el servicio alojado:

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

La ruta de datos no cambia. Sigue siendo WireGuard y continúa siendo directa 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 administra. Nadie externo puede ver la estructura de su red, desactivar su cuenta ni cobrarle por usuario.

El trabajo adicional es real. Ahora administra un servicio HTTPS público. Esto requiere 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 enterarse de los cambios. Headscale también está por debajo de la versión 1.0 y sus versiones menores han incluido cambios incompatibles, así que debe leer el registro de cambios antes de cada actualización. Ejecutar Headscale como su propio servidor de control de Tailscale cubre la instalación, config.yaml, las claves de preautorización y los puertos que debe abrir.

Hay una limitación que algunas personas detectan 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 es un único equipo en una única región, no una flota distribuida por todo el mundo. Los pares situados al otro lado del planeta notan la diferencia.

Cómo decidir en un solo paso

Pregunte cuántas máquinas deben comunicarse entre sí. Si la respuesta es que todas solo se comunican con el servidor, WireGuard básico 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 conviene implementarla de nuevo.

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 sea costosa, ejecute Headscale y acepte que ahora debe operar el servidor de control.

Puede cambiar de decisión con poco esfuerzo. Como el plano de datos usa el mismo protocolo en las tres opciones, pasar de WireGuard básico a una malla coordinada solo requiere instalar el cliente, no rediseñar la solución. Pasar de Tailscale a Headscale requiere volver a registrar cada nodo en un servidor de inicio de sesión diferente.

Lo que ninguno de los tres ofrece

Ninguno de ellos 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. Por eso, mantenga las reglas del firewall UFW en el VPS activas. La política de Tailscale limita a qué pueden acceder los demás nodos, pero no afecta a la interfaz pública.

Ninguno ofrece autenticación por servicio. Tampoco proporciona un registro de auditoría de las acciones de 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. Lo que añade es la coordinación: intercambio de claves, asignación de direcciones, recorrido de NAT con relays STUN y DERP, caducidad de claves y un archivo de políticas que identifica a los usuarios en lugar de rangos de IP. WireGuard sin más deja estas 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 pares se conectan directamente una vez que el servidor de coordinación los ha presentado, y tailscale status muestra direct en esas líneas de pares. 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 contiene 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 utiliza el mismo protocolo de control, por lo que los clientes oficiales se conectan mediante sudo tailscale up --login-server https://headscale.example.com. También puede configurar las aplicaciones de escritorio y móviles para usar un servidor de inicio de sesión personalizado. La opción se encuentra en un lugar diferente en cada plataforma, y es más probable que las aplicaciones móviles necesiten una versión específica. Pruebe primero con un teléfono antes de migrar toda la red.

¿Tengo que 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 autoalojado sí necesita puertos entrantes: 443 para el protocolo de control, 80 si utiliza un desafío de certificado HTTP-01 y 3478/udp solo cuando activa el relay integrado. WireGuard sin más 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 más, 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 indica si la ruta es directa o usa un relay, o con iperf3 a través del túnel.