Configurar 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 puedan 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 exit node es la función que suele confundirse con él y realiza la tarea opuesta. 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 exit node cambia el lugar desde el que sale tu tráfico público. Si necesitas lo segundo, consulta cómo ejecutar un exit node de Tailscale en un VPS. Son flags independientes y un mismo VPS puede realizar ambas funciones al mismo tiempo, pero resuelven problemas distintos y fallan de formas diferentes.

Cuándo un VPS necesita actuar como enrutador de subred

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 podrá 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. Si sólo necesita acceder desde ese segmento a una aplicación web en un puerto, anunciar todo el rango es más de lo necesario, y Tailscale serve proporciona HTTPS directamente en ese único puerto. El mismo razonamiento se aplica a un daemon que se enlaza deliberadamente sólo a localhost, como dsh ejecutándose sin interfaz bajo systemd, donde una dirección de tailnet en ese VPS sustituye al túnel SSH que de otro modo tendría que mantener abierto para acceder a su interfaz.

El otro caso es una red situada al otro lado del VPS. Puede ser una LAN (red de área local) 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 firmware bloqueado. Un equipo Linux de esa red actúa como enrutador de subred para todos los demás dispositivos. En casa, ese equipo suele ser una VM pequeña en un hipervisor que ya administra. Antes de decidir en qué extremo del túnel deben ejecutarse sus servicios, conviene resolver la comparación de costes entre un host Proxmox doméstico y un VPS alquilado.

Ambos casos tienen un requisito común. El enrutador 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 enrutador y se lo entrega al kernel para que lo reenvíe.

Instalar Tailscale y comprobar 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 puede alcanzar 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, algo similar a 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, ningún indicador 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.

Activar el reenvío IP y conservarlo tras reiniciar

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ébelo con sysctl net.ipv4.ip_forward, que debería mostrar net.ipv4.ip_forward = 1.

Este paso suele configurarse sólo parcialmente. sudo sysctl -w net.ipv4.ip_forward=1 funciona de inmediato, pero se pierde en el siguiente arranque. Por eso, el router de subred puede funcionar durante semanas y dejar de hacerlo la mañana siguiente al reiniciar después de una actualización del kernel. La parte confusa es que nada parece estar averiado. tailscale status sigue mostrando el nodo como activo, la consola de administración sigue mostrando la ruta como aprobada y los clientes todavía tienen instalada la ruta. Los paquetes llegan al VPS, pero el kernel los descarta sin registrar ningún mensaje. Escribir los valores en /etc/sysctl.d/99-tailscale.conf hace que se restablezcan después de un reinicio.

Si anuncia 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.. Lea la salida de ese comando en lugar de pasarla por alto.

Anuncie las rutas

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

En un VPS que ya ha iniciado sesión en su tailnet, cambie la configuración directamente:

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

Use tailscale set para cada cambio posterior. Si vuelve a ejecutar tailscale up con un solo indicador, se restablecen los indicadores que no haya repetido. La CLI detiene la operación y muestra un error que indica que, para cambiar la configuración de esta forma, debe mencionar todos los indicadores que no tengan el valor predeterminado. tailscale set cambia un ajuste y deja los demás intactos.

Incluya varios rangos en una sola lista separada 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 clase, el formato 10.0.0.0/24). Si escribe por error su 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ía usar. Para dejar de anunciar rutas, establezca una lista vacía con sudo tailscale set --advertise-routes=.

Aprobar 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 dentro del rango. Esto es intencionado, porque una máquina que puede añadirse a la tabla de enrutamiento de todos podría capturar el tráfico de cualquier rango que quisiera.

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 aparecerá sin aprobar, mientras el antiguo seguirá 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, active 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. Esto resulta útil si reconstruye el VPS mediante un script, porque un nodo reconstruido es un nodo nuevo y sus rutas vuelven a quedar 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, porque una máquina Linux suele ser un servidor o un router cuya tabla de enrutamiento se configuró de forma explícita, y la inserción silenciosa de una /24 aprendida de la red podría interrumpir el tráfico que esa máquina ya gestiona. Por eso, en Linux debe habilitarse de forma explícita 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íticas, visibles con ip rule show en el intervalo de prioridad de 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 sólo ese comando concluirá que --accept-routes no hizo nada. ip route show table 52 es el comando que muestra la configuración real, y debería listar el rango anunciado en tailscale0.

Hay una excepción importante. Si este nodo Linux es también 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 de reserva de un par de alta disponibilidad, mantenga --accept-routes desactivado y anuncie únicamente 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 longitudes de prefijo diferentes, y Tailscale selecciona 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 hacia 10.0.0.20 se dirige a A.

Lo que suele sorprender es el comportamiento cuando A queda fuera de línea. Tailscale no recurre a la ruta menos específica. El tráfico hacia 10.0.0.20 se detiene, mientras que el tráfico hacia 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 fuera de línea que mantiene el prefijo más específico. Si quiere disponer de conmutación por error, haga que el router con el rango más amplio anuncie también los prefijos más estrechos, de modo que ambos cubran las mismas direcciones.

