Prečo schválená trasa podsiete v Tailscale stále končí vypršaním času

Schválenie v administratívnej konzole vyzerá ako posledný krok, ale nie je. Najprv aplikácia skončí vypršaním času, a až potom zistíte, že je router online a trasa schválená. Schválenie je krok distribúcie, nie povolenie a nie záruka preposielania. Štyri etapy sa musia zladiť, kým paket dorazí k hostiteľovi za routerom podsiete, a každá môže uspieť, kým ďalšia zlyhá. Prejdite ich po poradí a zastavte sa pri prvej etape, ktorá neobstojí.

Štyri etapy, jedno zlyhanie

Router inzeruje prefix, tailnet toto oznámenie schváli, klient prijme trasu, ktorú dostal, a prístupová politika povolí konkrétne spojenie. To sú štyri oddelené rozhodnutia, ktoré prijímajú tri rôzne komponenty. Schválená trasa preto hovorí len to, že sieť je teraz súčasťou smerovacej tabuľky tailnetu.

Štvrtá etapa sa najčastejšie vynecháva, pretože prvé tri dávajú viditeľný stav. Povolenie, ktoré pokrýva vlastnú adresu routera v tailnete, automaticky nepokrýva privátnu podsieť za ním. Sú to rôzne ciele a politika sa vyhodnocuje pre každý cieľ zvlášť.

V Linuxe má tretia etapa aj predvolené správanie, ktoré ľudí prekvapí: prijímanie trás podsietí je voliteľné. Viaceré GUI klienty prijímajú inzerované trasy predvolene, takže zmiešaná flotila môže ukázať jeden zlyhávajúci stroj, kým ostatné fungujú.

Overte nastavenie na zlyhávajúcom stroji, namiesto toho, aby ste predpokladali platformu. Trasa nikdy nebola chýbajúcim dielom na fungujúcich strojoch, preto nechajte ich dokázať, že strana tailnetu je zdravá. Dokumentácia Tailscale k routerom podsietí pokrýva schválenie, prijatie trás klientom a etapu politiky.

Skontrolujte trasu tam, kde beží klient

Začnite pri zlyhávajúcom klientovi, nie pri routeri. Potvrďte, že trasa existuje a že nastavenie klienta vôbec umožňuje prijímať trasy.

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

Prvý príkaz zobrazuje zoznam partnerov a to, či je router podsiete dostupný, druhý vypisuje predvoľby klienta vrátane príznaku prijímania trás a tretí sa pýta jadra, ktoré rozhranie by použilo pre skutočného hostiteľa v podsieti. Ak posledný príkaz uvedie fyzické rozhranie namiesto rozhrania Tailscale, trasa sa do tabuľky nikdy nedostala. Chýbajúca trasa je problém na strane klienta, nie problému schválenia. Opravte ju, kým sa pozriete na politiku.

Ak chcete v Linuxe prijímať trasy, pripojte sa znova s príznakom, namiesto toho, aby ste predpokladali, že je nastavený: tailscale up --accept-routes. Klient pripojený s inými príznakmi si ich ponechá, kým sa nezmenia, preto pred pridaním ďalšieho skontrolujte aktuálne nastavenie. Opätovné spustenie prvého príkazu po zmene by malo zobraziť trasu v tabuľke.

Dokážte preposielanie a spiatočnú cestu

Schválenie nenastavuje router na preposielanie paketov a nezariaďuje odpoveď. Oboje sú záležitosti na úrovni hostiteľa na strane LAN routera. Testujte ich na routeri, nie na klientovi.

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

Prvý príkaz musí hlásiť 1, inak jadro preposielaný paket zahodí. Druhý ukazuje, či maskovanie trasy podsiete prepisuje zdroj, čo je predvolené správanie a zvyčajne to, čo chcete. Tretí ukazuje, či požiadavka dorazí k cieľu a či sa niečo vracia; požiadavka bez odpovede je problém spiatočnej cesty, nie schválenia. Prečítajte si tri výsledky spolu, kým niektorý z nich zmeníte.

Ak je maskovanie vypnuté, cieľová sieť potrebuje trasu späť k adresám tailnetu a každý skok medzi tým to musí vedieť. Opätovné zapnutie maskovania je najrýchlejšia oprava pre jednu službu, ale za cenu skrytia pôvodnej adresy klienta pred cieľom. Tento kompromis je dôležitý, keď cieľ zaznamenáva zdrojové adresy na audit, preto ho rozhodnite vedome, namiesto prepínania príznaku počas incidentu. Zdokumentujte, ktorú možnosť ste zvolili, pretože ďalší človek uvidí len jedno z dvoch správaní.

Prečítajte si prístupové pravidlo pre prostriedok

Keď je trasa prítomná a preposielanie preukázané, zostávajúcim podozrivým je politika. Prečítajte si povolenie, ktoré má spojenie povoliť, a skontrolujte jeho cieľ, nielen zdroj. Identita samotného klienta musí tiež zodpovedať selektoru politiky, preto ju zachyťte na tom istom stroji, ktorý zlyháva.

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

Výstup stavu identifikuje vlastné adresy klienta a partnerov, ktoré vidí, a s tým musí selektor zdroja politiky zodpovedať. tailscale ping preukazuje cestu tailnetu k samotnému routeru podsiete; prekladá mená partnerov a adresy tailnetu, nie hostiteľov v inzerovanej podsieti. Tretí príkaz posiela bežné ICMP echo cez trasu podsiete, takže jeho výsledok opisuje cieľ, nie router. Odmietnutie na úrovni tailnetu sa zvyčajne vráti ako odmietnutie, kým paket, ktorý odíde a nikdy sa nevráti, skončí vypršaním času.

Zlyhávajúce meno je iná otázka ako zlyhávajúca adresa; preložte hostiteľa priamo, kým obviníte trasu. Píšte povolenie podľa skutočnej potreby prostriedku, nie podľa celej podsiete. Otvoriť celú /24, aby jedna aplikácia fungovala, je cesta, ktorou sa úzka požiadavka stane širokým povolením, ktoré si potom nikto netrúfne odobrať.

Ak bolo cieľom vyjdenie do internetu a nie privátna podsieť, správnym komponentom je výstupný uzol, nie router podsiete, a politika aj smerovanie sa podľa toho líšia. Skontrolujte toto rozhodnutie, kým rozšírite povolenie. Výstupný uzol mení predvolenú trasu; router podsiete iba inzeruje prefix.