Por qué el cliente de Tailscale para Linux ignora las rutas de subred anunciadas

Estás en un portátil Linux, tailscale status lista las demás máquinas, y el NAS en 10.80.0.25 sigue agotando el tiempo. La tailnet está sana, el router de subred está en línea, y nada en la salida del cliente dice por qué la LAN que hay detrás es inalcanzable. El recorrido de abajo avanza desde ese síntoma hacia fuera: la opción en este cliente, luego el anuncio en el router, luego la aprobación, luego la política, y solo entonces el destino mismo. Cada puerta falla con el mismo tiempo agotado, así que el orden importa más que los comandos.

Qué se niega a instalar el cliente de Linux

Los clientes de Tailscale en Linux no aceptan rutas de subred anunciadas a menos que se lo pidas. Sin ese ajuste el cliente se une a la tailnet y alcanza las direcciones de los pares, mientras que cada prefijo que anuncia el router queda sin usar. El valor por defecto es deliberado, y por eso el síntoma parece un router roto y no una decisión local.

Aquí se llaman enrutamiento dos cosas distintas, y solo una es tuya. El router anuncia un prefijo en la tailnet; tu máquina decide si lo instala. Un fallo en cualquiera de las dos produce el mismo tiempo agotado, por eso adivinar desperdicia una tarde. Averigua qué lado se niega antes de editar nada.

Activa la aceptación de rutas para esta máquina

Establece la preferencia en el cliente, y luego mira qué cambió en lugar de suponer que el comando surtió efecto. La forma actual aplica el ajuste sin repetir el flujo de inicio de sesión, lo que importa cuando estás a mitad de una sesión.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale instala las rutas aceptadas en su propia tabla en Linux, así que un prefijo que aparece en la tabla 52 es prueba directa de que este cliente instaló el anuncio. Si tu rango no está en esa tabla, detente: el problema es local y ningún trabajo en el router lo cambiará.

Los clientes más antiguos exponen la misma preferencia como una opción del comando de inicio de sesión, así que sudo tailscale up --accept-routes es la alternativa cuando falta tailscale set. Úsala en lugar de editar rutas a mano, porque el demonio reescribe su propia tabla y tu edición desaparece en la próxima reconexión. Comprueba la versión antes de copiar un comando de un artículo antiguo.

Comprueba el anuncio y la aprobación por separado

En el router de subred el prefijo tiene que anunciarse, y el núcleo tiene que reenviar paquetes entre interfaces. Anunciar sin reenviar te da una ruta aprobada que descarta el tráfico en silencio, que es la configuración a medio terminar más común.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

Compara el prefijo anunciado con la dirección a la que realmente intentas llegar, carácter a carácter. Un router que anuncia 10.70.0.0/24 no dice nada de un NAS en 10.80.0.25, y la discrepancia es invisible en cualquier salida de estado porque ambos números parecen igual de plausibles. La mayoría de los informes de una ruta rota terminan aquí. Corrige el anuncio antes de tocar nada más abajo.

La aprobación es la siguiente puerta, y es fácil saltársela cuando el router se configuró desde un shell. El anuncio tiene que habilitarse para ese dispositivo en la consola de administración antes de que otras máquinas puedan usarlo. Aceptar rutas en el cliente no aprueba nada ni anula ninguna regla de acceso.

Prueba la dirección privada antes que el nombre de host

Una conexión correcta a la dirección tailnet del propio router demuestra que la tailnet funciona, algo que ya sabías. La prueba útil es el servicio que realmente necesitas, primero contra la dirección privada, para que un fallo de DNS no pueda disfrazarse de fallo de enrutamiento.

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

Si la dirección responde y el nombre de host no, tienes un problema de resolución de nombres y deberías dejar de tratarlo como un problema de ruta. Si no responde ninguno, vuelve una sección atrás y confirma que el anuncio cubre la dirección. Los dos fallos se ven idénticos desde la aplicación y se corrigen en lugares distintos.

Merece la pena una comprobación local antes de culpar a la tailnet. Cuando tu LAN actual usa el mismo prefijo que la subred remota, el núcleo prefiere la ruta conectada directamente y el tráfico nunca sale de la máquina; eso es lo que pasa cuando una casa y una oficina eligen ambas 192.168.1.0/24.

Por qué una opción del cliente no es un ajuste del router

Son roles distintos con requisitos distintos, y copiar una opción de cliente en un router es como una tailnet que funciona adquiere un bucle. Una máquina que anuncia rutas necesita reenvío, reglas de cortafuegos que permitan el tráfico reenviado y una decisión sobre qué prefijos anuncia. Nada de eso lo implica --accept-routes.

La documentación de routers de subred advierte contra habilitar la aceptación de rutas en routers redundantes que anuncian un solo prefijo, ya que un nodo en espera puede empujar tráfico que ya es local a través del activo. Si tienes un par de alta disponibilidad, trátalo como una restricción de diseño y no como una nota al pie, y decide qué nodo posee el prefijo antes de aprobarlo en ambos. En un solo router la misma advertencia se lee como un recordatorio de que la aceptación corresponde a los clientes, no a la máquina que anuncia. Anota qué puerta estaba cerrada.

Para un cliente corriente la secuencia termina con la prueba de aplicación que falló al principio. Para el router, revisa reenvío, anuncio, aprobación y cortafuegos en ese orden, porque el primero que falte produce exactamente el tiempo agotado con el que empezaste.