VPN mort după suspendare: tunel pierdut sau aplicație învechită?

Capacul se deschide, pictograma wireless revine, iar VPN-ul apare în continuare ca fiind conectat. Prima pagină internă se blochează apoi până la expirarea timpului, iar un tab nou face la fel. Trei lucruri diferite pot produce acea imagine și au nevoie de trei reparații diferite: un tunel care nu a supraviețuit suspendării, un profil pe care nimeni nu a cerut să fie reactivat, sau o aplicație care mai ține o sesiune moartă de ore bune. Compararea lor este mai rapidă decât reinstalarea oricărui lucru.

Trei lucruri se pot strica după trezire

Primul candidat este tunelul însuși. Interfața poate exista în continuare cu o adresă, în timp ce asocierea cu partenerul a dispărut, de aceea un bec indicator nu este dovada unei căi funcționale. Un handshake mai vechi decât suspendarea este indiciul, iar pentru a-l vedea este suficientă o comandă.

Al doilea este activarea. Mulți clienți se reconectează singuri; unii nu, iar un profil pe care nimeni nu îl cheamă să revină rămâne acolo și arată configurat. Acest eșec este silențios prin proiectare, pentru că nimic nu a raportat o eroare.

Al treilea este aplicația. Un tab de browser, o sesiune SSH sau o conexiune la o bază de date pot supraviețui unei schimbări de rețea ca descriptor de fișier, în timp ce transportul de dedesubt este mort. Atunci o sesiune nouă funcționează perfect, ceea ce vă spune că tunelul a fost în regulă tot timpul.

Comparați-le pe toate trei înainte de a schimba ceva, pentru că reparațiile nu se suprapun. Repornirea unui client care nu a fost niciodată invitat să pornească din nou risipește dovada de care aveați nevoie. Notați cărui candidat îi corespunde simptomul înainte de a atinge o configurație. Acea singură propoziție decide de obicei restul investigației.

Primul: a revenit tunelul?

Priviți interfața și starea partenerului în loc de textul de stare al clientului. O interfață cu adresă și fără handshake recent este un tunel care există doar cu numele.

ip -brief addr show
wg show
ip route show table all | head -20

Dacă interfața lipsește complet, tunelul nu a supraviețuit și întrebarea devine cine ar fi trebuit să îl aducă înapoi. Dacă este prezentă, dar handshake-ul este vechi, asocierea cu partenerul trebuie restabilită, iar clientul poate aștepta trafic care să o declanșeze.

Verificați și rutele și configurația DNS. Un tunel poate reveni fără rutele sale, ceea ce produce starea confuză în care interfața este activă și numele interne se rezolvă încă prin serverul greșit.

Al doilea: a cerut ceva să revină?

Aici comparația își merită efortul. Un profil de plugin OpenVPN și o conexiune WireGuard nativă sunt tratate diferit de NetworkManager, iar referința setărilor de conexiune spune clar că connection.autoconnect nu activează profiluri VPN; mecanismul de a ridica un VPN împreună cu o conexiune este connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Dacă reconectarea manuală repară problema de fiecare dată, este semnătura unei activări lipsă și nu a unui tunel stricat. Jurnalul va arăta de obicei interfața căzând și nimic aducând-o înapoi.

Rezistați impulsului de a adăuga imediat un hook de suspendare. Un hook care se declanșează înainte ca rețeaua să își revină concurează exact procesul căruia încearcă să îi ajute, și transformă o problemă reproductibilă într-una intermitentă.

Al treilea: aplicația ține o stare veche?

Deschideți o sesiune complet nouă către aceeași destinație înainte de a atinge VPN-ul. Dacă sesiunea nouă funcționează și cea veche nu, tunelul este în regulă și aplicația ține o conexiune moartă.

Aceasta este cea mai ieftină dintre cele trei verificări și cea mai des omisă, pentru că fereastra care eșuează este chiar pe ecran. Închideți-o, redeschideți-o și notați dacă problema supraviețuiește. Dacă sesiunea nouă funcționează, opriți complet investigarea tunelului. Dacă și ea eșuează, aplicația este un simptom și nu o cauză.

Unele aplicații își revin singure după un timp de așteptare, de aceea simptomul poate părea că se repară singur după câteva minute. Acel comportament indică aplicația și nu tunelul, și merită notat separat. Un coleg care spune că s-a reparat singur descrie acest tipar, nu un noroc.

Faceți comparația reproductibilă

Țineți variabilele mici: o rețea de acces, o durată de suspendare și aceeași primă cerere de fiecare dată. Apoi notați două rezultate: dacă reconectarea manuală îl repară și dacă o altă suspendare aduce din nou eșecul.

Acea ultimă observație este cea care separă cei trei candidați cel mai fiabil. O sesiune nouă care funcționează după una veche eșuată nu este o problemă de tunel, iar nicio reinstalare a clientului nu va schimba asta.

Keepalive-ul persistent al WireGuard intră în această imagine doar ca keepalive de mapare NAT. Trimite pachete pentru a ține o mapare deschisă; nu împiedică mașina să adoarmă și nu poate continua să trimită cât timp procesul este suspendat.

Notați în tichet ce ați găsit: care dintre cele trei era stricat, ce l-a reparat și cum l-ați reprodus. Următoarea persoană care deschide un capac într-o zi de luni vă va mulțumi, iar răspunsul nu va trebui redescoperit de la zero.