Proč trasa plného tunelu odřízne server, který ji nese

Zapněte plný tunel a každé cílové umístění nyní patří rozhraní VPN, včetně stroje, který jej ukončuje. Vnější pakety nesoucí tunel jsou adresovány tomuto stroji, takže trasa nakonec spotřebovává transport, na kterém závisí. Jedna další konkrétní trasa to řeší a ten důvod stojí za pochopení. Bez něj příští přestavba znovu zavleče závadu.

Trasa, která požírá vlastní transport

Zapouzdření obalí každý paket druhou hlavičkou. Vnější je adresována z místní fyzické adresy na veřejnou adresu serveru a musí projít fyzickým spojem, než může existovat jakýkoli tunel.

Teď nechte vyhledání této veřejné adresy vybrat tunel. Aby stroj paket odeslal, musí jej zapouzdřit, což vyžaduje trasu na stejnou adresu, která vrací tunel. Klienti to řeší jedním ze dvou způsobů. Opatrný odmítne nainstalovat výchozí trasu a ohlásí chybu, zatímco méně opatrný ohlásí úspěch a pak nic nepřesune. Tiché selhání je to, které stojí odpoledne.

Shoda nejdelšího prefixu rozhoduje o vyhledání dřív, než se vezme v úvahu jakákoli metrika, takže trasa na jednu adresu převyšuje každou výchozí trasu na stroji. To je celý mechanismus opravy.

Nainstalujte výjimku před výchozí trasou

Vytvořte trasu na jednu adresu pro server, s fyzickou bránou jako dalším skokem, dřív než se výchozí trasa pohne. Na pořadí záleží: instalace potom znamená žít s rozbitým tunelem, dokud píšete.

Většina klientů to dělá bez vyzvání. OpenVPN vyhledá vzdálenou adresu a připne ji, než přepíše výchozí bránu, a jeho volba route-delay existuje pro platformy, kde se tento sled závodí. wg-quick jde úplně jinou cestou, označuje pakety a obrací se na pravidlo zásad místo přidání výjimky. Různé mechanismy, stejný požadavek: vnější paket musí uniknout tunelu, který vytváří.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Výstup vyhledání je přijímací test. Musí pojmenovat fyzické zařízení a fyzického dalšího skoku. Tunelové zařízení v této odpovědi znamená, že výjimka chybí, nebo byla umístěna za něčím, co ji přebíjí.

Zrcadlový obraz na serveru

Stejná past čeká na druhé straně, obráceně. Dejte serveru výchozí trasu přes jiný tunel, nebo mu pošlete trasu pokrývající veřejné adresy klientů, a jeho odpovědi získají návyk jít špatným směrem.

Představte si klienta, který se připojí a pošle požadavek. Odpověď je adresována na veřejnou adresu tohoto klienta, která nyní odpovídá tunelové trase, takže vychází z jiného rozhraní a nese zdroj, který klient nikdy nevolal. Klient může tento paket přijmout a přesto jej zahodit, protože nic jej nepojí s požadavkem, který odeslal. Vycházejte z rozhodnutí serveru o směrování, ne z časového limitu klienta, protože jen jedno z nich ukazuje skutečnou volbu.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Existují tři opravy a nejsou rovnocenné. Připnutí služby k fyzické adrese nebo překlad zdroje obojí skrývá rozhodnutí o směrování místo toho, aby je opravilo. Odesílání odpovědního provozu pro tunelový fond přes vyhrazenou tabulku opravuje příčinu a zbývající dvě jsou přijatelné jen dokud je návrh směrování zmrazen.

Výjimky, které tunel neustále krade

Hrstka úloh potřebuje otevřený internet, i když tunel vlastní výchozí trasu, a každá potřebuje vlastní výjimku. Aktualizátor dynamického DNS se obvykle rozbije první.

Přeloží poskytovatele, otevře spojení a zjistí, že jeho vlastní pakety putují tunelem, jehož adresa se změnila před několika sekundami, takže aktualizace selže nebo zveřejní špatnou adresu. Tři východiska: připněte poskytovatele trasou k hostiteli přes fyzickou bránu, spusťte aktualizaci před tím, než tunel vstane, nebo dejte aktualizátoru tabulku zásad, na kterou tunel nikdy nesáhne. Synchronizace času má stejnou expozici na zařízení, které startuje bez resolveru, a koncové body pro ověřování certifikátů patří na seznam ze stejného důvodu.

Výjimka, kterou nikdo nezapsal, je výjimka, kterou příští přestavba tiše zahodí.

Dokažte to po opětovném připojení, ne před ním

Otestujte tři cíle, ne jeden: koncový bod, soukromou adresu za tunelem a veřejnou adresu za ním. Jediné úspěšné vyhledání neříká o zbývajících dvou téměř nic.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Potom restartujte připojení, protože klient, který při opětovném připojení přestaví svou tabulku, zahodí trasu, kterou jste napsali ručně. Pokud je v hře kill switch, zkontrolujte, že je koncový bod povolen, jinak se tunel po změně sítě nemůže vrátit a symptom vypadá jako výpadek. Uložte výjimku do profilu nebo do unit souboru místo do historie shellu, aby ji opětovné připojení znovu vytvořilo, místo aby ji smazalo.