OpenVPN spadne po obnovení DHCP: udržte trasu k cílovému bodu

Tunel se připojí, pak ho obnovení pronájmu na přístupovém spoji zabije a log viní timeout, ne trasu. V konfiguraci VPN se nic nezměnilo, a to je ta stopa: změnilo se něco mimo ni. Událost DHCP přepsala adresu nebo bránu, a hostitelská trasa, která držela cílový bod tunelu dostupný, teď ukazuje na další skok, který už neexistuje. Tohle je problém vlastnictví dřív, než je problém routování.

Porovnejte příznak s polovinami výchozích tras

S redirect-gateway def1 nainstaluje OpenVPN 0.0.0.0/1 a 128.0.0.0/1 místo nahrazení výchozí trasy. Obě dohromady pokrývají celý adresní prostor a přebíjejí 0.0.0.0/0 už jen délkou prefixu. Proto každé cílové místo bez konkrétnější shody vstoupí do tunelu.

Cílový bod potřebuje výjimku. OpenVPN přidá hostitelskou trasu k adrese serveru přes původní přístupovou bránu dřív, než se poloviny výchozích tras zapíšou, aby zapouzdřené pakety mohly odejít. Když tato výjimka zmizí, nebo si podrží další skok, který už neexistuje, vlastní vnější pakety tunelu odpovídají polovině výchozí trasy a pošlou se zpět do tunelu. Výsledkem je spojení, které umře při dalším keepalive nebo handshake, a v logu není nic, co by vypadalo jako chyba routování.

Potvrďte tvar tabulky, než sáhnete na cokoli jiného. ip route show by měl vypsat obě poloviny plus hostitelskou trasu k adrese serveru; když hostitelská trasa chybí, má zbytek vyšetřování zřejmý výchozí bod.

Proč poloviny výchozích tras vyhrají bez změny metriky

Nižší metrika nepřekoná delší prefix. Trasy /1 vyhrají, protože jádro nejdřív páruje nejkonkrétnější trasu, takže zvýšení metriky na výchozí trase nic nemění na tom, kam provoz směřující do tunelu jde. Honění metrik je v této diagnostice nejčastější špatné odbočení.

Zkontrolujte volbu pomocí ip route get 203.0.113.10, dosaďte skutečnou adresu serveru. Odpověď pojmenuje rozhraní a další skok, které by jádro skutečně použilo, což je informativnější než číst tabulku a uvažovat o ní.

Spusťte ten příkaz před startem tunelu, když běží, a po události pronájmu. Tři odpovědi z jednoho příkazu a bod rozdílu je vidět.

Udělejte tři snímky, ne jeden

Seberte přístupovou adresu, přístupovou bránu, cíl cílového bodu, zvolenou trasu a všechna pravidla zásad ve třech okamžicích: po konfiguraci přístupového spoje, po připojení VPN a po události pronájmu nebo operátora. Každý snímek je hrstka příkazů a smysl mají jen společně. Jeden snímek po selhání zaznamená stav, ne přechod. Zapište příkazy do malého skriptu, aby se každý snímek pořizoval stejně.

Držte snímky v jednom souboru s časovými značkami, protože zajímavá otázka později je pořadí. Přišla událost DHCP předtím, nebo poté, co OpenVPN obnovil svou trasu? Odpověď rozhoduje, kdo to musí opravit. Časová značka ze špatných hodin je horší než žádná, takže ji berte z hostitele, který vlastní routovací tabulku.

Když je cílový bod nakonfigurován jako jméno místo adresy, rozlište ho i v každém snímku. Změna DNS na přístupovém spoji může posunout cílový bod, aniž by se jakákoli trasa vůbec dotkla.

Rozhodněte, která komponenta výjimku obnovuje

V systému s dhcpcd se háčky spouštějí z adresáře háčků a z výstupního háčku, a režim správce se rozsahem liší od režimu pro jednotlivé rozhraní. Ať háček dělá cokoli, musí být idempotentní, protože obnovení mohou přicházet v dávkách.

Spolehlivý vlastník je integrace, která už zná obě strany: správce sítě, který spravuje připojení VPN, nebo unit seřazený až po nahození přístupového spoje. Statická trasa přidaná háčkem funguje do další změny brány, a pak selže úplně stejným způsobem. Pokud háček přesto použijete, přinuťte ho číst aktuální bránu za běhu, místo aby pevně kódoval tu, kterou jste viděli dnes.

Zaznamenejte vlastníka uvnitř konfigurace. Další člověk, který bude ladit opětovné připojení, musí vědět, že za výjimkovou trasu odpovídá háček, ne VPN.

Testujte životní cyklus, ne jen opětovné připojení

Vynuťte obnovení pomocí dhcpcd -n eth0 nebo uvolněním a novým získáním pronájmu, pak znovu zkontrolujte ip route get pro cílový bod. Udělejte to dvakrát, protože druhý běh zachytí háčky, které přidávají duplicitní trasy. Potom restartujte, protože trvalost je jiná vlastnost než správnost.

Tunel, který přežije obnovení i restart, má vlastníka a fungující výjimku. Ten, který přežije jen ruční restart, nemá ani jedno, a selže při další události, kterou nedokážete naplánovat.