Vaše stará výchozí trasa po OpenVPN záměrně zůstává

Připojíte tunel, spustíte ip route a původní výchozí brána tam stále je. První myšlenka je, že klient trasu nepřevzal, takže výchozí trasu smažete ručně a úplně ztratíte spojení. Tento záznam má zůstat. S redirect-gateway def1 OpenVPN nainstaluje dvě konkrétnější trasy, které předčí běžnou výchozí trasu, místo aby ji nahradily. Stará brána zůstává a přestává přenášet provoz, který jste testovali.

Co def1 skutečně dělá

Příznak přidá 0.0.0.0/1 a 128.0.0.0/1, obě směřující do tunelu. 0.0.0.0/1 pokrývá každou adresu, jejíž první oktet je 0 až 127, a 128.0.0.0/1 pokrývá 128 až 255, takže každý cíl IPv4 má shodu konkrétnější než stará výchozí trasa. O tom, která trasa vyhraje, rozhoduje délka prefixu, ne metrika.

Ponechat původní výchozí trasu na místě je záměr. Klient si nemusí pamatovat, co nahradil, a nepřepisuje trasu, která nese jeho vlastní spojení k serveru VPN. Při odpojení odstraní dvě poloviční trasy a tabulka se vrátí do původního stavu.

Proč /1, a ne /0

Směrování volí nejdelší odpovídající prefix, ne nejnižší metriku, takže /1 porazí /0 bez ohledu na to, co říká metrika výchozí trasy. Obě poloviny existují proto, že jeden /1 pokrývá jen polovinu prostoru; když je přítomna jen 0.0.0.0/1, všechno od 128.0.0.0 výš stále sleduje starou výchozí trasu, což dává matoucí příznak: některé weby fungují a jiné ne.

Zvýšení nebo snížení metriky staré výchozí trasy nic nezmění a výchozí trasa s nižší metrikou na jiném rozhraní provoz také neukradne. Nejprve rozhoduje délka prefixu a na metriku se sáhne jen u stejných prefixů.

Přečtěte si skutečnou směrovací tabulku

Připojený host může ukázat všechny tři záznamy najednou, přičemž tunel nese poloviny a původní brána je stále v seznamu. Adresy jsou příklady, ne konfigurace ke kopírování, protože názvy rozhraní, topologie tunelu a další trasy se liší podle platformy a klienta.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

Důležitý je vztah: dvě konkrétní poloviny nad jednou obecnou výchozí trasou. Řádek staré brány zůstává, protože ho nic nenahradilo.

Ověřte, kterou trasu paket skutečně použije

Konkrétnější trasy mohou stále vyhrát: trasa pro soukromý rozsah, místní podsíť nebo vlastní adresa serveru VPN je delší než /1. Tunel potřebuje vnější cestu ke svému serveru a poslání tohoto spojení zpět do tunelu by ho okamžitě rozbilo. V Linuxu se ptejte jádra, místo abyste tabulku četli od oka: ip route get s cílem, který vás zajímá, vypíše zvolenou trasu, rozhraní a zdroj. Pokud je nastaveno směrování podle politik, prohlédněte i pravidla, protože pravidlo může vybrat jinou tabulku dřív, než se použije hlavní.

Pokud se špatně chová jen část IPv4, potvrďte, že jsou nainstalované obě poloviny, a pak hledejte výjimku odpovídající selhávajícímu cíli. Smazání staré výchozí trasy není řešení a odebere trasu, kterou klient potřebuje k čistému rozpojení tunelu.

Co def1 nepokrývá

Dva záznamy IPv4 neříkají nic o IPv6: host s konektivitou IPv6 dál používá svou výchozí trasu, dokud něco tuto rodinu neodkloní zvlášť, a proto v síti s duálním zásobníkem část provozu vypadá, jako by obcházela tunel. Jiní klienti a správci sítí implementují směrování celého tunelu jinak a jejich tabulky se nebudou shodovat. Zde popsané chování def1 patří dokumentovanému příznaku OpenVPN, ne každé VPN na stroji.

Kill switch odpovídá na jinou otázku: co stroj udělá, když tunel spadne. Priorita tras rozhoduje, kam provoz jde, dokud je tunel nahoře; nerozhoduje, co potom udělá firewall. Pořadí práce: přečtěte tabulku, potvrďte, že obě poloviny existují, spusťte ip route get pro selhávající cíl, zkontrolujte pravidla politik a pak se zvlášť podívejte na IPv6. Nechte starou výchozí trasu tam, kde je.