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 administrable o un NAS antiguo con firmware bloqueado. Un equipo Linux de esa red actúa como router de subred para todos los demás dispositivos. El router doméstico situado delante no necesita ningún puerto reenviado para esto. cómo atraviesa Tailscale la NAT sin abrir un puerto en el router explica por qué funciona y cuándo recurre a un relay. En casa, ese equipo suele ser una VM pequeña en un hypervisor que ya administra. la comparación de costes entre un host de Proxmox en casa y un VPS alquilado es el aspecto que debe resolver antes de decidir en qué extremo del túnel deben ejecutarse sus servicios.

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 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 no es opcional.

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.

A menudo este paso se completa sólo parcialmente. sudo sysctl -w net.ipv4.ip_forward=1 funciona de inmediato, pero su configuración se pierde en el siguiente arranque. Como resultado, el router de subred funciona durante semanas y deja de hacerlo la mañana posterior al 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 como aprobada y los clientes todavía tienen la ruta instalada. Los paquetes llegan al VPS y el kernel los descarta sin registrar ningún mensaje. Escribir los valores en /etc/sysctl.d/99-tailscale.conf es lo que permite recuperarlos después de un reinicio.

Si anuncia rutas con el reenvío todavía desactivado, tailscale up muestra una advertencia en ese momento. En Linux, el mensaje se parece a Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.. 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 superpuestos

Dos routers de subred pueden anunciar rangos idénticos. Así funciona un par de alta disponibilidad: cada router anuncia exactamente los mismos prefijos y los clientes pueden conmutar de uno al otro. También se permiten rangos superpuestos 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 deja de estar disponible. Tailscale no cambia a la ruta menos específica porque un router desconectado no puede retirar su anuncio y los clientes siguen prefiriendo el prefijo más específico. El tráfico hacia 10.0.0.20 se detiene, mientras que el tráfico hacia 10.0.1.20, que sólo cubre el /16 de B, sigue funcionando a través de B. El síntoma parece indicar que parte 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, configure el router con el rango más amplio para que también anuncie 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, ambas rutas compiten por los mismos destinos, y cuál gana depende de la plataforma. En Linux, instale una regla delante de la propia regla 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, así que elija un rango dentro de 10.0.0.0/8 de forma deliberada. El mismo conflicto rompe una VPN WireGuard básica que configure manualmente, por la misma razón: 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.

Supongamos que db.internal.example.com se resuelve en 10.0.5.20 a través de tu servidor de nombres privado y que has anunciado 10.0.0.0/24. La consulta se completa correctamente porque la resolución DNS (domain name system) y el enrutamiento IP son pasos independientes, y ninguno comprueba el otro. Después, el paquete dirigido a 10.0.5.20 no encuentra ninguna ruta coincidente en la 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 en este cliente. En un cliente Linux, confirma primero que --accept-routes esté activado, porque sin esta opción no se instala ninguna ruta de subred, aunque un prefijo aprobado ya cubra la dirección. Si está activado y ningún prefijo aprobado cubre la dirección, anuncia un rango que la incluya, ya sea 10.0.0.0/16 o un segundo prefijo explícito. Después, aprueba el nuevo prefijo en la consola.

En el propio servidor de nombres existe un problema similar. Si configuras 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 que no están en esa red privada no podrán acceder al resolvedor. Si activas la opción que sustituye los servidores DNS locales mientras apuntas a un resolvedor inaccesible, todos los dispositivos de la tailnet perderán la resolución de nombres de inmediato, incluidos los que funcionaban un segundo antes. Anuncia y aprueba primero la ruta al resolvedor. Después, cambia la configuración DNS. Si la resolución DNS dentro de un túnel es el problema que sigues intentando resolver, la forma en que DNS falla a través de 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. 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

La caducidad de la clave de esta máquina depende de cómo se haya iniciado sesión. Un nodo puesto en marcha con una etiqueta, como en el ejemplo autoApprovers anterior, tiene desactivada la caducidad de la clave de forma predeterminada desde el momento en que se etiqueta y autentica por primera vez, por lo que esa configuración no requiere ninguna acción aquí. Un nodo en el que se haya iniciado sesión como usuario sigue el periodo de caducidad de claves del tailnet. En un tailnet nuevo, el valor predeterminado es 180 días y, desde octubre de 2026, se puede establecer entre 1 y 180 días. Cuando caduca la clave de un router de subred de este tipo, se interrumpen las conexiones hacia él y desde él, y todo el rango anunciado deja de ser accesible, sin que ningún cambio de configuración permita explicar el problema. Para un router en el que se haya iniciado sesión como usuario, desactive la caducidad de la clave desde el menú situado al final de su fila en la página Machines de la consola de administración y anote que lo ha hecho.

