De ce clientul Tailscale din Linux ignoră rutele de subrețea anunțate

Sunteți pe un laptop Linux, tailscale status listează celelalte mașini, iar NAS-ul de la 10.80.0.25 tot expiră. Tailnet-ul este sănătos, routerul de subrețea este online și nimic din ieșirea clientului nu spune de ce LAN-ul din spatele lui este inaccesibil. Ghidul de mai jos pornește de la acel simptom spre exterior: steagul de pe acest client, apoi anunțul de pe router, apoi aprobarea, apoi politica și abia apoi destinația în sine. Fiecare poartă eșuează cu aceeași expirare, așa că ordinea contează mai mult decât comenzile.

Ce refuză să instaleze clientul Linux

Clienții Tailscale din Linux nu acceptă rute de subrețea anunțate decât dacă le cereți asta. Fără această setare clientul se alătură tailnet-ului și ajunge la adresele perechilor, în timp ce fiecare prefix anunțat de router rămâne nefolosit. Valoarea implicită este intenționată și de aceea simptomul arată ca un router defect, nu ca o decizie locală.

Două lucruri diferite se numesc rutare aici, iar doar unul este al dumneavoastră. Routerul anunță un prefix în tailnet; mașina dumneavoastră decide dacă îl instalează. O defecțiune în oricare dintre ele produce aceeași expirare, de aceea ghicitul pierde o după-amiază. Aflați care parte refuză înainte de a modifica ceva.

Activați acceptarea rutelor pentru această mașină

Setați preferința pe client, apoi uitați-vă ce s-a schimbat în loc să presupuneți că comanda a funcționat. Forma actuală aplică setarea fără a repeta fluxul de autentificare, ceea ce contează când sunteți la mijlocul unei sesiuni.

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

Tailscale instalează rutele acceptate în propriul tabel pe Linux, așa că un prefix care apare în tabelul 52 este dovadă directă că acest client a instalat anunțul. Dacă intervalul dumneavoastră lipsește din acel tabel, opriți-vă: problema este locală și nicio muncă pe router nu o va schimba.

Clienții mai vechi expun aceeași preferință ca steag al comenzii de autentificare, așa că sudo tailscale up --accept-routes este alternativa când lipsește tailscale set. Folosiți-o în loc să editați rutele manual, pentru că demonul își rescrie propriul tabel, iar modificarea dumneavoastră dispare la următoarea reconectare. Verificați versiunea înainte de a copia o comandă dintr-un articol vechi.

Verificați anunțul și aprobarea separat

Pe routerul de subrețea prefixul trebuie anunțat, iar kernelul trebuie să transmită pachetele între interfețe. Anunțul fără transmitere vă dă o rută aprobată care aruncă traficul în silențiu, iar aceasta este cea mai comună configurație pe jumătate terminată.

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

Comparați prefixul anunțat cu adresa la care încercați de fapt să ajungeți, caracter cu caracter. Un router care anunță 10.70.0.0/24 nu spune nimic despre un NAS la 10.80.0.25, iar nepotrivirea este invizibilă în orice ieșire de stare pentru că ambele numere par la fel de plauzibile. Majoritatea raportărilor unei rute defecte se termină aici. Corectați anunțul înainte de a atinge ceva mai jos.

Aprobarea este următoarea poartă și este ușor de sărit când routerul a fost configurat dintr-un shell. Anunțul trebuie activat pentru acel dispozitiv în consola de administrare înainte ca alte mașini să îl poată folosi. Acceptarea rutelor pe client nu aprobă nimic și nu anulează nicio regulă de acces.

Testați adresa privată înaintea numelui de gazdă

O conexiune reușită la adresa tailnet a routerului însuși dovedește că tailnet-ul funcționează, ceea ce știați deja. Testul util este serviciul de care aveți cu adevărat nevoie, mai întâi către adresa privată, ca o defecțiune DNS să nu se poată da drept defecțiune de rutare.

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

Dacă adresa răspunde și numele de gazdă nu, aveți o problemă de rezolvare a numelor și ar trebui să nu o mai tratați ca problemă de rută. Dacă niciuna nu răspunde, reveniți o secțiune și confirmați că anunțul acoperă adresa. Cele două defecțiuni arată identic din aplicație și se repară în locuri diferite.

Merită o verificare locală înainte de a da vina pe tailnet. Când LAN-ul actual folosește același prefix ca subrețeaua îndepărtată, kernelul preferă ruta conectată direct și traficul nu părăsește niciodată mașina; asta se întâmplă când o casă și un birou aleg amândouă 192.168.1.0/24.

De ce un steag de client nu este o setare a routerului

Sunt roluri diferite cu cerințe diferite, iar copierea unui steag de client pe un router este felul în care un tailnet funcțional capătă o buclă. O mașină care anunță rute are nevoie de transmitere, reguli de firewall care permit traficul transmis și o decizie privind prefixele pe care le anunță. Nimic din toate acestea nu este implicat de --accept-routes.

Documentația routerelor de subrețea avertizează împotriva activării acceptării rutelor pe routere redundante care anunță un singur prefix, fiindcă un nod de rezervă poate împinge traficul deja local prin nodul activ. Dacă rulați o pereche HA, tratați asta ca o constrângere de proiectare și nu ca o notă de subsol, și decideți care nod deține prefixul înainte de a-l aproba pe amândouă. Pe un singur router același avertisment se citește ca o reamintire că acceptarea aparține clienților, nu mașinii care anunță. Notați care poartă era închisă.

Pentru un client obișnuit secvența se termină cu testul aplicației care a eșuat la început. Pentru router, revizuiți transmiterea, anunțul, aprobarea și firewallul în această ordine, pentru că primul lipsă produce exact expirarea cu care ați început.