Fiks VPN-fall i lediggang: ei sjekkliste for Wi-Fi-straumspering

Gå gjennom VPN-fall i lediggang i rekkefølgje: stadfest tidspunktet, skil radioen frå tunnelen, les den faktiske straumsparingstilstanden, og endre så éi innstilling og test på nytt.

Tunnelen din døyr etter at maskina har stått urørt ei stund, og han kjem tilbake i same augneblink som du rører styreflata. Det mønsteret peikar på at den trådlause sambandet går i straumsparing, ikkje på at VPN-gatewayen avviser påloggingsinformasjonen din. Ein travel morgon på same profil er provet: tunnelen overlever medan trafikken flyt og fell når radioen blir stille. Gå gjennom kontrollane nedanfor i rekkefølgje, stopp ved den første som feilar, og endre først då éi innstilling.

Kontroll éin: følgjer fallet lediggang?

Start med å prove samanhengen i staden for å ta han for gitt. Noter veggklokketida for den siste pakken du sende, tidspunktet klienten melde at tunnelen var nede, og om skjermen slokka i mellomtida. Viss intervallet er det same kvar gong, har du eit problem på lediggangsvegen; viss falla kjem tilfeldig under aktiv bruk, hopp til kontroll fem.

Ein billeg test som ikkje kostar noko å angre: send ein jamn ping med låg frekvens til gatewayen i tjue minutt og lat maskina vere i fred. Viss tunnelen held heile økta, maskerer konstant liten trafikk symptomet i staden for å fikse det, noko som framleis er nyttig prov. Eg oppbevarer den ping-utskrifta i eit kladdeterminal og samanliknar han med klientloggen etterpå, fordi dei to klokkene sjeldan er samde.

Kontroll to: er det berre VPN-trafikk?

Før du gir tunnelen skulda, finn ut om sjølve sambandet framleis er brukbart. Medan tunnelen er død men skjermen framleis slokka, prøv å nå adressa til aksesspunktet og ein offentleg vert via IP. Viss den vanlege ping-en også feilar, har radioen eller aksesspunktet sleppt deg, og VPN-klienten er berre tilskodar.

Viss vanleg trafikk flyt medan tunnelen er taus, er sambandet sunt, og problemet ligg i tunnelens eigne timarar eller i korleis klienten handterer ein gjenopptaking. Det er to ulike rettingar, så ikkje hopp over dette steget. På ei maskin med både Wi-Fi og Ethernet tek du ut kabelen og gjer lediggangstesten om att: eit lediggangsfall som forsvinn på kablet Ethernet er sterkt prov for det trådlause laget.

Kontroll tre: les straumsparingstilstanden

Dei fleste skrivebord gir deg ein avkrysningsboks, men boksen er ikkje tilstanden drivaren står i. Les først rapporten til drivaren sjølv, og avgjer deretter. På Linux med mac80211 svarar 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 ein test, ikkje ei retting. Han overlever ikkje fråkopling, dvale eller omstart, noko som gjer han til ein rein måte å prøve hypotesen på utan å leggje igjen varige endringar.

På Windows powercfg /q SCHEME_CURRENT skriv ut det aktive skjemaet, og undertreet for den trådlause adapteren viser om adapteren kan få beskjed om å spare straum; det same valet finst også i Eningsbehandling på adapteren si fane for straumstyring. På macOS er 802.11-straumsparing per grensesnitt ikkje tilgjengeleg for deg, så sjå i staden på pmset -g for dvale- og standbytferd. Der viser feilen seg som regel å vere dvale- og oppvakningsvegen snarare enn lediggangstferda til radioen.

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

Endre nøyaktig éin variabel per køyring og gjer same belastning om att. Viss tunnelen no overlever ein ledig time med straumsparing av, har du lært noko ekte. Viss han framleis fell, rull tilbake før du testar neste idé, elles sit du att med tre overlappande innstillingar og inga aning om kva som betyr noko.

Å halde sambandet i live er den andre uavhengige variabelen, og han blir heile tida blanda saman med straumsparing. WireGuards PersistentKeepalive = 25 held ei NAT-tildeling varm;OpenVPN brukar keepalive og ping-restart i begge endar. Begge genererer trafikk på ein elles stille tunnel, så ein hald-i-live som ser ut til å fikse fallet, kan skjule eit radioproblem i staden for å løyse det. Test dei kvar for seg, éin om gongen:

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

Kontroll fem: når radioen er uskuldig

Viss lediggangsfall held fram med straumsparing av og hald-i-live på, sjå utanfor maskina. Aksesspunkt og heimerutarar lèt ledige NAT- eller øktoppføringar gå ut etter sin eigen tidsplan, og ein VPN-server kan droppe ei økt utan trafikk.Roaming mellom aksesspunkt som deler same SSID kan også nullstille sambandet utan at klienten seier det tydeleg.

Samanlikn deretter med eit anna apparat på same nettverk som gjer den same lediggangstesten. To apparat som fell med same intervall, er ei historie om veg eller tenar; eitt apparat som fell, er ei lokal historie om drivar eller straum. Den samanlikninga kostar ti minutt og sparer deg for å skrive om feil konfigurasjon.

Før du gjer det varig

Avgjer kva du er viljug til å behalde. Eit skript per profil som slår av straumsparing berre på netverka der du har sett fallet, er forsvarleg. Ei global endring som slår av alt og blir betalt med batteritid på kvart nettverk, er det vanlegvis ikkje.

  • Skriv ned den opphavlege straumsparingsverdien ved sida av skriptet, slik at han kan gjenopprettast.
  • Gjer lediggangstesten om att etter kvar drivar- eller klientoppdatering; standardverdiane endrar seg.
  • Hald ping-loggen og klientloggen saman når du rapporterer problemet.
  • Viss steg to feila, slutt å endre VPN-innstillingar og handsam det som ein lokal feil i sambandet.

Viss du berre gjer éin ting, gjer kontroll to. Den avgjer om resten av denne lista i det heile gjeld for deg, og det er steget folk hoppar over når dei først har bestemt at svaret er straumsparing.

Relaterte artiklar