VPN pārtraukumu tukšgaitā novēršana: Wi-Fi enerģijas taupīšanas kontrolsaraksts

Izejiet VPN pārtraukumus tukšgaitā pēc kārtas: apstipriniet laiku, atdaliet radio no tuneļa, izlasiet īsto enerģijas taupīšanas stāvokli, pēc tam nomainiet vienu iestatījumu un pārbaudiet vēlreiz.

Jūsu tunelis mirst pēc tam, kad klēpjdators kādu laiku paliek neaiztikts, un atgriežas tajā mirklī, kad pieskaraties skārienpaliktnim. Šis modelis norāda, ka bezvadu saite pāriet enerģijas taupīšanas režīmā, nevis ka VPN vārteja noraida jūsu akreditācijas datus. Aizņemts rīts tajā pašā profilā ir pierādījums: tunelis dzīvo, kamēr plūst satiksme, un krīt, tiklīdz radio apklust. Izpildiet turpmākās pārbaudes pēc kārtas, apstājieties pie pirmās neveiksmīgās un tikai tad nomainiet vienu iestatījumu.

Pirmā pārbaude: vai pārtraukums seko tukšgaitai?

Sāciet ar korelācijas pierādīšanu, nevis pieņēmumu. Pierakstiet pēdējās nosūtītās paketes sienas pulksteņa laiku, laiku, kad klients ziņoja par tuneļa kritienu, un vai starplaikā izslēdzās ekrāns. Ja starpība katru reizi ir tāda pati, jums ir problēma tukšgaitas ceļā; ja pārtraukumi aktīvas lietošanas laikā notiek nejauši, pārejiet uz piekto pārbaudi.

Lēts tests, kura atcelšana neko nemaksā: divdesmit minūtes sūtiet vienmērīgu zemas frekvences ping uz savu vārteju un atstājiet mašīnu vienu. Ja tunelis iztur visu laiku, pastāvīga neliela satiksme maskē simptomu, nevis to novērš, kas tomēr ir noderīgs pierādījums. Es glabāju šī ping izvadi melnraksta terminālī un vēlāk salīdzinu ar klienta žurnālu, jo divi pulksteņi reti sakrīt.

Otrā pārbaude: vai tas ir tikai VPN satiksme?

Pirms vainot tuneli, noskaidrojiet, vai pati saite vēl ir lietojama. Kamēr tunelis ir miris, bet ekrāns vēl izslēgts, mēģiniet sasniegt piekļuves punkta adresi un publisku resursdatoru ar IP. Ja neizdodas arī parastais ping, radio vai piekļuves punkts jūs ir atlaidis, un VPN klients ir tikai novērotājs.

Ja parastā satiksme plūst, kamēr tunelis klusē, saite ir vesela un problēma ir paša tuneļa taimeros vai tajā, kā klients apstrādā atsākšanu. Tie ir divi dažādi labojumi, tāpēc neizlaidiet šo soli. Klēpjdatorā ar Wi-Fi un Ethernet vienlaikus izvelciet kabeli un atkārtojiet tukšgaitas testu: tukšgaitas pārtraukums, kas pazūd vadu Ethernet, ir spēcīgs pierādījums bezvadu slāņa labā.

Trešā pārbaude: izlasiet enerģijas taupīšanas stāvokli

Lielākā daļa darbvirsmju dod jums izvēles rūtiņu, bet rūtiņa nav stāvoklis, kurā atrodas draiveris. Vispirms izlasiet paša draivera ziņojumu, tad izlemiet. Linux ar mac80211 saskarne atbild tieši:

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

Otrā komanda ir tests, nevis labojums. Tā nepārdzīvo atvienošanu, miegu vai restartu, kas padara to par tīru veidu, kā pārbaudīt hipotēzi, neatstājot pastāvīgas izmaiņas.

