Per què una ruta de subxarxa de Tailscale aprovada encara esgota el temps

L’aprovació a la consola d’administració sembla el pas final, i no ho és. Primer l’aplicació esgota el temps, i només després trobeu el router en línia i la ruta aprovada. L’aprovació és un pas de distribució, no un permís ni una garantia de reenviament. Cal que quatre etapes s’alineïn abans que un paquet arribi a un amfitrió darrere d’un router de subxarxa, i cadascuna pot reeixir mentre la següent falla. Feu-les en ordre i atureu-vos a la primera etapa que no es compleixi.

Quatre etapes, una fallada

El router anuncia el prefix, la tailnet aprova aquest anunci, el client accepta la ruta que ha rebut i la política d’accés permet la connexió concreta. Són quatre decisions separades preses per tres components diferents. Per tant, una ruta aprovada només diu que la xarxa ja forma part de la taula d’encaminament de la tailnet.

La quarta etapa és la que es descarta més sovint, perquè les tres primeres produeixen estat visible. Una concessió que cobreix l’adreça pròpia del router a la tailnet no cobreix automàticament una subxarxa privada darrere seu. Són destinacions diferents, i la política s’avalua per destinació.

A Linux, la tercera etapa també té un valor per defecte que sorprèn la gent: acceptar rutes de subxarxa és opcional. Diversos clients amb interfície gràfica accepten per defecte les rutes anunciades, de manera que una flota mixta pot mostrar una màquina que falla mentre la resta funcionen.

Confirmeu la preferència a la màquina que falla en lloc de suposar una plataforma. La ruta no va ser mai la peça que faltava a les màquines que funcionen, així que deixeu que demostrin que el costat de la tailnet és sa. La documentació de Tailscale sobre routers de subxarxa cobreix l’aprovació, l’acceptació de rutes al client i l’etapa de política.

Comproveu la ruta allà on s’executa el client

Comenceu pel client que falla, no pel router. Confirmeu que la ruta hi és i que la preferència del client permet acceptar rutes.

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

La primera ordre mostra la llista de parells i si el router de subxarxa és abastable, la segona imprimeix les preferències del client, inclòs el flag d’acceptació de rutes, i la tercera pregunta al nucli quina interfície faria servir per a un amfitrió real de la subxarxa. Si aquesta darrera ordre nomena la interfície física en lloc de la interfície de Tailscale, la ruta no ha arribat mai a la taula. Una ruta que falta és un problema del costat del client, no de l’aprovació. Arregleu-lo abans de mirar la política.

Per acceptar rutes a Linux, torneu a connectar-vos amb el flag en lloc de suposar que ja hi és: tailscale up --accept-routes. Un client que es va unir amb flags diferents els manté fins que es canvien, així que comproveu la preferència actual abans d’afegir-ne una altra. Tornar a executar la primera ordre després del canvi hauria de mostrar la ruta a la taula.

Demostreu el reenviament i el camí de tornada

L’aprovació no configura el router per reenviar paquets ni arranja la resposta. Totes dues són qüestions de nivell d’amfitrió al costat LAN del router. Proveu-les al router, no al client.

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

La primera ordre ha de reportar 1, o el nucli descartarà el paquet reenviat. La segona mostra si el maquillatge de la ruta de subxarxa reescriu l’origen, que és el comportament per defecte i normalment el que voleu. La tercera mostra si la petició arriba a la destinació i si torna res; una petició sense resposta és un problema del camí de tornada, no de l’aprovació. Llegiu els tres resultats junts abans de canviar-ne cap.

Si el maquillatge s’ha desactivat, la xarxa de destinació necessita una ruta de tornada a les adreces de la tailnet, i cada salt entremig ho ha de saber. Tornar a activar el maquillatge és la solució més ràpida per a un sol servei, a costa d’amagar l’adreça original del client a la destinació. Aquest intercanvi importa quan la destinació registra adreces d’origen per auditar, així que decidiu-ho deliberadament en lloc de canviar el flag durant un incident. Documenteu quina opció heu triat, perquè la persona següent només veurà un dels dos comportaments.

Llegiu la regla d’accés al recurs

Amb la ruta present i el reenviament demostrat, el sospitós que queda és la política. Llegiu la concessió que hauria de permetre la connexió i comproveu-ne la destinació, no només l’origen. La identitat del client també ha de coincidir amb el selector de la política, així que captureu-la a la mateixa màquina que falla.

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

La sortida d’estat identifica les adreces pròpies del client i els parells que veu, que és amb què ha de coincidir el selector d’origen de la política. tailscale ping demostra el camí de la tailnet fins al router de subxarxa mateix; resol noms de parells i adreces de la tailnet, no amfitrions dins d’una subxarxa anunciada. La tercera ordre envia un eco ICMP normal per la ruta de subxarxa, així que el seu resultat descriu la destinació, no el router. Una denegació a nivell de tailnet sol tornar com a refús, mentre que un paquet que surt i no torna mai esgota el temps.

Un nom que falla és una qüestió diferent d’una adreça que falla; resoleu l’amfitrió directament abans de culpar la ruta. Escriviu la concessió segons el requisit real del recurs i no segons tota la subxarxa. Obrir una /24 sencera perquè una aplicació funcioni és com una petició estreta es converteix en un permís ampli que després ningú no gosa retirar.

Si l’objectiu era la sortida a internet i no una subxarxa privada, el component correcte és un node de sortida, no un router de subxarxa, i la política i l’encaminament difereixen en conseqüència. Comproveu aquesta decisió abans d’ampliar una concessió. Un node de sortida canvia la ruta per defecte; un router de subxarxa només anuncia un prefix.