Configura un router de subred Tailscale en un VPS

Qué hace un router de subred de Tailscale

Un router de subred de Tailscale es una máquina que anuncia un rango completo de direcciones IP privadas a tu tailnet, de modo que todos los dispositivos de la tailnet pueden acceder a las direcciones de ese rango aunque allí no se ejecute Tailscale. Tu tailnet es tu red privada de Tailscale: el conjunto de dispositivos que han iniciado sesión con una misma cuenta u organización. Un nodo de salida es la función que suele confundirse con esto, pero realiza la tarea contraria. Envía todo el tráfico de un dispositivo a través del VPS, de modo que el VPS se convierte en la ruta de ese dispositivo hacia Internet pública.

Una frase para cada caso. Un router de subred hace que una red privada sea accesible desde la tailnet. Un nodo de salida cambia el lugar desde el que sale tu tráfico público. Si eso es lo que necesitas, consulta cómo ejecutar un nodo de salida de Tailscale en un VPS. Son opciones independientes, y un mismo VPS puede hacer ambas cosas a la vez, pero resuelven problemas diferentes y fallan de formas distintas.

Cuándo se necesita un router de subred en un VPS

El caso habitual es una red privada que el proveedor ya le ha asignado. El VPS tiene una dirección pública y una segunda interfaz en un segmento privado. Los demás servidores de ese segmento no tienen ninguna dirección pública: una base de datos en 10.0.0.20 y un destino de copias de seguridad en 10.0.0.30. Instale Tailscale en un VPS y anuncie 10.0.0.0/24. Así, su portátil puede acceder directamente a esas direcciones privadas. No cambia nada más en el segmento y la base de datos sigue sin tener una dirección pública.

El otro caso es una red situada al otro lado del VPS. Puede ser una LAN doméstica o de oficina detrás de su propio router, o un conjunto de dispositivos que no pueden ejecutar Tailscale, como un switch gestionado o un NAS antiguo con el firmware bloqueado. Un equipo Linux de esa red se convierte en el router de subred para el resto de los dispositivos.

Ambos casos tienen un requisito en común. El router de subred ya debe poder acceder al rango que anuncia mediante su propia tabla de enrutamiento y su propio firewall. Tailscale no crea esa conexión. Transporta el tráfico hasta el router y se lo entrega al kernel para que lo reenvíe.

Instale Tailscale y compruebe primero la ruta local

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

El script detecta la distribución, añade el repositorio de paquetes de Tailscale, instala el comando tailscale y el daemon tailscaled, y después habilita el servicio. Confírmelo con systemctl is-active tailscaled, que debería mostrar active.

Antes de continuar, compruebe que el VPS pueda acceder a la red que planea anunciar.

ip route show
ping -c3 10.0.0.20

ip route show debe mostrar el rango privado en una interfaz real, por ejemplo 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Si el ping falla aquí, directamente en el router, ninguna opción de Tailscale lo solucionará. El problema está en la configuración de red del VPS o en un firewall del host de destino. Corríjalo primero, porque todas las pruebas posteriores dependen de ello.

Activa el reenvío IP y haz que persista tras un reinicio

Una máquina Linux descarta cualquier paquete que no esté dirigido a ella, a menos que el reenvío esté activado. Reenviar los paquetes de otras máquinas es la función principal de un router de subred, por lo que este paso es obligatorio.

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

Compruébalo con sysctl net.ipv4.ip_forward, que debería mostrar net.ipv4.ip_forward = 1.

A menudo este paso se completa sólo a medias. sudo sysctl -w net.ipv4.ip_forward=1 funciona de inmediato y se pierde en el siguiente arranque. Por eso, el router de subred puede funcionar durante semanas y detenerse la mañana posterior a un reinicio provocado por una actualización del kernel. La parte confusa es que nada parece estar averiado. tailscale status sigue mostrando el nodo en línea, la consola de administración sigue mostrando la ruta aprobada y los clientes todavía tienen instalada la ruta. Los paquetes llegan al VPS y el kernel los descarta sin registrar nada. Escribir los valores en /etc/sysctl.d/99-tailscale.conf hace que se restablezcan después de un reinicio.

Si anuncias rutas con el reenvío todavía desactivado, tailscale up muestra una advertencia en ese momento, con una línea similar a Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. Lee la salida de ese comando en lugar de pasarla por alto.

Anunciar las rutas

sudo tailscale up --advertise-routes=10.0.0.0/24

En un VPS que ya haya iniciado sesión en tu tailnet, cambia la configuración directamente:

sudo tailscale set --advertise-routes=10.0.0.0/24

