Vypněte zdrojový NAT na směrovači podsítě Tailscale a tunel funguje dál, zatímco spojení přes něj přestanou. Požadavky dorazí do cíle s vlastní overlay adresou vzdáleného klienta, což je přesně smysl změny, a odpovědi teď potřebují cestu, kterou LAN nikdy nemusela znát. Bez této cesty pakety přistanou, odpovědi odejdou přes běžnou bránu a porucha se jeví jako problém firewallu, který žádné pravidlo firewallu nevysvětluje. Tunel je zdravý; zpáteční větev chybí.

Co SNAT skrýval

Při zapnutém SNAT přepisuje směrovač zdrojovou adresu na svou vlastní LAN adresu před předáním do podsítě, takže cíl odpovídá hostiteli, ke kterému už ví, jak se dostat, a nic dalšího není třeba konfigurovat. Vypnutí zachová původní zdroj a cíl pak vidí adresu v rozsahu overlaye, nikoli souseda na vlastním drátu. Tato adresa je skutečná a směrovatelná v rámci tailnetu, ale z LAN přes výchozí bránu je nedostupná. Dokumentovaný přepínač je --snat-subnet-routes=false, aplikovaný na samotný Linux směrovač podsítě.

Je to trvalé nastavení, nikoli přepínač pro každý paket, takže zpáteční cesta musí existovat pro každou cílovou síť, kterou tento směrovač obsluhuje. Právě proto je změna rozhodnutím o nasazení, a ne zaškrtávacím políčkem. Vše, co tento směrovač obsluhuje, zdědí požadavek ve stejný okamžik.

Kde může zpáteční cesta žít

Tři umístění jsou běžná a liší se dosahem, nikoli správností. Statická trasa na cílovém hostiteli je nejpřímější a nejméně škálovatelná, protože každé zařízení potřebuje vlastní kopii. Směrovací tabulka ve VPC nebo na směrovači lokality pokrývá celou síť najednou a volba DHCP s beztřídními statickými trasami se dostane ke klientům automaticky, ale tiše selže na zařízeních, která ji ignorují.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

Ať zvolíte kterékoli umístění, další hop je LAN adresa směrovače a nikdy jeho adresa v tailnetu. Hostitel v LAN se k overlayi nedostane, dokud tuto trasu nemá, takže další hop uvnitř overlaye je kruhový a pošle paket nikam. Právě tato jediná chyba vysvětluje většinu konfigurací, které vypadají správně a přesto selhávají, a přežije každou kontrolu, která čte jen tabulku samotného směrovače. Zapište, které umístění jste použili, protože jinak příští člověk otestuje to špatné.

Čtení poruchy jako jednosměrného provozu

Příznak se pozná snadněji než příčina: služba odpovídá na samotném směrovači a mlčí od vzdáleného klienta. Zachycení na cíli ukazuje přicházející požadavky a odcházející odpovědi, což vypadá jako úspěch, dokud si nevšimnete, kam ty odpovědi míří. Jdou k výchozí bráně, což znamená, že příchozí větev fungovala a zpáteční ne.

Zachycujte raději na směrovači, protože vidí oba směry jedné výměny a ukáže, zda odpověď vůbec dorazila. Pokud se odpověď objeví na cíli, ale nikdy na směrovači, trasa na straně cíle chybí nebo je špatná. Pokud se objeví na směrovači a tam se zastaví, problém je dál a patří k jinému vyšetřování.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Stojí skutečná adresa za trasu

Zachování SNAT zůstává jednodušší odpovědí, kdykoli cílovou síť nelze překonfigurovat, a cenou je, že každý klient vypadá v logech a politice cíle jako směrovač. Vypnutí je opodstatněné, když aplikace potřebuje skutečnou zdrojovou adresu nebo když síťová politika musí rozlišovat klienty, kteří sdílejí směrovač. Oba důvody jsou legitimní a ani jeden není zdarma. Přínos musí stát za udržováním trasy v každé cílové síti plus za revizí firewallu popsanou níže.

U jedné malé LAN se výměna obvykle vyplatí, zatímco u roztroušených zařízení, která nemohou přijmout statickou trasu, obvykle ne. Zapište rozhodnutí a důvod vedle konfigurace směrovače, aby příští správce věděl, které chování je záměrné. Výchozí stav, který nikdo nezapsal, nelze rozeznat od opomenutí.

Firewall, protokolování a zdvojená role

Každé pravidlo, které odpovídalo LAN adrese směrovače, nyní odpovídá jinému zdroji, včetně pravidel povolení a každého pole protokolu, které zaznamenávalo směrovač jako klienta. Přečtěte si tato pravidla před prvním testem, ne po prvním selhání, protože pravidlo povolující jen adresu směrovače nový zdroj zcela zablokuje. Zúžte náhradu na klienty a porty, které ji potřebují, a pak potvrďte, že tiše nepouští celý tailnet.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

Jeden uzel sloužící zároveň jako výstupní uzel i směrovač podsítě je dokumentovaná kombinace, která může po vypnutí SNAT podsítě zahazovat provoz směrem nahoru. Rozdělení těchto rolí na různé uzly tuto výhradu odstraní a dá každé trase a politice firewallu jediného vlastníka. Pokud role musí zůstat spolu, očekávejte takové chování a otestujte je, než obviníte klienta. Držte trasu, nastavení přepínače a přidělení rolí v jedné poznámce, protože se čtou společně, když příští spojení selže.

Související články