Zaseknutá VPN po restartu routeru: tři věci, které se změnily

Router dokončí start, notebook se znovu připojí ke stejné SSID a VPN zůstane ve stavu připojeno, aniž by se něco hýbalo. Uložený profil je v pořádku. Co pod ním vypršelo, byla cesta, a klient si stále drží stav, který si pro tu starou postavil.

Opravu určují tři podmínky. Kontrolujte je v pořadí, protože pozdější jsou zbytečná práce, pokud ta první už zaseknutí vysvětluje.

První podmínka: lokální adresa se změnila

Restart může stroji přidělit jinou adresu. VPN nakonfigurovaná s pevným lokálním koncovým bodem pak dál používá spojení, které už neexistuje. Totéž platí pro klienta, který svůj socket navázal na starou adresu. Rozhraní tunelu může zůstat nahoru, zatímco každý paket, který vytvoří, míří nikam.

Porovnejte adresu, kterou klient používá, s adresou, kterou rozhraní právě má. Výchozí trasa ukazující na bránu, která se také změnila, je stejný druh problému pod jiným jménem.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Druhá podmínka: přeložené mapování zmizelo

Domácí routery překládají odchozí toky a tato mapování žijí v paměti. Restart vymaže každé z nich. To je neškodné pro nové spojení a fatální pro tunel, který věří, že jeho stávající tok je stále platný. Protistrana pak nic nevidí, takže klient nikdy nedostane chybu, se kterou by mohl pracovat.

Tady tunel bez keepalive tiše ustrne, místo aby hlasitě selhal. Dokumentovaná omezení WireGuardu popisují stejný tvar selhání. Špatný stav koncového bodu vytváří zahozené pakety místo diagnostiky.

Trvalý keepalive 25 sekund je obvyklé zmírnění, protože obnovuje mapování dřív, než vyprší časový limit nečinnosti. Neopravuje mapování, které už zmizelo. Spárujte keepalive s logikou opětovného připojení místo toho, abyste ho brali jako opravu.

Třetí podmínka: veřejná adresa se změnila

Pokud se změnila vlastní externí adresa routeru, vše na druhé straně, co filtruje podle zdrojové adresy, teď vidí jinou protistranu. Tunel může naskočit a server přesto provoz zahazovat; vypadá to jako rozbitý klient a ve skutečnosti je to politika na druhém konci.

Zaznamenejte externí adresu před restartem a po něm. Když se obě liší, otázka se přesouvá od klienta k tomu, kdo vede seznam povolených, a reset přihlašovacích údajů na notebooku nepomůže.

Obnovujte ve správném pořadí

Nejprve dokončete povinné přihlášení do captive portálu, potom nechte klienta znovu se připojit jeho podporovaným postupem, místo abyste proces zabíjeli. Sledujte, zda se obnoví identita i datový provoz, protože to jsou dvě různé fáze téhož spojení.

Uložená stránka nic nedokazuje, stejně jako chatovací aplikace, která se připojila sama. Otestujte koncový bod, na kterém vám opravdu záleží, novým požadavkem. Během přerušení ponechte politiku přímého provozu v platnosti, protože pokus o opětovné připojení není blokování.

Když se to opakuje po každém restartu, záznam je důležitější než nový pokus. Zapište lokální adresu, bránu, externí adresu a stav klienta před a po, pak porovnejte oba sloupce. Změní to neurčitou stížnost na chybu životního cyklu, kterou někdo dokáže opravit, a zastaví třetí výměnu certifikátů kvůli časovému limitu mapování.