Por qué una ruta de subred de Tailscale aprobada sigue agotando el tiempo de espera

La aprobación en la consola de administración parece el último paso, y no lo es. Primero la aplicación agota el tiempo de espera, y solo después descubre que el router está en línea y la ruta aprobada. La aprobación es un paso de distribución, no un permiso ni una garantía de reenvío. Cuatro etapas deben alinearse antes de que un paquete llegue a un host detrás de un router de subred, y cada una puede funcionar mientras la siguiente falla. Recórralas en orden y deténgase en la primera que no se sostenga.

Cuatro etapas, un fallo

El router anuncia el prefijo, la tailnet aprueba ese anuncio, el cliente acepta la ruta que recibió y la política de acceso permite la conexión concreta. Son cuatro decisiones separadas tomadas por tres componentes distintos. Por tanto, una ruta aprobada solo dice que la red ya forma parte de la tabla de enrutamiento de la tailnet.

La cuarta etapa es la que más se omite, porque las tres primeras producen un estado visible. Una concesión que cubre la dirección propia del router en la tailnet no cubre automáticamente una subred privada detrás de él. Son destinos distintos, y la política se evalúa por destino.

En Linux la tercera etapa también tiene un valor predeterminado que sorprende: aceptar rutas de subred es opcional. Varios clientes con interfaz gráfica aceptan las rutas anunciadas de forma predeterminada, así que una flota mixta puede mostrar una máquina que falla mientras el resto funciona.

Confirme la preferencia en la máquina que falla en lugar de suponer una plataforma. La ruta nunca fue la pieza que faltaba en las máquinas que funcionan, así que deje que demuestren que el lado de la tailnet está sano. La documentación de Tailscale sobre routers de subred cubre la aprobación, la aceptación de rutas en el cliente y la etapa de política.

Compruebe la ruta donde se ejecuta el cliente

Empiece por el cliente que falla, no por el router. Confirme que la ruta está presente y que la preferencia del cliente permite aceptar rutas.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

El primer comando muestra la lista de pares y si el router de subred es accesible, el segundo imprime las preferencias del cliente, incluido el indicador de aceptación de rutas, y el tercero pregunta al núcleo qué interfaz usaría para un host real en la subred. Si ese último comando nombra la interfaz física en lugar de la interfaz de Tailscale, la ruta nunca llegó a la tabla. Una ruta ausente es un problema del lado del cliente, no de la aprobación. Corríjalo antes de mirar la política.

Para aceptar rutas en Linux, vuelva a conectarse con el indicador en lugar de suponer que está establecido: tailscale up --accept-routes. Un cliente que se unió con otros indicadores los conserva hasta que se cambian, así que compruebe la preferencia actual antes de añadir otra. Volver a ejecutar el primer comando tras el cambio debería mostrar la ruta en la tabla.

Demuestre el reenvío y el camino de vuelta

La aprobación no configura el router para reenviar paquetes ni arregla la respuesta. Ambas son cuestiones de nivel de host en el lado LAN del router. Pruébelas en el router, no en el cliente.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

El primer comando debe informar de 1, o el núcleo descartará el paquete reenviado. El segundo muestra si el enmascaramiento de la ruta de subred reescribe el origen, que es el comportamiento predeterminado y normalmente lo que se desea. El tercero muestra si la petición llega al destino y si vuelve algo; una petición sin respuesta es un problema del camino de vuelta, no de la aprobación. Lea los tres resultados juntos antes de cambiar cualquiera de ellos.

Si el enmascaramiento se ha desactivado, la red de destino necesita una ruta de vuelta a las direcciones de la tailnet, y cada salto intermedio debe conocerla. Volver a activar el enmascaramiento es la solución más rápida para un solo servicio, a costa de ocultar la dirección original del cliente al destino. Ese intercambio importa cuando el destino registra direcciones de origen para auditar, así que decídalo deliberadamente en lugar de cambiar el indicador durante un incidente. Documente qué opción eligió, porque la siguiente persona solo verá uno de los dos comportamientos.

Lea la regla de acceso al recurso

Con la ruta presente y el reenvío demostrado, el sospechoso restante es la política. Lea la concesión que debería permitir la conexión y compruebe su destino, no solo su origen. La identidad del propio cliente también debe coincidir con el selector de la política, así que captúrela desde la misma máquina que falla.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

La salida de estado identifica las direcciones propias del cliente y los pares que ve, que es con lo que debe coincidir el selector de origen de la política. tailscale ping demuestra el camino de la tailnet hasta el propio router de subred; resuelve nombres de pares y direcciones de la tailnet, no hosts dentro de una subred anunciada. El tercer comando envía un eco ICMP normal por la ruta de subred, así que su resultado describe el destino en lugar del router. Una denegación a nivel de tailnet suele volver como rechazo, mientras que un paquete que sale y nunca vuelve agota el tiempo de espera.

Un nombre que falla es una cuestión distinta de una dirección que falla; resuelva el host directamente antes de culpar a la ruta. Escriba la concesión según el requisito real del recurso y no según toda la subred. Abrir una /24 entera para que funcione una aplicación es la forma en que una petición estrecha se convierte en un permiso amplio que después nadie se atreve a retirar.

Si el objetivo era la salida a internet y no una subred privada, el componente correcto es un nodo de salida, no un router de subred, y la política y el enrutamiento difieren en consecuencia. Compruebe esa decisión antes de ampliar una concesión. Un nodo de salida cambia la ruta predeterminada; un router de subred solo anuncia un prefijo.