Remedierea căderilor VPN în repaus: o listă de verificare pentru economisirea energiei Wi-Fi

Tunelul moare după ce laptopul stă un timp neatins, și revine în momentul în care atingeți trackpadul. Acest model indică faptul că legătura wireless intră în economisire de energie, nu că gateway-ul VPN vă respinge credențialele. O dimineață aglomerată pe același profil este dovada: tunelul supraviețuiește cât timp curge trafic și cade când radioul tace. Parcurgeți verificările de mai jos în ordine, opriți-vă la prima care eșuează și abia apoi schimbați o setare.

Prima verificare: căderea urmează repausul?

Începeți prin a demonstra corelația în loc să o presupuneți. Notați ora de perete a ultimului pachet trimis, momentul în care clientul a raportat tunelul căzut și dacă ecranul s-a stins între timp. Dacă intervalul este același de fiecare dată, aveți o problemă pe calea repausului; dacă căderile apar aleatoriu în timpul utilizării active, treceți la a cincea verificare.

Un test ieftin care nu costă nimic de anulat: trimiteți un ping constant cu ritm scăzut către gateway timp de douăzeci de minute și lăsați mașina singură. Dacă tunelul rezistă tot timpul, traficul mic constant maschează simptomul în loc să îl remedieze, ceea ce rămâne o dovadă utilă. Păstrez rezultatul acelui ping într-un terminal de ciornă și îl compar apoi cu jurnalul clientului, pentru că cele două ceasuri rareori coincid.

A doua verificare: este doar trafic VPN?

Înainte de a da vina pe tunel, aflați dacă legătura în sine mai este utilizabilă. Cât timp tunelul este mort dar ecranul încă stins, încercați să ajungeți la adresa punctului de acces și la un host public prin IP. Dacă și ping-ul obișnuit eșuează, radioul sau punctul de acces v-au dat drumul, iar clientul VPN este doar spectator.

Dacă traficul obișnuit curge în timp ce tunelul tace, legătura este sănătoasă și problema stă în temporizatoarele tunelului însuși sau în felul în care clientul tratează o reluare. Sunt două remedieri diferite, așa că nu săriți acest pas. Pe un laptop cu Wi-Fi și Ethernet simultan, scoateți cablul și repetați testul de repaus: o cădere în repaus care dispare pe Ethernet cu cablu este o dovadă puternică pentru stratul wireless.

A treia verificare: citiți starea de economisire a energiei

Majoritatea mediilor desktop vă oferă o casetă de bifare, dar caseta nu este starea în care se află driverul. Citiți mai întâi raportul driverului însuși, apoi decideți. Pe Linux cu mac80211 interfața răspunde direct:

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

A doua comandă este un test, nu o remediere. Nu supraviețuiește unei deconectări, suspendări sau reporniri, ceea ce o face o modalitate curată de a verifica ipoteza fără a lăsa modificări permanente.

Pe Windows powercfg /q SCHEME_CURRENT afișează schema activă, iar subarborele adaptorului wireless arată dacă adaptorului i se poate porunci să economisească energie; aceeași opțiune este și în Device Manager, în fila de gestionare a energiei a adaptorului. Pe macOS economisirea energiei 802.11 pentru fiecare interfață nu vă este expusă, așa că priviți în schimb pmset -g la comportamentul de repaus și standby. Acolo defecțiunea se dovedește de obicei a fi calea de repaus și trezire, nu comportamentul în repaus al radioului.

A patra verificare: schimbați un singur lucru, apoi retestați

Schimbați exact o variabilă pe rulare și repetați aceeași sarcină. Dacă tunelul rezistă acum o oră de repaus cu economisirea energiei oprită, ați învățat ceva real. Dacă tot cade, reveniți înainte de a testa următoarea idee, altfel rămâneți cu trei setări suprapuse și fără nicio idee care contează.

Menținerea conexiunii vii este cealaltă variabilă independentă și este confundată constant cu economisirea energiei. Valoarea PersistentKeepalive = 25 din WireGuard ține o mapare NAT caldă;OpenVPN la ambele capete keepalive și ping-restart folosește. Ambele generează trafic pe un tunel altfel silențios, așa că o menținere vie care pare să remedieze căderea poate ascunde o problemă de radio în loc să o rezolve. Testați-le separat, unul câte unul:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

A cincea verificare: când radioul este nevinovat

Dacă căderile în repaus continuă cu economisirea energiei oprită și menținerea vie activă, priviți în afara laptopului. Punctele de acces și routerele de acasă lasă să expire intrările NAT sau de sesiune în repaus după propriul lor calendar, iar un server VPN poate renunța la o sesiune fără trafic.Roamingul între puncte de acces care împart același SSID poate și el reseta legătura fără ca clientul să spună asta clar.

Apoi comparați cu un al doilea dispozitiv din aceeași rețea care face același test de repaus. Două dispozitive care cad la același interval sunt o poveste de cale sau de server; un singur dispozitiv care cade este o poveste de driver sau de energie locală. Acea comparație costă zece minute și vă scutește de rescrierea configurației greșite.

Înainte de a o face permanentă

Decideți ce sunteți dispus să păstrați. Un script pe profil care oprește economisirea energiei doar în rețelele unde ați văzut căderea este justificabil. O ajustare globală care oprește totul și se plătește cu durata bateriei în fiecare rețea de obicei nu este.

• Notați valoarea originală de economisire a energiei lângă script, ca să poată fi restaurată.
• Repetați testul de repaus după fiecare actualizare de driver sau client; valorile implicite se schimbă.
• Țineți jurnalul de ping și jurnalul clientului împreună când raportați problema.
• Dacă al doilea pas a eșuat, opriți modificarea setărilor VPN și tratați-o ca pe o defecțiune locală a legăturii.

Dacă faceți doar un lucru, faceți a doua verificare. Ea decide dacă restul listei vi se aplică, și este pasul pe care oamenii îl sar după ce au decis deja că răspunsul este economisirea energiei.