Zaseknutá VPN po reštarte routera: tri veci, ktoré sa zmenili

Router dokončí štart, notebook sa znova pripojí k tej istej SSID a VPN zostane v stave pripojené, pričom sa nič nehýbe. Uložený profil je v poriadku. To, čo pod ním vypršalo, bola cesta, a klient si stále drží stav, ktorý si pre tú starú postavil.

Opravu určujú tri podmienky. Kontrolujte ich v poradí, pretože neskoršie sú zbytočná práca, ak tá prvá už zaseknutie vysvetľuje.

Prvá podmienka: lokálna adresa sa zmenila

Reštart môže stroju prideliť inú adresu. VPN nakonfigurovaná s pevným lokálnym koncovým bodom potom ďalej používa spojenie, ktoré už neexistuje. To isté platí pre klienta, ktorý svoj socket naviazal na starú adresu. Rozhranie tunela môže zostať hore, zatiaľ čo každý paket, ktorý vytvorí, ide nikam.

Porovnajte adresu, ktorú klient používa, s adresou, ktorú má rozhranie teraz. Predvolená trasa ukazujúca na bránu, ktorá sa tiež zmenila, je ten istý druh problému pod iným názvom.

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

Druhá podmienka: preložené mapovanie zmizlo

Domáce routery prekladajú odchádzajúce toky a tieto mapovania žijú v pamäti. Reštart vymaže každé z nich. Pre nové spojenie je to neškodné a pre tunel, ktorý verí, že jeho existujúci tok je stále platný, fatálne. Protistrana potom nič nevidí, takže klient nikdy nedostane chybu, s ktorou by mohol pracovať.

Tu tunel bez keepalive ticho ustrnie, namiesto toho aby hlasno zlyhal. Dokumentované obmedzenia WireGuardu opisujú rovnaký tvar zlyhania. Nesprávny stav koncového bodu vytvára zahodené pakety namiesto diagnostiky.

Trvalý keepalive 25 sekúnd je obvyklé zmiernenie, pretože obnovuje mapovanie skôr, než môže vypršať časový limit nečinnosti. Neopravuje mapovanie, ktoré už zmizlo. Spárujte keepalive s logikou opätovného pripojenia namiesto toho, aby ste ho brali ako opravu.

Tretia podmienka: verejná adresa sa zmenila

Ak sa zmenila vlastná externá adresa routera, všetko na druhej strane, čo filtruje podľa zdrojovej adresy, teraz vidí inú protistranu. Tunel môže naskočiť a server môže naďalej zahadzovať prevádzku; vyzerá to ako pokazený klient a v skutočnosti je to politika na druhom konci.

Zaznamenajte externú adresu pred reštartom a po ňom. Keď sa obe líšia, otázka sa presúva od klienta k tomu, kto vedie zoznam povolených, a reset prihlasovacích údajov na notebooku nepomôže.

Obnovujte v správnom poradí

Najprv dokončite povinné prihlásenie do captive portálu, potom nechajte klienta znova sa pripojiť jeho podporovaným postupom, namiesto toho aby ste proces zabíjali. Sledujte, či sa obnoví identita aj dátová prevádzka, pretože to sú dve rôzne fázy toho istého spojenia.

Uložená stránka nič nedokazuje, rovnako ako chatovacia aplikácia, ktorá sa pripojila sama. Otestujte koncový bod, na ktorom vám naozaj záleží, novou požiadavkou. Počas prerušenia ponechajte politiku priamej prevádzky v platnosti, pretože pokus o opätovné pripojenie nie je blokovanie.

Keď sa to opakuje po každom reštarte, záznam je dôležitejší než nový pokus. Zapíšte lokálnu adresu, bránu, externú adresu a stav klienta pred a po, potom porovnajte oba stĺpce. Zmení to neurčitú sťažnosť na chybu životného cyklu, ktorú niekto dokáže opraviť, a zastaví tretiu výmenu certifikátov pre časový limit mapovania.