Åtgärda VPN-avbrott vid inaktivitet: en checklista för Wi-Fi-energisparande

Gå igenom VPN-avbrott vid inaktivitet i ordning: bekräfta tidsstämpeln, skilj radion från tunneln, läs det faktiska energisparläget och ändra sedan en inställning och testa igen.

Din tunnel dör efter att datorn stått orörd ett tag, och den kommer tillbaka i samma ögonblick som du rör styrplattan. Mönstret pekar på att den trådlösa länken går in i energisparläge, inte på att VPN-gatewayen avvisar dina inloggningsuppgifter. En stressig morgon på samma profil är beviset: tunneln överlever medan trafiken flödar och faller när radion tystnar. Gå igenom kontrollerna nedan i ordning, stanna vid den första som misslyckas och ändra först då en inställning.

Kontroll ett: följer avbrottet inaktiviteten?

Börja med att bevisa sambandet i stället för att anta det. Anteckna väggklocketiden för det senaste paketet du skickade, tiden då klienten rapporterade att tunneln låg nere, och om skärmen släcktes däremellan. Om intervallet är detsamma varje gång har du ett problem på inaktivitetsvägen; om avbrotten kommer slumpmässigt under aktiv användning, hoppa till kontroll fem.

Ett billigt test som inte kostar något att ångra: skicka en jämn ping med låg frekvens till din gateway i tjugo minuter och lämna maskinen ifred. Om tunneln håller hela tiden maskerar ständig liten trafik symtomet i stället för att åtgärda det, vilket fortfarande är ett användbart bevis. Jag förvarar den ping-utskriften i en kladdterminal och jämför den med klientloggen efteråt, eftersom de två klockorna sällan är överens.

Kontroll två: är det bara VPN-trafik?

Innan du skyller på tunneln, ta reda på om själva länken fortfarande är användbar. Medan tunneln är död men skärmen fortfarande släckt, försök nå åtkomstpunktens adress och en offentlig värd via IP. Om den vanliga pingningen också misslyckas har radion eller åtkomstpunkten släppt dig, och VPN-klienten är bara åskådare.

Om vanlig trafik flödar medan tunneln är tyst är länken frisk och problemet sitter i tunnelns egna timers eller i hur klienten hanterar en återupptagning. Det är två olika åtgärder, så hoppa inte över detta steg. På en dator med både Wi-Fi och Ethernet drar du ur kabeln och upprepar inaktivitetsprovet: ett inaktivitetsavbrott som försvinner på kabelanslutet Ethernet är starkt bevis för det trådlösa lagret.

Kontroll tre: läs energisparläget

De flesta skrivbord ger dig en kryssruta, men rutan är inte det läge som drivrutinen befinner sig i. Läs drivrutinens egen rapport först och bestäm sedan. På Linux med mac80211 svarar gränssnittet direkt:

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

Det andra kommandot är ett test, inte en åtgärd. Det överlever inte en frånkoppling, viloläge eller omstart, vilket gör det till ett rent sätt att pröva hypotesen utan att lämna bestående ändringar.

På Windows powercfg /q SCHEME_CURRENT skriver ut det aktiva schemat, och underträdet för den trådlösa adaptern visar om adaptern kan beordras att spara energi; samma val finns också i Enhetshanteraren på adapterns flik för energihantering. På macOS visas inte 802.11-energisparande per gränssnitt för dig, så titta i stället på pmset -g för viloläges- och standbeteende. Där visar sig felet oftast vara viloläges- och uppvakningsvägen snarare än radions inaktivitetsbeteende.

Kontroll fyra: ändra en sak och testa igen

Ändra exakt en variabel per körning och upprepa samma belastning. Om tunneln nu klarar en timmes inaktivitet med energisparande avstängt har du lärt dig något verkligt. Om den fortfarande faller, rulla tillbaka innan du testar nästa idé, annars sitter du kvar med tre överlappande inställningar och ingen aning om vilken som spelar roll.

Att hålla anslutningen vid liv är den andra oberoende variabeln och den blandas ständigt ihop med energisparande. WireGuards PersistentKeepalive = 25 håller en NAT-mappning varm;OpenVPN i båda ändar keepalive och ping-restart använder. Båda genererar trafik på en annars tyst tunnel, så en håll-igång som verkar åtgärda avbrottet kan dölja ett radioproblem i stället för att lösa det. Testa dem separat, en i taget:

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

Kontroll fem: när radion är oskyldig

Om inaktivitetsavbrott fortsätter med energisparande avstängt och håll-igång påslaget, titta utanför datorn. Åtkomstpunkter och hemmaroutrar låter inaktiva NAT- eller sessionposter löpa ut enligt sitt eget schema, och en VPN-server kan släppa en session utan trafik.Roaming mellan åtkomstpunkter som delar samma SSID kan också återställa länken utan att klienten säger det tydligt.

Jämför sedan med en andra enhet på samma nätverk som gör samma inaktivitetsprov. Två enheter som faller med samma intervall är en historia om väg eller server; en enda enhet som faller är en lokal historia om drivrutin eller ström. Den jämförelsen kostar tio minuter och sparar dig från att skriva om fel konfiguration.

Innan du gör det permanent

Bestäm vad du är villig att behålla. Ett skript per profil som stänger av energisparande bara på de nätverk där du sett avbrottet är försvarbart. En global ändring som stänger av allt och betalas med batteritid på varje nätverk är det vanligtvis inte.

  • Skriv ned det ursprungliga energisparvärdet bredvid skriptet så att det kan återställas.
  • Upprepa inaktivitetsprovet efter varje drivrutins- eller klientuppdatering; standardvärden ändras.
  • Håll ping-loggen och klientloggen tillsammans när du rapporterar problemet.
  • Om steg två misslyckades, sluta ändra VPN-inställningar och behandla det som ett lokalt fel i länken.

Om du bara gör en sak, gör kontroll två. Den avgör om resten av listan över huvud taget gäller dig, och det är steget folk hoppar över när de väl bestämt att svaret är energisparande.

Relaterade artiklar