Usa tailscale set para todos los cambios posteriores. Si vuelves a ejecutar tailscale up con una sola opción, se restablecen las opciones que no hayas repetido. La CLI detiene la operación y muestra un error que indica que, para cambiar la configuración de esta forma, debes especificar todas las opciones que no tienen el valor predeterminado. tailscale set cambia una opción y mantiene las demás sin modificaciones.

Puedes incluir varios rangos en una sola lista, separados por comas y sin espacios: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Cada entrada debe ser una dirección de red en notación CIDR (enrutamiento entre dominios sin clases, con el formato 10.0.0.0/24). Si escribes por error tu propia dirección de host, 10.0.0.5/24, se rechaza porque los bits posteriores al prefijo no son cero. El error indica el prefijo que probablemente querías usar. Para dejar de anunciar rutas, establece una lista vacía con sudo tailscale set --advertise-routes=.

Apruebe la ruta en la consola de administración

Anunciar una ruta es una solicitud, no un cambio. Hasta que un administrador la apruebe, ningún cliente recibe la ruta y no se puede acceder a nada del rango. Esto es intencionado, porque una máquina que pueda añadirse a la tabla de enrutamiento de todos podría capturar tráfico de cualquier rango que elija.

Apruébela en la página Machines de la consola de administración. El VPS aparece con una etiqueta de subred. Abra su fila, busque la sección de subredes, edite la configuración de la ruta, marque la ruta y guarde los cambios.

La aprobación se aplica a cada prefijo. Anuncie 10.0.0.0/24 hoy y 192.168.50.0/24 el próximo mes: el nuevo prefijo aparece sin aprobar, mientras el anterior sigue funcionando. Desde el VPS, una ruta aprobada y una ruta ignorada tienen el mismo aspecto. Por eso, compruebe la consola antes de depurar cualquier otra cosa.

Puede omitir el paso manual con un bloque autoApprovers en el archivo de política de tailnet:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

Después, inicie el nodo con esa etiqueta, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, y la ruta se aprobará en cuanto se anuncie. La etiqueta debe existir primero en la sección tagOwners del mismo archivo de política. Conviene configurarlo si reconstruye el VPS mediante un script, porque un nodo reconstruido es un nodo nuevo y sus rutas vuelven a aparecer sin aprobar.

Por qué los clientes Linux ignoran la ruta sin --accept-routes

La ruta ya se anuncia y está aprobada. El teléfono y el Mac pueden acceder a 10.0.0.20. El portátil Linux no puede, y la consola de administración no muestra ningún problema.

Aceptar una ruta de subred significa escribir entradas en la tabla de enrutamiento del cliente. En Android, iOS, macOS, tvOS y Windows, el cliente de Tailscale lo hace automáticamente. En Linux no ocurre así porque una máquina Linux suele ser un servidor o un router cuya tabla de enrutamiento se configuró de forma intencionada. Insertar silenciosamente una /24 aprendida de la red podría interrumpir el tráfico que esa máquina ya gestiona. Por eso, en Linux debe habilitar esta opción en cada cliente:

sudo tailscale set --accept-routes

A continuación, compruebe dónde se instaló la ruta:

ip route show table 52
ip route get 10.0.0.20

Tailscale en Linux no coloca las rutas aceptadas en la tabla de enrutamiento principal. Las coloca en la tabla de enrutamiento 52 e instala reglas de política, visibles con ip rule show en el intervalo de prioridad 5210 a 5270, que envían los paquetes no coincidentes a esa tabla. Por tanto, ip route show por sí solo nunca mostrará 10.0.0.0/24, y quien compruebe únicamente ese comando concluirá que --accept-routes no hizo nada. ip route show table 52 es el comando que muestra el estado real, y debería mostrar el rango anunciado en tailscale0.

Conviene conocer una excepción. Si este nodo Linux también es un segundo router de subred para su propia red local, --accept-routes hace que envíe el tráfico destinado a su propia subred conectada directamente a través del otro router, en lugar de hacerlo por su propia interfaz. En un router en espera de un par de alta disponibilidad, deje --accept-routes desactivado y anuncie sólo la ruta.

Modo de fallo: dos routers anuncian rangos solapados

Dos routers de subred no deben anunciar rangos idénticos. Se permiten rangos solapados con diferentes longitudes de prefijo, y Tailscale elige la coincidencia más específica. Si el router A anuncia 10.0.0.0/24 y el router B anuncia 10.0.0.0/16, el tráfico destinado a 10.0.0.20 se envía a A.

