Resoldre les caigudes de VPN en repòs: una llista de comprovació per a l'estalvi d'energia del Wi-Fi

El túnel mor després que l'ordinador portàtil quedi una estona sense tocar, i torna en el moment que toqueu el trackpad. Aquest patró apunta que l'enllaç sense fils entra en estalvi d'energia, no que la passarel·la VPN rebutgi les vostres credencials. Un matí atrafegat amb el mateix perfil és la pista: el túnel sobreviu mentre hi ha trànsit i cau quan la ràdio calla. Feu les comprovacions següents per ordre, atureu-vos a la primera que falli i només llavors canvieu un paràmetre.

Primera comprovació: la caiguda segueix el repòs?

Comenceu demostrant la correlació en lloc de suposar-la. Anoteu l'hora de rellotge de l'últim paquet enviat, l'hora en què el client va informar que el túnel havia caigut i si la pantalla es va apagar entremig. Si l'interval és el mateix cada cop, teniu un problema al camí de repòs; si les caigudes arriben a l'atzar durant l'ús actiu, salteu a la cinquena comprovació.

Una prova barata que no costa res de desfer: envieu un ping constant de ritme baix a la passarel·la durant vint minuts i deixeu la màquina sola. Si el túnel aguanta tota l'estona, el trànsit petit constant està emmascarant el símptoma en lloc d'arreglar-lo, cosa que encara és una evidència útil. Guarde el resultat d'aquell ping en un terminal d'esborrany i després el comparo amb el registre del client, perquè els dos rellotges poques vegades coincideixen.

Segona comprovació: és només trànsit VPN?

Abans de culpar el túnel, esbrineu si l'enllaç mateix encara és utilitzable. Mentre el túnel és mort però la pantalla encara és apagada, proveu d'arribar a l'adreça del punt d'accés i a un amfitrió públic per IP. Si el ping normal també falla, la ràdio o el punt d'accés us han deixat anar i el client VPN és un simple espectador.

Si el trànsit ordinari flueix mentre el túnel calla, l'enllaç és sa i el problema és als temporitzadors del propi túnel o en com el client gestiona una represa. Són dues correccions diferents, així que no us salteu aquest pas. En un portàtil amb Wi-Fi i Ethernet alhora, desconnecteu el cable i repetiu la prova de repòs: una caiguda de repòs que desapareix amb Ethernet per cable és una evidència forta per a la capa sense fils.

Tercera comprovació: llegiu l'estat d'estalvi d'energia

La majoria d'escriptoris us donen una casella, però la casella no és l'estat en què es troba el controlador. Llegiu primer l'informe propi del controlador i després decidiu. A Linux amb mac80211 la interfície respon directament:

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

La segona ordre és una prova, no una correcció. No sobreviu a una desconnexió, una suspensió ni un reinici, cosa que la fa una manera neta de comprovar la hipòtesi sense deixar canvis permanents.

A Windows powercfg /q SCHEME_CURRENT imprimeix l'esquema actiu, i el subarbre de l'adaptador sense fils mostra si se li pot ordenar a l'adaptador que estalviï energia; la mateixa opció també és al Device Manager a la pestanya de gestió d'energia de l'adaptador. A macOS l'estalvi d'energia 802.11 per interfície no us és accessible, així que mireu en lloc d'això pmset -g pel comportament de repòs i espera. Allà la fallada sol resultar ser el camí de repòs i despertar, no el comportament en repòs de la ràdio.

Quarta comprovació: canvieu una cosa i torneu a provar

Canvieu exactament una variable per execució i repetiu la mateixa càrrega. Si el túnel ara aguanta una hora de repòs amb l'estalvi d'energia desactivat, heu après una cosa real. Si encara cau, revertiu-ho abans de provar la idea següent, o acabareu amb tres paràmetres superposats i sense idea de quin importa.

Mantenir la connexió viva és l'altra variable independent i es confon constantment amb l'estalvi d'energia. El valor PersistentKeepalive = 25 del WireGuard manté calent un mapatge NAT;OpenVPN fa servir keepalive i ping-restart als dos extrems. Tots dos generen trànsit en un túnel que d'altra manera seria silenciós, així que un manteniment de connexió que sembla arreglar la caiguda pot estar amagant un problema de ràdio en lloc de resoldre'l. Proveu-los per separat, un a la vegada:

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

Cinquena comprovació: quan la ràdio és innocent

Si les caigudes en repòs continuen amb l'estalvi d'energia desactivat i el manteniment de connexió activat, mireu fora del portàtil. Els punts d'accés i els encaminadors domèstics fan caducar les entrades NAT o de sessió en repòs segons el seu propi calendari, i un servidor VPN pot deixar caure una sessió sense trànsit.L'itinerància entre punts d'accés que comparteixen un mateix SSID també pot reiniciar l'enllaç sense que el client ho digui clarament.

Després compareu amb un segon dispositiu a la mateixa xarxa que faci la mateixa prova de repòs. Dos dispositius que cauen en el mateix interval són una història de camí o de servidor; un de sol que cau és una història de controlador o d'energia local. Aquesta comparació costa deu minuts i us estalvia reescriure la configuració equivocada.

Abans de fer-ho permanent

Decidiu què esteu disposats a mantenir. Un script per perfil que desactiva l'estalvi d'energia només a les xarxes on heu vist la caiguda és defensable. Un retoc global que ho desactiva tot a canvi de bateria a totes les xarxes normalment no ho és.

• Anoteu el valor original d'estalvi d'energia al costat de l'script perquè es pugui restaurar.
• Torneu a fer la prova de repòs després de cada actualització de controlador o client; els valors per defecte canvien.
• Manteniu el registre de ping i el registre del client junts quan informeu del problema.
• Si el segon pas ha fallat, atureu els canvis de paràmetres VPN i tracteu-ho com una fallada local de l'enllaç.

Si només feu una cosa, feu la segona comprovació. És la que decideix si la resta d'aquesta llista us afecta, i és el pas que la gent s'estalvia quan ja ha decidit que la resposta és l'estalvi d'energia.