WAN IP se změnila a tunel spadl: kontroly v pořadí

Tunel spadne, router zaprotokoluje opětovné připojení a v místní síti se nic nepohnulo. Nová adresa WAN zneplatní vnější spojení, aniž by uvnitř cokoli změnila: zdrojová adresa klienta se změnila, starý stav NAT ukazuje na zdroj, který už neexistuje, a vzdálený partner může stále posílat na předchozí adresu. Obnova je normální chování a užitečná otázka je, který stav se neaktualizoval.

Pojmenujte událost, než začnete číst log

Zkontrolujte, co se skutečně stalo na přístupové vrstvě. Obnovení nájmu od poskytovatele je jedna událost. Znovu připojená relace PPPoE je jiná. Restartovaný optický modem nebo přepnutí WAN z jednoho uplinku na druhý mění vnější adresu nebo její cestu třetím způsobem. Nejsou to stejné události a nezanechávají stejné zbytky.

Řádek opětovného připojení v logu VPN také není důkazem změny WAN. Časový limit nečinnosti, interval opětovného ověření a detekce mrtvého partnera všechny vytvářejí opětovná připojení bez jakékoli změny adresy. Před jakýmkoli závěrem porovnejte časová razítka z přístupového logu s logem VPN a okno porovnání držte dost široké, aby zachytilo změnu, která nastala v noci.

Roaming a opětovné připojení jsou různé protokoly

WireGuard má ověřený roaming zabudovaný v protokolu: když partner obdrží správně ověřený paket z nové zdrojové adresy, aktualizuje koncový bod tohoto partnera. Stručný úvod do WireGuardu popisuje konfiguraci partnera, která to umožňuje, a proto se klient na měnící se adrese často zotaví bez viditelného restartu.

OpenVPN se ve výchozím nastavení chová jinak. Relace UDP může skončit a znovu se připojit a volitelné chování float umožňuje ověřenému partnerovi pokračovat z nové adresy tam, kde to konfigurace dovoluje. Tunely založené na TCP jsou přísnější, protože samotné spojení je vázáno na dvojici adres. Tento rozdíl rozhoduje o tom, zda obnova vypadá neviditelně, nebo se pokaždé oznámí v logu.

Ani jedno chování nic neříká o aplikacích uvnitř. Obnovený tunel neobnoví relaci TCP, kterou partner už považoval za mrtvou.

Stav, který tunel nevlastní

Stav překladu a směrování přežije opětovné připojení způsoby, které lidi překvapují. Záznam conntrack vytvořený pro starý zdroj drží cestu odpovědi ukotvenou na adrese, která už neexistuje, a vyprší podle vlastního plánu, ne když se tunel vrátil. Restart služby tunelu tuto čekací dobu nezkrátí, takže opravené spojení může ještě chvíli vypadat rozbité.

Trasy a pravidla zásad mohou odkazovat na starou bránu nebo rozhraní. Sada pravidel, která byla správná před přepnutím WAN, může ukazovat na zařízení, které je nyní mimo provoz, což vytváří tunel, který hlásí připojení, a provoz, který nikam nejde. Dynamické DNS pro server, který hostujete, je samostatný problém od klienta získávajícího nový zdroj. Záznam je třeba aktualizovat, aby vás vzdálení klienti našli, a žádná konfigurace na straně klienta nevykompenzuje adresu, kterou překlad výše po proudu nepředá.

Seřaďte kontroly zvenčí dovnitř

Pořadí níže jde od vnějšího připojení dovnitř a právě zastavení u prvního neúspěšného kroku ho činí užitečným: každý průchod vylučuje vrstvu nad sebou. Toto pořadí dodržte, i když porucha vypadá zjevně.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

První příkaz ukazuje aktuální koncový bod a stáří handshake pro každého partnera. Druhý a třetí ukazují, zda vnější rozhraní a trasa ke koncovému bodu ještě dávají smysl. Počet conntrack je hrubá kontrola stavu zbylého z předchozí adresy a log je místo, kde se zaznamenává důvod opětovného připojení.

Potom testujte z klienta v místní síti, ne z routeru. Ping odeslaný samotným routerem používá jinou cestu než přeposílaný provoz, takže úspěšný ping z routeru dokazuje existenci tunelu a nic o dostupnosti klienta.

Rozhodněte očekávané chování a zapište ho

Opětovné připojení je správné chování pro většinu nasazení, takže cílem není mu zabránit. Rozhodněte místo toho, co se má s provozem během mezery stát: zastavit ho, podržet, nebo přejít na jinou cestu. To rozhodnutí patří do firewallu a směrovací politiky, ne do profilu VPN.

Zaznamenávejte přístupové události a časy opětovného připojení společně po dobu jednoho týdne. Opakované změny bez odpovídající přístupové události ukazují na přístupovou službu a nahrazení profilu VPN neopraví uplink, který stále znovu vyjednává. Jediná dvojice záznamů ve stejné minutě vyřeší otázku pro tento incident a dá dalšímu výchozí bod.