Per què el client de Tailscale per a Linux ignora les rutes de subxarxa anunciades

Ets en un portàtil Linux, tailscale status llista les altres màquines, i el NAS a 10.80.0.25 encara esgota el temps. La tailnet és sana, el router de subxarxa està en línia, i res a la sortida del client diu per què la LAN del darrere és inabastable. El recorregut de sota va d'aquest símptoma cap enfora: l'opció en aquest client, després l'anunci al router, després l'aprovació, després la política, i només aleshores la destinació mateixa. Cada porta falla amb el mateix temps esgotat, així que l'ordre importa més que les ordres.

Què es nega a instal·lar el client de Linux

Els clients de Tailscale a Linux no accepten rutes de subxarxa anunciades tret que els ho demanis. Sense aquest paràmetre el client s'uneix a la tailnet i arriba a les adreces dels parells, mentre que cada prefix que anuncia el router queda sense usar. El valor per defecte és deliberat, i és per això que el símptoma sembla un router espatllat i no una decisió local.

Aquí s'anomenen encaminament dues coses diferents, i només una és teva. El router anuncia un prefix a la tailnet; la teva màquina decideix si l'instal·la. Una fallada en qualsevol de les dues produeix el mateix temps esgotat, i per això endevinar malbarata una tarda. Esbrina quin costat es nega abans d'editar res.

Activa l'acceptació de rutes per a aquesta màquina

Estableix la preferència al client, i després mira què ha canviat en lloc de suposar que l'ordre ha fet efecte. La forma actual aplica el paràmetre sense repetir el flux d'inici de sessió, cosa que importa quan ets a mig camí d'una sessió.

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

Tailscale instal·la les rutes acceptades a la seva pròpia taula a Linux, així que un prefix que apareix a la taula 52 és evidència directa que aquest client ha instal·lat l'anunci. Si el teu rang no hi és, atura't: el problema és local i cap quantitat de feina al router el canviarà.

Els clients més antics exposen la mateixa preferència com una opció de l'ordre d'inici de sessió, així que sudo tailscale up --accept-routes és l'alternativa quan falta tailscale set. Fes-la servir en lloc d'editar rutes a mà, perquè el dimoni reescriu la seva pròpia taula i la teva edició desapareix a la propera reconnexió. Comprova la versió abans de copiar una ordre d'un article antic.

Comprova l'anunci i l'aprovació per separat

Al router de subxarxa el prefix s'ha d'anunciar, i el nucli ha de reenviar paquets entre interfícies. Anunciar sense reenviar et dona una ruta aprovada que descarta el trànsit en silenci, que és la configuració a mig fer més habitual.

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

Compara el prefix anunciat amb l'adreça a la qual realment vols arribar, caràcter a caràcter. Un router que anuncia 10.70.0.0/24 no diu res d'un NAS a 10.80.0.25, i la discrepància és invisible a qualsevol sortida d'estat perquè tots dos números semblen igual de plausibles. La majoria d'informes d'una ruta trencada acaben aquí. Corregeix l'anunci abans de tocar res més avall.

L'aprovació és la porta següent, i és fàcil saltar-se-la quan el router s'ha configurat des d'una shell. L'anunci s'ha d'habilitar per a aquest dispositiu a la consola d'administració abans que altres màquines el puguin fer servir. Acceptar rutes al client no aprova res ni anul·la cap regla d'accés.

Prova l'adreça privada abans que el nom d'amfitrió

Una connexió correcta a l'adreça tailnet del mateix router demostra que la tailnet funciona, cosa que ja sabies. La prova útil és el servei que realment necessites, primer contra l'adreça privada, perquè una fallada de DNS no es pugui fer passar per una fallada d'encaminament.

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 l'adreça respon i el nom d'amfitrió no, tens un problema de resolució de noms i hauries de deixar de tractar-lo com un problema de ruta. Si no respon cap dels dos, torna una secció enrere i confirma que l'anunci cobreix l'adreça. Les dues fallades semblen idèntiques des de l'aplicació i es corregeixen en llocs diferents.

Val la pena fer una comprovació local abans de culpar la tailnet. Quan la teva LAN actual fa servir el mateix prefix que la subxarxa remota, el nucli prefereix la ruta connectada directament i el trànsit no surt mai de la màquina; això és el que passa quan una casa i una oficina trien totes dues 192.168.1.0/24.

Per què una opció del client no és un paràmetre del router

Són papers diferents amb requisits diferents, i copiar una opció de client a un router és com una tailnet que funciona adquireix un bucle. Una màquina que anuncia rutes necessita reenviament, regles de tallafoc que permetin el trànsit reenviat i una decisió sobre quins prefixos anuncia. Res d'això no ho implica --accept-routes.

La documentació dels routers de subxarxa adverteix contra habilitar l'acceptació de rutes en routers redundants que anuncien un sol prefix, ja que un node en espera pot empènyer trànsit que ja és local a través del node actiu. Si tens una parella HA, tracta-ho com una restricció de disseny i no com una nota al peu, i decideix quin node posseeix el prefix abans d'aprovar-lo als dos. En un sol router, la mateixa advertència es llegeix com un recordatori que l'acceptació pertoca als clients, no a la màquina que fa l'anunci. Anota quina porta estava tancada.

Per a un client corrent la seqüència acaba amb la prova d'aplicació que va fallar al principi. Per al router, revisa reenviament, anunci, aprovació i tallafoc en aquest ordre, perquè el primer que falti produeix exactament el temps esgotat amb què vas començar.