Jak odlišit trasy vnucené VPN od statických v Linuxu

Prefix se na notebooku objeví, když se tunel zvedne, takže to vypadá, že ho nainstaloval VPN. Možná ano, ale stejný výsledek může přijít od klientského skriptu, který se spouští při připojení, od profilu připojení, který uvádí podsíť, nebo od statické trasy, která tam byla celou dobu a začala fungovat až tehdy, když rozhraní existovalo. Volba špatného vlastníka znamená, že se trasa po každém úklidu vrátí a další člověk opakuje stejnou opravu. Následující postup tyto tři oddělí dřív, než se cokoli změní.

Krok 1: pojmenujte mechanismus, který instaluje prefixy

Různé protokoly zajišťují dostupnost různými způsoby a nazývat to všechno oznámením skrývá rozdíl. Server OpenVPN vnucuje direktivu trasy přes řídicí kanál a klient ji nainstaluje, pokud ji nezablokuje pull filtr. Konfigurace WireGuard uvádí povolené prefixy lokálně a klient je používá jak pro směrování kryptoklíčů, tak pro trasy, které přidává. Tunel IPsec se s protějškem dohodne na selektorech provozu a jádro z těchto selektorů instaluje trasy.

Než začnete číst jakoukoli tabulku, určete, který z nich váš tunel používá. Trasa vnucená při připojení není oznámením směrovacího protokolu a neslibuje, že prefix je za vzdáleným koncem dostupný. Poznamenejte mechanismus vedle prefixu, protože rozhoduje o tom, kam oprava patří.

Krok 2: porovnejte tabulku napříč připojením

Uložte hlavní tabulku se spuštěným tunelem dolů, zvedněte ho, uložte ji znovu a porovnejte oba snímky. Vše, co se objevilo, patří k životnímu cyklu připojení, a vše, co zůstalo, patří k místní konfiguraci.

Zachyťte ji pomocí ip route show table main > /tmp/route-down.txt, připojte se a zachyťte znovu. Totéž udělejte pro ip -6 route, pokud lokalita používá IPv6, protože chybějící prefix tam vytváří poruchy, které vypadají nesouvisející se směrováním.

Krok 3: čtěte metriku, ne jen přítomnost

Dva záznamy pro stejný prefix mohou existovat vedle sebe a jádro vybírá nižší metriku. Statická trasa s metrikou 50 bude dál porážet vnucenou trasu se 100, i když jsou obě viditelné, a proto „trasa tam je“ a „provoz ji používá“ jsou různá tvrzení.

Zeptejte se jádra přímo pomocí ip route get 10.20.5.7 a přečtěte rozhraní, které uvede. Pokud provoz odchází přes fyzický adaptér, zatímco v tabulce leží trasa tunelu, vysvětluje to metrika nebo délka prefixu, ne klient VPN. Zopakujte dotaz pro hostitele, o kterém víte, že je za tunelem, a pro toho, o kterém víte, že není, a rozdíl ukáže, zda se rozdělení chová podle záměru.

Krok 4: najděte záznamy, které tunel přežijí

Statické trasy přežívají odpojení podle návrhu a odtud pocházejí zastaralé záznamy. Trvalá trasa ukazující na rozhraní, které už neexistuje, může podsíť tiše pohltit, a trasa na znovupoužité jméno rozhraní může po restartu poslat soukromý provoz špatnými dveřmi.

Zkontrolujte trvalou stranu na místě, které používá vaše distribuce, ať už je to jednotka systemd-networkd, profil NetworkManageru nebo skript v klientském adresáři up. Oprava živé tabulky pomocí ip route del vydrží jen do dalšího připojení. Berte to smazání jako test hypotézy, ne jako opravu.

Když vzdálený konec poskytuje špatné pokrytí, řešte to s operátorem, místo abyste filtrovali všechno. Zahození všech vnucených nastavení zahazuje i DNS a politiku rozděleného tunelu, na kterých profil závisí.

Krok 5: potvrďte zpáteční cestu, než obviníte klienta

U spojení lokalita-lokalita nebo podsítě za tunelem potřebuje vzdálená strana trasu zpět na adresu vašeho klienta a zapnuté předávání na bráně. Jednosměrná cesta vypadá přesně jako chyba směrování na klientu, jenže handshake i odchozí paket uspějí.

Filtrování zpětné cesty přidává na linuxových bránách druhou past. Odpověď, která dorazí na jiné rozhraní, než trasa předpovídá, je v přísném režimu zahozena, a asymetrické cesty přes dva poskytovatele to spolehlivě spouštějí. Počítadla zahození na bráně, ne na klientu, řeknou, zda je příčinou filtrování.

Krok 6: testujte zdroj, ne ping

Jakmile je zvolená trasa správná, otevřete skutečný zdroj a potvrďte zpětný provoz. Odpověď na ping dokazuje cestu jedním směrem a nic o službě, a služba odpovídající na kešované spojení dokazuje ještě méně.

Pak celou kontrolu zopakujte po opětovném připojení. Hodnota postupu je v tom, že předpovídá, co udělá příští připojení, a proto do tiketu patří srovnání i metrika.