VPN blocat după repornirea routerului: trei lucruri care s-au schimbat

Routerul termină pornirea, laptopul se reconectează la același SSID, iar VPN-ul rămâne pe conectat fără ca nimic să se miște. Profilul salvat este intact. Ce a expirat dedesubt a fost calea, iar clientul ține încă starea pe care a construit-o pentru cea veche.

Trei condiții decid remedierea. Verificați-le în ordine, pentru că cele de mai târziu sunt efort irosit dacă prima explică deja blocajul.

Prima condiție: adresa locală s-a schimbat

O repornire poate da mașinii o altă adresă. Atunci un VPN configurat cu un punct final local fix continuă să folosească o legătură care nu mai există. Același lucru se aplică unui client care și-a legat socketul de adresa veche. Interfața tunelului poate rămâne activă în timp ce fiecare pachet pe care îl produce merge într-un loc inutil.

Comparați adresa pe care o folosește clientul cu adresa pe care o are interfața acum. O rută implicită care indică o poartă care s-a schimbat și ea este aceeași clasă de problemă sub alt nume.

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

A doua condiție: maparea tradusă a dispărut

Routerele de acasă traduc fluxurile de ieșire, iar acele mapări trăiesc în memorie. O repornire le șterge pe fiecare. Asta este inofensiv pentru o conexiune nouă și fatal pentru un tunel care crede că fluxul său existent este încă valid. Atunci cealaltă parte nu vede nimic, așa că clientul nu primește niciodată o eroare pe care să poată acționa.

Aici un tunel fără keepalive se oprește în tăcere în loc să eșueze zgomotos. Limitările documentate ale WireGuard descriu aceeași formă de eșec. O stare greșită a punctului final produce pachete aruncate în loc de un diagnostic.

Un keepalive persistent de 25 de secunde este atenuarea obișnuită, pentru că reîmprospătează maparea înainte ca un timeout de inactivitate să poată expira. Nu repară o mapare care a dispărut deja. Asociați keepalive-ul cu logica de reconectare în loc să îl tratați ca pe o remediere.

A treia condiție: adresa publică s-a schimbat

Dacă adresa externă proprie a routerului s-a schimbat, tot ce se află de cealaltă parte și filtrează după adresa sursă vede acum un alt partener. Tunelul poate urca și serverul poate în continuare să arunce traficul, ceea ce arată ca un client defect și în realitate este o politică la celălalt capăt.

Notați adresa externă înainte și după repornire. Când cele două diferă, întrebarea se mută de la client la cel care întreține lista de permisiuni, iar resetarea datelor de autentificare pe laptop nu poate ajuta.

Recuperați în ordinea corectă

Finalizați mai întâi orice autentificare obligatorie în portalul captiv, apoi lăsați clientul să se reconecteze prin procedura sa acceptată în loc să omorâți procesul. Urmăriți dacă revin atât identitatea, cât și traficul de date, pentru că sunt două etape diferite ale aceleiași conexiuni.

O pagină din cache nu dovedește nimic, la fel nici o aplicație de chat care s-a reconectat singură. Testați punctul final care vă interesează cu adevărat printr-o cerere nouă. Mențineți politica de trafic direct în vigoare în timpul întreruperii, pentru că o încercare de reconectare nu este o blocare.

Când acest lucru se repetă după fiecare repornire, înregistrarea contează mai mult decât reîncercarea. Notați adresa locală, poarta, adresa externă și starea clientului înainte și după, apoi comparați cele două coloane. Asta transformă o plângere vagă într-un defect de ciclu de viață pe care cineva îl poate corecta și oprește a treia înlocuire a certificatelor din cauza unui timeout de mapare.