Windows powercfg /q SCHEME_CURRENT izdrukā aktīvo shēmu, un bezvadu adaptera apakškoks parāda, vai adapterim var pavēlēt taupīt enerģiju; tā pati izvēle ir arī Device Manager adaptera enerģijas pārvaldības cilnē. macOS 802.11 enerģijas taupīšana katram interfeisam jums netiek rādīta, tāpēc tā vietā skatiet pmset -g miega un gaidīšanas uzvedību. Tur kļūme parasti izrādās miega un pamošanās ceļš, nevis radio tukšgaitas uzvedība.

Ceturtā pārbaude: nomainiet vienu lietu, tad pārbaudiet vēlreiz

Katrā palaidienā nomainiet tieši vienu mainīgo un atkārtojiet to pašu slodzi. Ja tunelis tagad iztur stundu tukšgaitas ar izslēgtu enerģijas taupīšanu, jūs uzzinājāt kaut ko īstu. Ja tas joprojām krīt, atgrieziet izmaiņu pirms nākamās idejas testēšanas, citādi paliksiet ar trim pārklājošiem iestatījumiem un bez nojausmas, kurš ir svarīgs.

Savienojuma uzturēšana dzīvu ir otrs neatkarīgais mainīgais, un to pastāvīgi jauc ar enerģijas taupīšanu. WireGuard PersistentKeepalive = 25 uztur NAT kartējumu siltu;OpenVPN abos galos keepalive un ping-restart izmanto. Abi ģenerē satiksmi citādi klusā tunelī, tāpēc dzīvības uzturēšana, kas šķietami novērš pārtraukumu, var slēpt radio problēmu, nevis to atrisināt. Pārbaudiet tos atsevišķi, pa vienam:

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

Piektā pārbaude: kad radio ir nevainīgs

Ja tukšgaitas pārtraukumi turpinās ar izslēgtu enerģijas taupīšanu un ieslēgtu dzīvības uzturēšanu, skatieties ārpus klēpjdatora. Piekļuves punkti un mājas maršrutētāji ļauj tukšgaitas NAT vai sesijas ierakstiem beigties pēc sava grafika, un VPN serveris var nomest sesiju bez satiksmes.Viesabonēšana starp piekļuves punktiem, kas dala vienu SSID, arī var atiestatīt saiti, klientam to skaidri nesakot.

Pēc tam salīdziniet ar otru ierīci tajā pašā tīklā, kas veic to pašu tukšgaitas testu. Divas ierīces, kas krīt vienā intervālā, ir ceļa vai servera stāsts; viena krītoša ierīce ir vietējs draivera vai enerģijas stāsts. Šis salīdzinājums maksā desmit minūtes un pasargā jūs no nepareizas konfigurācijas pārrakstīšanas.

Pirms padarāt to pastāvīgu

Izlemiet, ko esat gatavs paturēt. Skripts katram profilam, kas izslēdz enerģijas taupīšanu tikai tajos tīklos, kur redzējāt pārtraukumu, ir aizstāvams. Globāls pielāgojums, kas izslēdz visu un tiek apmaksāts ar akumulatora darbības laiku katrā tīklā, parasti nav.

  • Pierakstiet sākotnējo enerģijas taupīšanas vērtību blakus skriptam, lai to varētu atjaunot.
  • Atkārtojiet tukšgaitas testu pēc katras draivera vai klienta atjaunināšanas; noklusējuma vērtības mainās.
  • Kad ziņojat par problēmu, turiet ping žurnālu un klienta žurnālu kopā.
  • Ja otrais solis neizdevās, pārtrauciet mainīt VPN iestatījumus un uzskatiet to par vietēju saites kļūmi.

Ja darāt tikai vienu lietu, veiciet otro pārbaudi. Tā izšķir, vai pārējais šajā sarakstā uz jums vispār attiecas, un tieši šo soli cilvēki izlaiž, kad jau ir nolēmuši, ka atbilde ir enerģijas taupīšana.

Saistītie raksti