Beragadt VPN az útválasztó újraindítása után: három dolog, ami megváltozott

Az útválasztó befejezi az indítást, a laptop újra ugyanahhoz az SSID-hez csatlakozik, és a VPN csatlakoztatva állapotban marad anélkül, hogy bármi mozogna. A mentett profil ép. Ami alatta lejárt, az az útvonal volt, és a kliens még mindig azt az állapotot tartja, amelyet a régihez épített.

Három feltétel dönti el a javítást. Sorrendben ellenőrizze őket, mert a későbbiek elvesztegetett munka, ha az első már megmagyarázza a megakadást.

Első feltétel: a helyi cím megváltozott

Az újraindítás más címet adhat a gépnek. Ekkor a rögzített helyi végponttal beállított VPN továbbra is olyan kapcsolatot használ, amely már nem létezik. Ugyanez vonatkozik arra a kliensre, amely a socketjét a régi címhez kötötte. Az alagút interfésze fent maradhat, miközben minden általa előállított csomag haszontalan helyre megy.

Hasonlítsa össze a kliens által használt címet azzal a címmel, amely az interfészen jelenleg van. Az az alapértelmezett útvonal, amely egy szintén megváltozott átjáróra mutat, ugyanaz a probléma más néven.

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

Második feltétel: a lefordított leképezés eltűnt

Az otthoni útválasztók lefordítják a kimenő folyamokat, és ezek a leképezések a memóriában élnek. Az újraindítás mindegyiket törli. Ez egy új kapcsolatnak ártalmatlan, és végzetes egy olyan alagútnak, amely azt hiszi, hogy a meglévő folyama még érvényes. Ekkor a túloldal nem lát semmit, így a kliens soha nem kap olyan hibát, amelyre cselekedhetne.

Itt akad meg csendben egy keepalive nélküli alagút ahelyett, hogy hangosan meghiúsulna. A WireGuard dokumentált korlátait ugyanezt a hibaformát írják le. A hibás végpontállapot eldobott csomagokat eredményez diagnózis helyett.

A 25 másodperces állandó keepalive a szokásos enyhítés, mert frissíti a leképezést, mielőtt egy tétlenségi időkorlát lejárhatna. Nem javítja meg a már eltűnt leképezést. Párosítsa a keepalive-ot újracsatlakozási logikával, ahelyett hogy javításként kezelné.

Harmadik feltétel: a nyilvános cím megváltozott

Ha maga az útválasztó külső címe változott meg, akkor a túloldalon minden, ami forrás cím szerint szűr, most más partnert lát. Az alagút feljöhet, és a kiszolgáló továbbra is eldobhatja a forgalmat, ami törött kliensnek látszik, valójában pedig szabályzat a másik végén.

Jegyezze fel a külső címet az újraindítás előtt és után. Amikor a kettő eltér, a kérdés a klienstől átkerül ahhoz, aki az engedélyezési listát kezeli, és a laptopon a hitelesítő adatok visszaállítása nem segíthet.

A helyes sorrendben állítsa helyre

Először fejezze be a szükséges captive portal bejelentkezést, majd hagyja, hogy a kliens a támogatott eljárásával újracsatlakozzon, ahelyett hogy leölné a folyamatot. Figyelje, hogy az identitás és az adatforgalom is visszatér-e, mert ezek ugyanazon kapcsolat két különböző szakaszai.

A gyorsítótárazott oldal semmit sem bizonyít, és az sem, ha egy csevegőalkalmazás magától újracsatlakozott. Tesztelje azt a végpontot, amely valóban számít, friss kéréssel. Tartsa érvényben a közvetlen forgalom szabályzatát a megszakítás alatt, mert az újracsatlakozási kísérlet nem blokkolás.

Amikor ez minden újraindítás után megismétlődik, a feljegyzés többet ér, mint az újabb próbálkozás. Jegyezze fel a helyi címet, az átjárót, a külső címet és a kliens állapotát előtte és utána, majd hasonlítsa össze a két oszlopot. Ez a homályos panaszt olyan életciklus-hibává alakítja, amelyet valaki javítani tud, és megakadályozza, hogy a tanúsítványokat egy leképezési időtúllépés miatt harmadszor is lecseréljék.