Por que unha ruta de subrede de Tailscale aprobada segue esgotando o tempo de espera

A aprobación na consola de administración parece o último paso, e non o é. Primeiro a aplicación esgota o tempo de espera, e só despois descobre que o router está en liña e a ruta aprobada. A aprobación é un paso de distribución, non un permiso nin unha garantía de reenvío. Catro etapas deben aliñarse antes de que un paquete chegue a un host detrás dun router de subrede, e cada unha pode funcionar mentres a seguinte falla. Percórraas en orde e detéñase na primeira que non se sosteña.

Catro etapas, un fallo

O router anuncia o prefixo, a tailnet aproba ese anuncio, o cliente acepta a ruta que recibiu e a política de acceso permite a conexión concreta. Son catro decisións separadas tomadas por tres compoñentes distintos. Por tanto, unha ruta aprobada só di que a rede xa forma parte da táboa de encamiñamento da tailnet.

A cuarta etapa é a que máis se omite, porque as tres primeiras producen un estado visible. Unha concesión que cobre o enderezo propio do router na tailnet non cobre automaticamente unha subrede privada detrás del. Son destinos distintos, e a política avalíase por destino.

En Linux a terceira etapa tamén ten un valor predeterminado que sorprende: aceptar rutas de subrede é opcional. Varios clientes con interface gráfica aceptan as rutas anunciadas de forma predeterminada, así que unha frota mixta pode mostrar unha máquina que falla mentres o resto funciona.

Confirme a preferencia na máquina que falla en lugar de supor unha plataforma. A ruta nunca foi a peza que faltaba nas máquinas que funcionan, así que deixe que demostren que o lado da tailnet está san. A documentación de Tailscale sobre routers de subrede cobre a aprobación, a aceptación de rutas no cliente e a etapa de política.

Comprobe a ruta onde se executa o cliente

Empece polo cliente que falla, non polo router. Confirme que a ruta está presente e que a preferencia do cliente permite aceptar rutas.

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

O primeiro comando mostra a lista de pares e se o router de subrede é accesible, o segundo imprime as preferencias do cliente, incluído o indicador de aceptación de rutas, e o terceiro pregunta ao núcleo que interface usaría para un host real na subrede. Se ese último comando nomea a interface física en lugar da interface de Tailscale, a ruta nunca chegou á táboa. Unha ruta ausente é un problema do lado do cliente, non da aprobación. Corríxao antes de mirar a política.

Para aceptar rutas en Linux, volva conectarse co indicador en lugar de supor que está establecido: tailscale up --accept-routes. Un cliente que se uniu con outros indicadores consérvaos ata que se cambian, así que comprobe a preferencia actual antes de engadir outra. Volver executar o primeiro comando tras o cambio debería mostrar a ruta na táboa.

Demostre o reenvío e o camiño de volta

A aprobación non configura o router para reenviar paquetes nin arranxa a resposta. Ambas son cuestións de nivel de host no lado LAN do router. Próbeas no router, non no cliente.

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

O primeiro comando debe informar de 1, ou o núcleo descartará o paquete reenviado. O segundo mostra se a máscara da ruta de subrede reescribe a orixe, que é o comportamento predeterminado e normalmente o que se desexa. O terceiro mostra se a petición chega ao destino e se volve algo; unha petición sen resposta é un problema do camiño de volta, non da aprobación. Lea os tres resultados xuntos antes de cambiar calquera deles.

Se a máscara se desactivou, a rede de destino necesita unha ruta de volta aos enderezos da tailnet, e cada salto intermedio debe coñecela. Volver activar a máscara é a solución máis rápida para un só servizo, a costa de ocultar o enderezo orixinal do cliente ao destino. Ese intercambio importa cando o destino rexistra enderezos de orixe para auditar, así que decídao deliberadamente en lugar de cambiar o indicador durante un incidente. Documente que opción escolleu, porque a seguinte persoa só verá un dos dous comportamentos.

Lea a regra de acceso ao recurso

Coa ruta presente e o reenvío demostrado, o sospeitoso restante é a política. Lea a concesión que debería permitir a conexión e comprobe o seu destino, non só a súa orixe. A identidade do propio cliente tamén debe coincidir co selector da política, así que captúrea desde a mesma máquina que falla.

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

A saída de estado identifica os enderezos propios do cliente e os pares que ve, que é con o que debe coincidir o selector de orixe da política. tailscale ping demostra o camiño da tailnet ata o propio router de subrede; resolve nomes de pares e enderezos da tailnet, non hosts dentro dunha subrede anunciada. O terceiro comando envía un eco ICMP normal pola ruta de subrede, así que o seu resultado describe o destino en lugar do router. Unha denegación a nivel de tailnet adoita volver como rexeitamento, mentres que un paquete que sae e nunca volve esgota o tempo de espera.

Un nome que falla é unha cuestión distinta dun enderezo que falla; resolva o host directamente antes de culpar a ruta. Escriba a concesión segundo o requisito real do recurso e non segundo toda a subrede. Abrir unha /24 enteira para que funcione unha aplicación é a forma en que unha petición estreita se converte nun permiso amplo que despois ninguén se atreve a retirar.

Se o obxectivo era a saída a internet e non unha subrede privada, o compoñente correcto é un nodo de saída, non un router de subrede, e a política e o encamiñamento difiren en consecuencia. Comprobe esa decisión antes de ampliar unha concesión. Un nodo de saída cambia a ruta predeterminada; un router de subrede só anuncia un prefixo.