El otro solapamiento está más cerca del cliente. Si está conectado a una red de hotel en 192.168.1.0/24 mientras el router de subred anuncia 192.168.1.0/24, ambos compiten por los mismos destinos, y cuál gana depende de la plataforma. En Linux, instale una regla antes 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

Esa 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, así que elija algo dentro de 10.0.0.0/8 de forma deliberada. El mismo conflicto afecta a una VPN WireGuard normal que configure manualmente, por la misma razón: la ruta local más específica gana, de modo que el tráfico nunca entra en el túnel.

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

Este fallo 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 como 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 de DNS (sistema de nombres de dominio) y el enrutamiento IP son pasos independientes, y ninguno comprueba al otro. El paquete destinado a 10.0.5.20 no encuentra una ruta coincidente en la tailnet, así que sale por la puerta de enlace predeterminada del cliente y desaparece.

Dos comandos permiten separar ambos aspectos:

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.

En el propio servidor de nombres existe un problema similar. Si establece 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 llegar al resolvedor. Si activa la opción que sustituye los servidores DNS locales mientras apunta a un resolvedor inaccesible, todos los dispositivos de la 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 cambie después la configuración de DNS. Si DNS dentro de un túnel es el problema que sigue causando dificultades, la forma en que DNS falla a través de un túnel WireGuard explica 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. Esto 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 coste es que la base de datos ve todas las conexiones de tailnet como si procedieran del VPS, por lo que las reglas de firewall por 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 a 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, por lo que las conexiones se quedan bloqueadas después del primer paquete. Añada la ruta estática en la puerta de enlace de la red privada o mantenga SNAT activado.

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 equivalente 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), el tamaño máximo de los datos que transporta un paquete TCP. La sobrecarga del túnel hace que los paquetes reenviados sean demasiado grandes para algún enlace intermedio, y el ajuste del tamaño máximo corrige el problema:

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á en el siguiente arranque.

Mantenimiento para que siga funcionando

Las claves de nodo caducan de forma predeterminada después de 180 days, desde August 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 ningún cambio de configuración lo explique. Desactive la caducidad de claves para esta máquina en la página Machines de la consola de administración y deje constancia de ello.

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 sencillo: permita el tráfico UDP entrante en 41641 y la mayoría de los pares se conectarán directamente. Si ufw administra el firewall, las reglas de ufw que realmente necesita un VPS explican la sintaxis.

Las reglas de acceso son la otra mitad. En un tailnet predeterminado, todos sus dispositivos pueden comunicarse con 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 con direcciones IP de tailnet o tags no lo cubren.

Por último, decida si quiere utilizar un servidor de coordinación que no administra usted. 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íticas residen allí. Lo importante es determinar qué podría hacer realmente alguien con un plano de control comprometido o con las credenciales de una identidad robada antes de concederle acceso a una ruta hacia su red privada. El modelo de confianza de Tailscale delimita dónde se encuentra esa frontera. El coste rara vez hace que los usuarios abandonen Tailscale, ya que el plan gratuito admite hasta seis usuarios con un número ilimitado de dispositivos propios, aunque un router de subred que active con un tag se contabiliza de forma distinta de uno que haya iniciado sesión como usted. A partir de ese límite, la factura se basa en las personas y no en las máquinas. Por eso conviene calcular cuánto paga realmente un hogar o un equipo de cinco personas cuando se agota el plan gratuito antes de añadir la cuenta que le haga superar el límite. Ejecutar Headscale, el servidor de control de Tailscale autohospedado mantiene ese componente en su propio VPS, pero tendrá que administrarlo. Otra respuesta a la misma preocupación consiste en dejar atrás también los clientes de Tailscale. Autohospedar el servidor VPN de NetBird coloca la capa de coordinación y sus propios clientes mesh en una máquina que usted controla. Si todavía está decidiendo entre este modelo y una configuración escrita manualmente, la comparación entre WireGuard y Tailscale explica qué aporta la capa de coordinación y cuál es su coste.

FAQ

¿Cuál es la diferencia entre un subnet router y un exit node?

Un subnet router anuncia un rango de direcciones privadas para que los dispositivos del tailnet puedan acceder a máquinas que no ejecutan Tailscale. Un exit node se anuncia como ruta a Internet completa, 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 desempeñar ambas funciones. Son flags 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 les 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íticas, por lo que la tabla principal nunca 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 persiste tras un reinicio, por lo que debe escribirlo en /etc/sysctl.d/99-tailscale.conf y confirmarlo con sysctl net.ipv4.ip_forward. Si el reenvío está activo 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, y un subnet router cuya clave ha caducado parece un fallo de red, no un problema de cuenta.

¿Pueden dos subnet routers anunciar el mismo rango?

No si los rangos son idénticos. Los rangos solapados con longitudes de prefijo diferentes funcionan correctamente, y se utiliza el más específico. El failover requiere cuidado: cuando el router que mantiene el prefijo más específico se desconecta, Tailscale no cambia a la ruta más amplia, por lo que ese tráfico se detiene. Para formar 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, y el paquete sale entonces 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.