Proč schválená trasa podsítě v Tailscale stále končí vypršením času

Schválení v administrační konzoli vypadá jako poslední krok, ale není. Nejprve aplikaci vyprší čas, a teprve potom zjistíte, že je router online a trasa schválená. Schválení je krok distribuce, nikoli oprávnění a nikoli záruka předávání. Čtyři fáze se musí sejít, než paket dorazí k hostiteli za routerem podsítě, a každá může uspět, zatímco následující selže. Projděte je popořadě a zastavte se u první fáze, která neobstojí.

Čtyři fáze, jedno selhání

Router inzeruje prefix, tailnet toto oznámení schválí, klient přijme trasu, kterou dostal, a přístupová politika povolí konkrétní spojení. To jsou čtyři oddělená rozhodnutí, která činí tři různé komponenty. Schválená trasa proto říká jen, že síť je nyní součástí směrovací tabulky tailnetu.

Čtvrtá fáze je ta, která se nejčastěji přeskakuje, protože první tři dávají viditelný stav. Oprávnění, které pokrývá vlastní adresu routeru v tailnetu, automaticky nepokrývá privátní podsíť za ním. To jsou různé cíle a politika se vyhodnocuje pro každý cíl zvlášť.

V Linuxu má třetí fáze také výchozí chování, které lidi překvapí: přijímání tras podsítí je volitelné. Několik GUI klientů přijímá inzerované trasy ve výchozím nastavení, takže smíšená flotila může ukázat jeden selhávající stroj, zatímco ostatní fungují.

Ověřte předvolbu na selhávajícím stroji, místo abyste předpokládali platformu. Trasa nikdy nebyla chybějícím dílkem na fungujících strojích, takže ať ony prokážou, že strana tailnetu je zdravá. Dokumentace Tailscale k routerům podsítí pokrývá schválení, přijetí tras klientem a fázi politiky.

Zkontrolujte trasu tam, kde běží klient

Začněte u klienta, který selhává, ne u routeru. Potvrďte, že trasa existuje a že předvolba klienta vůbec dovoluje přijímat trasy.

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

První příkaz ukazuje seznam protějšků a zda je router podsítě dosažitelný, druhý vypíše předvolby klienta včetně příznaku přijímání tras a třetí se ptá jádra, které rozhraní by použilo pro skutečného hostitele v podsíti. Pokud poslední příkaz uvede fyzické rozhraní místo rozhraní Tailscale, trasa se do tabulky nikdy nedostala. Chybějící trasa je problém na straně klienta, ne problém schválení. Opravte ji, než se podíváte na politiku.

Chcete-li v Linuxu přijímat trasy, připojte se znovu s příznakem, místo abyste předpokládali, že je nastaven: tailscale up --accept-routes. Klient připojený s jinými příznaky si je ponechá, dokud se nezmění, takže před přidáním dalšího zkontrolujte současnou předvolbu. Opětovné spuštění prvního příkazu po změně by mělo trasu v tabulce ukázat.

Prokažte předávání a zpáteční cestu

Schválení nenastaví router, aby předával pakety, a nezařídí odpověď. Obojí jsou záležitosti na úrovni hostitele na straně LAN routeru. Testujte je na routeru, ne 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

První příkaz musí hlásit 1, jinak jádro předávaný paket zahodí. Druhý ukazuje, zda maskarádování trasy podsítě přepisuje zdroj, což je výchozí chování a obvykle to, co chcete. Třetí ukazuje, zda požadavek dorazí k cíli a zda se něco vrací; požadavek bez odpovědi je problém zpáteční cesty, ne schválení. Přečtěte si tři výsledky společně, než některý z nich změníte.

Pokud je maskarádování vypnuté, cílová síť potřebuje trasu zpět k adresám tailnetu a každý skok mezi tím to musí vědět. Opětovné zapnutí maskarádování je rychlejší oprava pro jednu službu, za cenu skrytí původní adresy klienta před cílem. Tato výměna je důležitá, když cíl zaznamenává zdrojové adresy pro audit, takže rozhodněte vědomě, místo abyste příznak přepínali během incidentu. Zdokumentujte, kterou možnost jste zvolili, protože další člověk uvidí jen jedno ze dvou chování.

Přečtěte si přístupové pravidlo pro prostředek

Když je trasa přítomná a předávání prokázané, zbývajícím podezřelým je politika. Přečtěte si oprávnění, které má spojení povolit, a zkontrolujte jeho cíl, ne jen zdroj. Identita samotného klienta musí odpovídat selektoru politiky, takže ji zachyťte na stejném stroji, který selhává.

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 protějšky, které vidí, a s tím musí selektor zdroje politiky odpovídat. tailscale ping prokazuje cestu tailnetu k samotnému routeru podsítě; překládá jména protějšků a adresy tailnetu, nikoli hostitele uvnitř inzerované podsítě. Třetí příkaz posílá běžné ICMP echo přes trasu podsítě, takže jeho výsledek popisuje cíl, ne router. Odmítnutí na úrovni tailnetu obvykle přichází jako odmítnutí, zatímco paket, který odejde a nikdy se nevrátí, vyprší.

Selhávající jméno je jiná otázka než selhávající adresa; přeložte hostitele přímo, než obviníte trasu. Pište oprávnění podle skutečného požadavku prostředku, ne podle celé podsítě. Otevřít celou /24, aby jedna aplikace fungovala, je způsob, jak se úzký požadavek stane širokým oprávněním, které si pak nikdo netroufne odebrat.

Pokud byl cílem výstup do internetu, a ne privátní podsíť, správnou komponentou je výstupní uzel, ne router podsítě, a politika i směrování se podle toho liší. Zkontrolujte toto rozhodnutí, než oprávnění rozšíříte. Výstupní uzel mění výchozí trasu; router podsítě pouze inzeruje prefix.