Ret VPN-fald under lediggang: en tjekliste til Wi-Fi-strømbesparelse

Gå VPN-fald under lediggang igennem i rækkefølge: bekræft timingen, skil radioen fra tunnelen, læs den faktiske strømbesparelsestilstand, og skift så én indstilling og test igen.

Din tunnel dør, efter at computeren har stået urørt et stykke tid, og den kommer tilbage i samme øjeblik, du rører ved styrepladen. Det mønster peger på, at den trådløse forbindelse går i strømbesparelse, ikke på at VPN-gatewayen afviser dine loginoplysninger. En travl morgen på samme profil er beviset: tunnelen overlever, mens trafikken løber, og fejler, når radioen bliver stille. Gå kontrollerne nedenfor igennem i rækkefølge, stop ved den første, der fejler, og skift først derefter én indstilling.

Kontrol et: følger faldet lediggang?

Begynd med at bevise sammenhængen i stedet for at antage den. Notér vægur-tiden for den sidste pakke, du sendte, tidspunktet hvor klienten rapporterede tunnelen nede, og om skærmen blev slukket i mellemtiden. Hvis mellemrummet er det samme hver gang, har du et problem på lediggangsvejen; hvis faldene kommer tilfældigt under aktiv brug, så spring til kontrol fem.

En billig test, der ikke koster noget at fortryde: send en jævn ping med lav frekvens til din gateway i tyve minutter, og lad maskinen være alene. Hvis tunnelen holder hele vejen, maskerer konstant lille trafik symptomet i stedet for at løse det, hvilket stadig er nyttigt bevis. Jeg gemmer den ping-udskrift i en kladde-terminal og sammenligner den bagefter med klientloggen, fordi de to ure sjældent er enige.

Kontrol to: er det kun VPN-trafik?

Før du bebrejder tunnelen, skal du finde ud af, om selve forbindelsen stadig er brugbar. Mens tunnelen er død, men skærmen stadig er slukket, så prøv at nå adgangspunktets adresse og en offentlig vært via IP. Hvis den almindelige ping også fejler, har radioen eller adgangspunktet droppet dig, og VPN-klienten er blot tilskuer.

Hvis almindelig trafik løber, mens tunnelen er tavs, er forbindelsen sund, og problemet ligger i tunnelens egne timere eller i måden, klienten håndterer en genoptagelse. Det er to forskellige rettelser, så spring ikke dette trin over. På en computer med både Wi-Fi og Ethernet tages kablet ud, og lediggangstesten gentages: et lediggangsfald, der forsvinder på kablet Ethernet, er stærkt bevis for det trådløse lag.

Kontrol tre: læs strømbesparelsestilstanden

De fleste skriveborde giver dig et afkrydsningsfelt, men feltet er ikke den tilstand, driveren står i. Læs først driverens egen rapport, og beslut så. På Linux med mac80211 svarer grænsefladen 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 anden kommando er en test, ikke en rettelse. Den overlever ikke en afbrydelse, suspendering eller genstart, hvilket gør den til en ren måde at afprøve hypotesen på uden at efterlade permanente ændringer.

På Windows powercfg /q SCHEME_CURRENT udskriver det aktive skema, og undergrebet for den trådløse adapter viser, om adapteren kan få besked om at spare strøm; det samme valg findes også i Enhedshåndtering på adapterens faneblad for strømstyring. På macOS er 802.11-strømbesparelse per grænseflade ikke tilgængelig for dig, så se i stedet på pmset -g for dvale- og standbyadfærd. Der viser fejlen sig som regel at være dvale- og vækningsvejen snarere end radioens lediggangsadfærd.

Kontrol fire: skift én ting, og test igen

Skift præcis én variabel for hver kørsel, og gentag den samme belastning. Hvis tunnelen nu overlever en ledig time med strømbesparelse slået fra, har du lært noget rigtigt. Hvis den stadig falder, så rul tilbage, før du tester den næste idé, ellers ender du med tre overlappende indstillinger og ingen idé om, hvilken der betyder noget.

Hold-i-live er den anden uafhængige variabel, og den bliver konstant blandet sammen med strømbesparelse. WireGuards PersistentKeepalive = 25 holder en NAT-mapping varm;OpenVPN bruger keepalive og ping-restart i begge ender. Begge genererer trafik på en ellers tavs tunnel, så en hold-i-live, der ser ud til at løse faldet, kan skjule et radioproblem i stedet for at løse det. Test dem hver for sig, én ad gangen:

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

Kontrol fem: når radioen er uskyldig

Hvis lediggangsfaldene fortsætter med strømbesparelse slået fra og hold-i-live slået til, så se uden for computeren. Adgangspunkter og forbrugerroutere udløber ledige NAT- eller sessionposter efter deres egen tidsplan, og en VPN-server kan droppe en session uden trafik.Roaming mellem adgangspunkter, der deler samme SSID, kan også nulstille forbindelsen, uden at klienten siger det tydeligt.

Sammenlign derefter med en anden enhed på samme netværk, som laver den samme lediggangstest. To enheder, der falder i samme interval, er en historie om vej eller server; én enhed, der falder, er en lokal historie om driver eller strøm. Den sammenligning koster ti minutter og sparer dig for at skrive den forkerte konfiguration om.

Før du gør det permanent

Beslut, hvad du er villig til at beholde. Et script for hver profil, der kun slår strømbesparelse fra på de netværk, hvor du har set faldet, er forsvarligt. En global ændring, der slår alt fra betalt med batteritid på alle netværk, er det som regel ikke.

  • Skriv den oprindelige strømbesparelsesværdi ned ved siden af scriptet, så den kan gendannes.
  • Kør lediggangstesten igen efter hver driver- eller klientopdatering; standardværdier ændrer sig.
  • Hold ping-loggen og klientloggen sammen, når du rapporterer problemet.
  • Hvis trin to fejlede, så stop med at ændre VPN-indstillinger og behandl det som en lokal fejl i forbindelsen.

Hvis du kun gør én ting, så gør kontrol to. Den afgør, om resten af denne liste overhovedet gælder for dig, og det er det trin, folk springer over, når de først har besluttet, at svaret er strømbesparelse.

Relaterede artikler