El comportamiento cuando A queda desconectado suele resultar inesperado. Tailscale no recurre a la ruta menos específica. El tráfico destinado a 10.0.0.20 se detiene, mientras que el tráfico destinado a 10.1.0.20 sigue funcionando a través de B. El síntoma parece indicar que la mitad de la red privada está caída, pero la causa es un nodo desconectado que mantiene el prefijo más específico. Si necesita conmutación por error, haga que el router con el rango más amplio anuncie también los prefijos más estrechos. Así, ambos cubrirán las mismas direcciones.

El otro solapamiento está más cerca del cliente. Si está conectado a la red de un hotel en 192.168.1.0/24 mientras el router de subred anuncia 192.168.1.0/24, ambas rutas compiten por los mismos destinos. La ruta que gana depende de la plataforma. En Linux, instale una regla por delante de la regla propia de Tailscale para que las direcciones locales usen la tabla principal:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

La regla no es persistente y desaparece en el siguiente arranque. La solución real es elegir un rango privado que no encuentre en otras redes. 192.168.0.0/24 y 192.168.1.0/24 son los valores predeterminados en la mayoría de los routers domésticos. Elija un rango dentro de 10.0.0.0/8 de forma deliberada. La misma colisión rompe una VPN de WireGuard sencilla que configure manualmente, por el mismo motivo: la ruta local más específica gana y el tráfico nunca entra en el túnel.

Modo de fallo: DNS resuelve a una dirección que ninguna ruta cubre

Este caso es difícil de depurar porque nada informa de un error. El nombre se resuelve. La conexión agota el tiempo de espera.

Suponga que db.internal.example.com se resuelve a 10.0.5.20 mediante su servidor de nombres privado y que ha anunciado 10.0.0.0/24. La consulta se completa correctamente porque la resolución DNS (sistema de nombres de dominio) y el enrutamiento IP son pasos independientes, y ninguno comprueba al otro. Después, el paquete destinado a 10.0.5.20 no encuentra una ruta coincidente en el tailnet, por lo que sale por la puerta de enlace predeterminada del cliente y desaparece.

Dos comandos permiten separar ambas partes:

nslookup db.internal.example.com
ip route get 10.0.5.20

Si la consulta devuelve una dirección, pero ip route get no responde con dev tailscale0, el nombre es correcto y falta la ruta. Anuncie un rango que cubra la dirección, ya sea 10.0.0.0/16 o un segundo prefijo explícito, y apruebe el nuevo prefijo en la consola.

El propio servidor de nombres presenta una trampa similar. Si configura un servidor de nombres global en la consola de administración con una dirección privada como 10.0.0.53, esa dirección debe estar dentro de una ruta aprobada; de lo contrario, los dispositivos no podrán alcanzar el resolvedor. Si activa la opción que sustituye los servidores DNS locales mientras apunta a un resolvedor inaccesible, todos los dispositivos del tailnet perderán la resolución de nombres al mismo tiempo, incluidos los que funcionaban un segundo antes. Anuncie y apruebe primero la ruta al resolvedor y, después, cambie la configuración de DNS. Si el DNS dentro de un túnel es el problema que sigue causando fallos, cómo falla el DNS en un túnel WireGuard describe el mismo mecanismo sin la capa de coordinación adicional.

NAT de origen y enlaces entre sitios

De forma predeterminada, el router de subred reescribe la dirección de origen de cada paquete reenviado con su propia dirección privada. Es SNAT (traducción de direcciones de red de origen) y permite que las respuestas funcionen sin cambiar nada en la red privada: la base de datos en 10.0.0.20 responde al VPS, que ya sabe cómo acceder a ella. El inconveniente es que la base de datos ve todas las conexiones de tailnet como si procedieran del VPS. Por tanto, las reglas de firewall basadas en el origen y los registros de acceso no proporcionan información útil.

Desactívelo en Linux cuando quiera conservar la dirección real del cliente en tailnet:

sudo tailscale set --snat-subnet-routes=false

Los hosts de la red privada necesitan entonces una ruta de retorno hacia 100.64.0.0/10, el rango que Tailscale asigna a los dispositivos, a través del router de subred. Sin esa ruta de retorno, las respuestas se envían a la puerta de enlace predeterminada y nunca llegan a su destino. Las conexiones quedan bloqueadas después del primer paquete. Añada la ruta estática en la puerta de enlace de la red privada o mantenga activado SNAT.

Un enlace entre sitios conecta dos routers de subred que realizan esta función al mismo tiempo. Cada uno anuncia su propia red y acepta la red del otro:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

