Rješavanje prekida VPN-a tijekom mirovanja: kontrolni popis za Wi-Fi uštedu energije

Prođite kroz prekide VPN-a tijekom mirovanja redom: potvrdite vrijeme, odvojite radio od tunela, pročitajte stvarno stanje uštede energije, zatim promijenite jednu postavku i ponovno testirajte.

Tunel umire nakon što prijenosnik neko vrijeme stoji netaknut, a vraća se u trenutku kad dotaknete trackpad. Taj obrazac upućuje na bežičnu vezu koja ulazi u uštedu energije, a ne na VPN pristupnik koji odbija vaše vjerodajnice. Zauzeto jutro na istom profilu je dokaz: tunel preživljava dok promet teče, a pada čim radio utihne. Prođite kroz provjere u nastavku redom, zaustavite se na prvoj koja ne uspije i tek tada promijenite postavku.

Prva provjera: prati li prekid mirovanje?

Počnite dokazivanjem korelacije umjesto pretpostavke. Zabilježite zidno vrijeme zadnjeg poslanog paketa, vrijeme kada je klijent javio da je tunel pao i je li se zaslon u međuvremenu isključio. Ako je razmak svaki put isti, imate problem na putu mirovanja; ako se prekidi javljaju nasumično tijekom aktivnog rada, prijeđite na petu provjeru.

Jeftin test koji ništa ne košta poništiti: dvadeset minuta šaljite ravnomjeran ping niske stope prema svom pristupniku i ostavite stroj na miru. Ako tunel izdrži cijelo vrijeme, stalni mali promet prikriva simptom umjesto da ga rješava, što je još uvijek koristan dokaz. Taj ping izlaz držim u pomoćnom terminalu i poslije ga uspoređujem s klijentskim zapisom, jer se dva sata rijetko slažu.

Druga provjera: je li to samo VPN promet?

Prije nego okrivite tunel, utvrdite je li sama veza još upotrebljiva. Dok je tunel mrtav, a zaslon još isključen, pokušajte doći do adrese pristupne točke i javnog hosta preko IP-a. Ako i obični ping ne uspije, radio ili pristupna točka su vas ispustili, a VPN klijent je samo promatrač.

Ako običan promet teče dok tunel šuti, veza je zdrava i problem je u tunelovim vlastitim timerima ili u tome kako klijent obrađuje nastavak. To su dvije različite popravke, pa nemojte preskočiti ovaj korak. Na prijenosniku s Wi-Fi i Ethernet vezom istodobno iskopčajte kabel i ponovite test mirovanja: prekid mirovanja koji nestaje na žičanom Ethernetu jak je dokaz za bežični sloj.

Treća provjera: pročitajte stanje uštede energije

Većina radnih okruženja daje vam potvrdni okvir, ali okvir nije stanje u kojem se upravljački program nalazi. Prvo pročitajte vlastito izvješće upravljačkog programa, pa odlučite. Na Linuxu s mac80211 sučelje odgovara izravno:

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

Druga naredba je test, a ne popravak. Ne preživljava odspajanje, suspenziju ni ponovno pokretanje, što je čini čistim načinom provjere hipoteze bez ostavljanja trajnih promjena.

Na Windowsima powercfg /q SCHEME_CURRENT ispisuje aktivnu shemu, a podstablo bežičnog adaptera pokazuje može li se adapteru narediti da štedi energiju; isti izbor stoji i u Device Manageru na kartici za upravljanje napajanjem adaptera. Na macOS-u ušteda energije 802.11 po sučelju nije vam izložena, pa umjesto toga pogledajte pmset -g za ponašanje pri spavanju i stanju pripravnosti. Ondje se kvar obično pokaže na putu spavanja i buđenja, a ne u ponašanju radija tijekom mirovanja.

Četvrta provjera: promijenite jednu stvar, pa ponovno testirajte

Promijenite točno jednu varijablu po pokretanju i ponovite isto radno opterećenje. Ako tunel sada izdrži sat mirovanja s isključenom uštedom energije, naučili ste nešto stvarno. Ako još pada, vratite promjenu prije testiranja sljedeće ideje, inače ostajete s tri preklapajuće postavke i bez pojma koja je važna.

Održavanje veze na životu druga je neovisna varijabla i stalno se brka s uštedom energije. Vrijednost PersistentKeepalive = 25 u WireGuardu drži NAT zapis toplim;OpenVPN koristi keepalive i ping-restart na oba kraja. Oba stvaraju promet na inače tihom tunelu, pa održavanje veze koje naizgled rješava prekid može skrivati problem radija umjesto da ga rješava. Testirajte ih odvojeno, jednu po jednu:

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

Peta provjera: kad je radio nevin

Ako prekidi mirovanja opstaju s isključenom uštedom energije i uključenim održavanjem veze, gledajte izvan prijenosnika. Pristupne točke i kućni usmjerivači istječu NAT ili sesijske zapise mirovanja po vlastitom rasporedu, a VPN poslužitelj može ispustiti sesiju bez prometa.Roaming između pristupnih točaka koje dijele isti SSID također može resetirati vezu, a da klijent to jasno ne kaže.

Zatim usporedite s drugim uređajem na istoj mreži koji radi isti test mirovanja. Dva uređaja koja padaju u istom intervalu priča su o putu ili poslužitelju; jedan uređaj koji pada priča je o lokalnom upravljačkom programu ili napajanju. Ta usporedba košta deset minuta i spašava vas od prepisivanja pogrešne konfiguracije.

Prije nego to učinite trajnim

Odlučite što ste spremni zadržati. Skripta po profilu koja isključuje uštedu energije samo na mrežama gdje ste vidjeli prekid je obranjiva. Globalna izmjena koja isključuje sve uz cijenu trajanja baterije na svakoj mreži obično nije.

  • Zapišite izvornu vrijednost uštede energije uz skriptu kako bi se mogla vratiti.
  • Ponovno pokrenite test mirovanja nakon svakog ažuriranja upravljačkog programa ili klijenta; zadane vrijednosti se mijenjaju.
  • Držite ping zapis i klijentski zapis zajedno kad prijavljujete problem.
  • Ako je drugi korak pao, prestanite mijenjati VPN postavke i tretirajte to kao lokalni kvar veze.

Ako učinite samo jednu stvar, učinite drugu provjeru. Ona odlučuje odnosi li se ostatak ovog popisa uopće na vas, i to je korak koji ljudi preskoče kad su već odlučili da je odgovor ušteda energije.

Povezani članci