Tailscale prefiere una conexión directa entre pares y recurre a sus servidores relay cuando no puede establecerla. Los relay funcionan, pero añaden latencia. Un VPS con una dirección pública es el caso más sencillo: permita la entrada de UDP 41641 y la mayoría de los pares se conectarán directamente. Cuando el tráfico hacia el rango privado es más lento de lo que debería permitir el enlace del VPS, comprobar si el cliente llega al router de subred directamente o mediante un relay es lo primero que debe descartar. Si ufw administra el firewall, las reglas de ufw que necesita realmente un VPS muestran la sintaxis.

Las reglas de acceso son la otra mitad. En un tailnet predeterminado, todos sus dispositivos pueden llegar a los demás, por lo que una ruta aprobada funciona sin más. Cuando se escribe una política ACL, el lado de destino de una regla debe cubrir el rango privado, ya sea mediante su nombre o con el comodín *, que incluye las rutas de subred aprobadas, porque 10.0.0.20 no es una dirección del tailnet y las reglas basadas en direcciones IP o etiquetas del tailnet no lo cubren.

Por último, decida si quiere depender de un servidor de coordinación que no administra. El plano de control de Tailscale es un servicio alojado. Las claves permanecen en sus equipos, pero la cuenta y el archivo de políticas están allí. Lo importante es determinar de antemano qué podría hacer realmente alguien con un plano de control comprometido o con las credenciales de identidad robadas, antes de concederle una ruta hacia su red privada. El modelo de confianza de Tailscale delimita dónde se encuentra esa frontera. El coste rara vez es el motivo para abandonarlo, porque el plan gratuito cubre hasta seis usuarios con dispositivos propios ilimitados, aunque un router de subred que active con una etiqueta se contabiliza de forma distinta a uno en el que haya iniciado sesión usted. A partir de ese límite, la factura se calcula según las personas y no según 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 autogestionado mantiene ese componente en su propio VPS, pero deberá encargarse de su mantenimiento. Otra respuesta a la misma preocupación consiste en dejar atrás también los clientes de Tailscale. Alojar usted mismo el servidor VPN de NetBird coloca la capa de coordinación y sus propios clientes de malla en una máquina que controla. Ambos utilizan WireGuard por debajo, así que los aspectos que cambian al migrar son los que analiza la comparación entre NetBird y Tailscale: quién administra el plano de control, cómo se escribe la regla de acceso que cubre el rango privado y cómo se retransmite el tráfico cuando los pares no pueden conectarse directamente. 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 router de subred y un nodo de salida?

Un router de subred anuncia un rango de direcciones privadas, de modo que los dispositivos del tailnet pueden llegar a máquinas que no ejecutan Tailscale. Un nodo de salida se anuncia como ruta hacia Internet completo, por lo que un dispositivo envía todo su tráfico a través de la dirección pública de ese nodo. Un mismo 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 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 llega 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 sobrevive a 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 siendo inaccesible, revise el nodo en la consola de administración. Un router en el que se haya iniciado sesión como usuario tiene una clave que caduca después de 180 días de forma predeterminada, y un router de subred con la clave caducada parece un fallo de red y no un problema de la cuenta. Un router puesto en marcha con una etiqueta tiene desactivada la caducidad de la clave de forma predeterminada; en ese caso, busque la causa en otro sitio.

¿Pueden dos routers de subred anunciar el mismo rango?

Sí. Los rangos idénticos permiten crear un par de alta disponibilidad: ambos routers anuncian exactamente los mismos prefijos. También se permiten rangos solapados con distintas longitudes de prefijo, y se utiliza el más específico. El failover requiere cuidado en este caso: 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 lo que ese tráfico se detiene. Para crear un par de espera 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 en un cliente Linux, compruebe primero que --accept-routes esté activo. Si lo está, anuncie un rango que cubra esa dirección y apruebe el nuevo prefijo en la consola de administración.