Ejecute el comando correspondiente en el otro router con su propio rango. Los dos rangos deben ser diferentes. Si las transferencias grandes se bloquean mientras ssh y ping funcionan correctamente, la causa es MSS (tamaño máximo de segmento), es decir, la cantidad máxima de datos que transporta un paquete TCP. La sobrecarga del túnel hace que los paquetes reenviados sean demasiado grandes para algún enlace intermedio. El ajuste del tamaño máximo de segmento lo corrige:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Guarde esa regla con iptables-persistent o desaparecerá durante el siguiente arranque.

Tareas de mantenimiento para mantenerlo operativo

Las claves de los nodos caducan después de 180 días de forma predeterminada, desde agosto de 2026. Cuando caduca la clave de un router de subred, el nodo cierra la sesión y todo el rango anunciado deja de ser accesible, sin que exista ningún cambio de configuración que lo explique. Desactive la caducidad de claves para esta máquina en la página Machines de la consola de administración y registre que lo hizo.

Tailscale prefiere una conexión directa entre pares y recurre a sus servidores relay cuando no puede establecerla. Los relays funcionan, pero añaden latencia. Un VPS con una dirección pública es el caso más sencillo: permita el tráfico UDP entrante en 41641 y la mayoría de los pares se conectarán directamente. Si ufw gestiona el firewall, las reglas de ufw que realmente necesita un VPS explican la sintaxis.

Las reglas de acceso son la otra parte. En un tailnet predeterminado, todos sus dispositivos pueden acceder a los demás, por lo que una ruta aprobada funciona directamente. Cuando escribe una política ACL, el destino de una regla debe especificar el rango privado, porque 10.0.0.20 no es una dirección de tailnet y las reglas escritas para direcciones IP de tailnet o etiquetas no lo cubren.

Por último, decida si quiere utilizar un servidor de coordinación que no administra. El plano de control de Tailscale es un servicio alojado. Sus claves permanecen en sus máquinas, pero la cuenta y el archivo de política residen allí. Ejecutar Headscale, el servidor de control de Tailscale autohospedado mantiene esos elementos en su propio VPS, a cambio de tener que administrarlo. Si todavía está decidiendo entre este modelo y una configuración escrita manualmente, la comparación entre WireGuard y Tailscale explica qué ofrece la capa de coordinación y cuál es su coste.

FAQ

¿Cuál es la diferencia entre un router de subred y un nodo de salida?

Un router de subred anuncia un rango de direcciones privadas para que los dispositivos de tailnet puedan acceder a máquinas que no ejecutan Tailscale. Un nodo de salida se anuncia como ruta hacia Internet completo, de modo que un dispositivo envía todo su tráfico a través de la dirección pública de ese nodo. Un VPS puede cumplir ambas funciones. Son indicadores independientes, --advertise-routes y --advertise-exit-node, y cada uno requiere su propia aprobación en la consola de administración.

¿Por qué mi cliente Linux ignora la ruta de subred anunciada?

Los clientes Linux no aceptan rutas de subred a menos que se lo indique. Ejecute sudo tailscale set --accept-routes en el cliente. Después, compruebe con ip route show table 52, no con ip route show. Tailscale instala las rutas aceptadas en la tabla de enrutamiento 52 y accede a ellas mediante reglas de política. Por eso la tabla principal no las muestra y una ruta operativa parece ausente.

Mi subred dejó de funcionar después de reiniciar. ¿Qué falló?

Lo más probable es el reenvío IP. Un valor establecido con sysctl -w no sobrevive a un reinicio. Escríbalo en /etc/sysctl.d/99-tailscale.conf y confírmelo con sysctl net.ipv4.ip_forward. Si el reenvío está habilitado y el rango sigue sin ser accesible, revise el nodo en la consola de administración. Las claves de nodo caducan después de 180 días de forma predeterminada. Un router de subred con la clave caducada parece un fallo de red y no un problema de la cuenta.

¿Pueden dos routers de subred anunciar el mismo rango?

No si los rangos son idénticos. Los rangos solapados con longitudes de prefijo distintas son válidos, y se usa el más específico. El failover requiere atención: cuando el router que mantiene el prefijo más específico deja de estar disponible, Tailscale no recurre a la ruta más amplia. Por tanto, ese tráfico se detiene. Para crear un par de respaldo real, haga que ambos routers anuncien los mismos prefijos específicos.

El nombre de host se resuelve, pero la conexión agota el tiempo de espera. ¿Por qué?

La resolución DNS y el enrutamiento son pasos independientes. Un nombre puede resolverse en una dirección que no esté cubierta por ninguna ruta aprobada. En ese caso, el paquete sale por la puerta de enlace predeterminada del cliente. Ejecute ip route get <address> en el cliente. Si la respuesta no incluye dev tailscale0, anuncie un rango que cubra esa dirección y apruebe el nuevo prefijo en la consola de administración.