Herstel VPN-onderbrekings tydens onaktiwiteit: 'n kontrolelys vir Wi-Fi-kragbesparing

Jou tonnel val weg nadat die skootrekenaar 'n ruk ongemoeid bly, en dit kom terug sodra jy die trackpad aanraak. Daardie patroon dui daarop dat die draadlose skakel in kragbesparing ingaan, nie dat die VPN-gateway jou geloofsbriewe verwerp nie. 'n Besige oggend op dieselfde profiel is die teken: die tonnel bly lewendig terwyl verkeer vloei en val weg sodra die radio stil word. Werk die kontroles hieronder in volgorde deur, stop by die eerste een wat misluk, en verander eers dan een instelling.

Kontrole een: volg die onderbreking op onaktiwiteit?

Begin deur die korrelasie te bewys eerder as om dit te aanvaar. Teken die muurkloktyd aan van die laaste pakkie wat jy gestuur het, die tyd toe die kliënt gerapporteer het dat die tonnel af is, en of die skerm intussen afgegaan het. As die gaping elke keer dieselfde is, het jy 'n onaktiwiteitsprobleem; as onderbrekings lukraak tydens aktiewe gebruik voorkom, gaan na kontrole vyf.

'n Goedkoop toets wat niks kos om ongedaan te maak nie: stuur twintig minute lank 'n bestendige lae-tempo ping na jou gateway en los die masjien alleen. As die tonnel die hele lopie op bly, verdoesel konstante klein verkeer die simptoom eerder as om dit reg te maak, wat steeds nuttige bewyse is. Ek hou daardie ping-uitset in 'n kras-terminaal en vergelyk dit agterna met die kliëntlog, want die twee klokke stem selde ooreen.

Kontrole twee: is dit net VPN-verkeer?

Voordat jy die tonnel blameer, vind uit of die skakel self nog bruikbaar is. Terwyl die tonnel dood is maar die skerm nog af is, probeer om die toegangspuntadres en 'n publieke gasheer per IP te bereik. As die gewone ping ook misluk, het die radio of die toegangspunt jou laat val en is die VPN-kliënt net 'n omstander.

As gewone verkeer vloei terwyl die tonnel stil bly, is die skakel gesond en sit die probleem in die tonnel se eie tydhouers of in hoe die kliënt 'n hervatting hanteer. Dit is twee verskillende regstellings, so moenie hierdie stap oorslaan nie. Op 'n skootrekenaar met beide Wi-Fi en Ethernet, trek die kabel uit en herhaal die onaktiwiteitstoets: 'n onaktiwiteitsonderbreking wat op bedrade Ethernet verdwyn, is sterk bewyse vir die draadlose laag.

Kontrole drie: lees die kragbesparingstatus

Die meeste werkskerms gee jou 'n merkblokkie, maar die merkblokkie is nie die toestand waarin die drywer is nie. Lees eers die drywer se eie verslag en besluit dan. Op Linux met mac80211 antwoord die koppelvlak direk:

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

Die tweede opdrag is 'n toets, nie 'n regstelling nie. Dit oorleef nie 'n ontkoppeling, slaap of herbegin nie, wat dit 'n skoon manier maak om die hipotese te toets sonder om permanente veranderinge agter te laat.

Op Windows druk powercfg /q SCHEME_CURRENT die aktiewe skema uit, en die substruktuur vir die draadlose adapter wys of die adapter opdrag kan kry om krag te bespaar; dieselfde keuse staan ook in Device Manager op die adapter se kragbestuuroortjie. Op macOS word die 802.11-kragbesparing per koppelvlak nie aan jou blootgestel nie, so kyk eerder na pmset -g vir slaap- en standbystatus. Daar blyk die fout gewoonlik die slaap-en-waak-pad te wees eerder as die radio se onaktiwiteitsgedrag.

Kontrole vier: verander een ding en toets weer

Verander presies een veranderlike per lopie en herhaal dieselfde werklading. As die tonnel nou 'n onaktiewe uur oorleef met kragbesparing af, het jy iets werkliks geleer. As dit steeds val, draai dit terug voordat jy die volgende idee toets, anders sit jy met drie oorvleuelende instellings en geen idee watter een saak maak nie.

Die lewendighoudfunksie is die ander onafhanklike veranderlike, en dit word gedurig met kragbesparing verwar. WireGuard se PersistentKeepalive = 25 hou 'n NAT-kaart lewendig;OpenVPN gebruik keepalive en ping-restart aan beide kante. Albei genereer verkeer op 'n andersins stil tonnel, so 'n lewendighouding wat die onderbreking blykbaar oplos, verberg miskien 'n radioprobleem eerder as om dit op te los. Toets hulle afsonderlik, een op 'n slag:

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

Kontrole vyf: wanneer die radio onskuldig is

As onaktiwiteitsonderbrekings voortduur met kragbesparing af en lewendighouding aan, kyk buite die skootrekenaar. Toegangspunte en verbruikersroeteerders laat onaktiewe NAT- of sessie-inskrywings volgens hul eie skedule verval, en 'n VPN-bediener kan 'n sessie laat val wat geen verkeer het nie.Roaming tussen toegangspunte wat een SSID deel, kan ook die skakel laat herbegin sonder dat die kliënt dit duidelik sê.

Vergelyk dit dan met 'n tweede toestel op dieselfde netwerk wat dieselfde onaktiwiteitstoets doen. Twee toestelle wat teen dieselfde interval val, is 'n verhaal oor die pad of die bediener; een toestel wat val, is 'n plaaslike drywer- of kragverhaal. Daardie vergelyking kos tien minute en spaar jou daarvan om die verkeerde konfigurasie te herskryf.

Voordat jy dit permanent maak

Besluit wat jy bereid is om te hou. 'n Script per profiel wat kragbesparing net op die netwerke afskakel waar jy die onderbreking gesien het, is verdedigbaar. 'n Globale aanpassing wat alles afskakel en met batterylewe op elke netwerk betaal word, is gewoonlik nie.

• Teken die oorspronklike kragbesparingswaarde langs die script aan sodat dit herstel kan word.
• Herhaal die onaktiwiteitstoets ná elke drywer- of kliëntopdatering; verstekwaardes verander.
• Hou die ping-log en die kliëntlog bymekaar wanneer jy die probleem rapporteer.
• As stap twee misluk het, stop om VPN-instellings te verander en hanteer dit as 'n plaaslike skakelfout.

As jy net een ding doen, doen kontrole twee. Dit bepaal of die res van hierdie lys hoegenaamd op jou van toepassing is, en dit is die stap wat mense oorslaan sodra hulle reeds besluit het die antwoord is kragbesparing.