Fiks VPN-fall i lediggang: en sjekkliste for Wi-Fi-strømsparing

Gå gjennom VPN-fall i lediggang i rekkefølge: bekreft tidspunktet, skill radioen fra tunnelen, les den faktiske strømsparingstilstanden, og endre så én innstilling og test på nytt.

Tunnelen din dør etter at maskinen har stått urørt en stund, og den kommer tilbake i samme øyeblikk som du berører styreflaten. Det mønsteret peker på at den trådløse forbindelsen går i strømsparing, ikke på at VPN-gatewayen avviser påloggingsinformasjonen din. En travel morgen på samme profil er beviset: tunnelen overlever mens trafikken flyter og faller når radioen blir stille. Gå gjennom kontrollene nedenfor i rekkefølge, stopp ved den første som feiler, og endre først da én innstilling.

Kontroll én: følger fallet lediggang?

Begynn med å bevise sammenhengen i stedet for å anta den. Noter veggklokketiden for den siste pakken du sendte, tidspunktet klienten meldte at tunnelen var nede, og om skjermen sluknet i mellomtiden. Hvis intervallet er det samme hver gang, har du et problem på lediggangsveien; hvis fallene kommer tilfeldig under aktiv bruk, hopp til kontroll fem.

En billig test som ikke koster noe å angre: send en jevn ping med lav frekvens til gatewayen i tjue minutter og la maskinen være i fred. Hvis tunnelen holder hele økten, maskerer konstant liten trafikk symptomet i stedet for å fikse det, noe som fortsatt er nyttig bevis. Jeg oppbevarer den ping-utskriften i et kladdeterminal og sammenligner den med klientloggen etterpå, fordi de to klokkene sjelden er enige.

Kontroll to: er det bare VPN-trafikk?

Før du gir tunnelen skylden, finn ut om selve forbindelsen fortsatt er brukbar. Mens tunnelen er død men skjermen fortsatt er slukket, prøv å nå aksesspunktets adresse og en offentlig vert via IP. Hvis den vanlige ping-en også feiler, har radioen eller aksesspunktet sluppet deg, og VPN-klienten er bare tilskuer.

Hvis vanlig trafikk flyter mens tunnelen er taus, er forbindelsen sunn, og problemet ligger i tunnelens egne timere eller i hvordan klienten håndterer en gjenopptakelse. Det er to forskjellige rettelser, så ikke hopp over dette trinnet. På en maskin med både Wi-Fi og Ethernet tar du ut kabelen og gjentar lediggangstesten: et lediggangsfall som forsvinner på kablet Ethernet er sterkt bevis for det trådløse laget.

Kontroll tre: les strømsparingstilstanden

De fleste skrivebord gir deg en avkrysningsboks, men boksen er ikke tilstanden driveren står i. Les først driverens egen rapport, og bestem deg deretter. På Linux med mac80211 svarer grensesnittet direkte:

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

Den andre kommandoen er en test, ikke en rettelse. Den overlever ikke frakobling, dvale eller omstart, noe som gjør den til en ren måte å prøve hypotesen på uten å legge igjen varige endringer.

På Windows powercfg /q SCHEME_CURRENT skriver ut det aktive skjemaet, og undertreet for den trådløse adapteren viser om adapteren kan få beskjed om å spare strøm; det samme valget finnes også i Enhetsbehandling på adapterens fane for strømstyring. På macOS er 802.11-strømsparing per grensesnitt ikke tilgjengelig for deg, så se i stedet på pmset -g for dvale- og standbyatferd. Der viser feilen seg som regel å være dvale- og oppvåkningsveien snarere enn radioens lediggangsatferd.

Kontroll fire: endre én ting, og test på nytt

Endre nøyaktig én variabel per kjøring og gjenta samme belastning. Hvis tunnelen nå overlever en ledig time med strømsparing av, har du lært noe ekte. Hvis den fortsatt faller, rull tilbake før du tester neste idé, ellers sitter du igjen med tre overlappende innstillinger og ingen anelse om hvilken som betyr noe.

Å holde forbindelsen i live er den andre uavhengige variabelen, og den blir hele tiden blandet sammen med strømsparing. WireGuards PersistentKeepalive = 25 holder en NAT-tilordning varm;OpenVPN bruker keepalive og ping-restart i begge ender. Begge genererer trafikk på en ellers stille tunnel, så en hold-i-live som ser ut til å fikse fallet, kan skjule et radioproblem i stedet for å løse det. Test dem hver for seg, én om gangen:

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

Kontroll fem: når radioen er uskyldig

Hvis lediggangsfall fortsetter med strømsparing av og hold-i-live på, se utenfor maskinen. Aksesspunkter og hjemmerutere lar ledige NAT- eller øktoppføringer utløpe etter sin egen tidsplan, og en VPN-server kan droppe en økt uten trafikk.Roaming mellom aksesspunkter som deler samme SSID kan også nullstille forbindelsen uten at klienten sier det tydelig.

Sammenlign deretter med en annen enhet på samme nettverk som gjør den samme lediggangstesten. To enheter som faller med samme intervall, er en historie om vei eller server; én enhet som faller, er en lokal historie om driver eller strøm. Den sammenligningen koster ti minutter og sparer deg for å skrive om feil konfigurasjon.

Før du gjør det varig

Bestem hva du er villig til å beholde. Et skript per profil som slår av strømsparing bare på nettverkene der du har sett fallet, er forsvarlig. En global endring som slår av alt og betales med batteritid på hvert nettverk, er det vanligvis ikke.

  • Skriv ned den opprinnelige strømsparingsverdien ved siden av skriptet, slik at den kan gjenopprettes.
  • Gjenta lediggangstesten etter hver driver- eller klientoppdatering; standardverdiene endres.
  • Hold ping-loggen og klientloggen sammen når du rapporterer problemet.
  • Hvis trinn to feilet, slutt å endre VPN-innstillinger og behandle det som en lokal feil i forbindelsen.

Hvis du bare gjør én ting, gjør kontroll to. Den avgjør om resten av denne listen i det hele tatt gjelder for deg, og det er trinnet folk hopper over når de først har bestemt at svaret er strømsparing.

Relaterte artikler