Ripari VPN-interrompojn dum senaktiveco: kontrolo-listo por Wi-Fi-energiŝparado

Trairu la VPN-interrompojn dum senaktiveco laŭvice: konfirmu la tempon, apartigu la radion de la tunelo, legu la realan energiŝparan staton, poste ŝanĝu unu agordon kaj retestu.

Via tunelo mortas post kiam la tekkomputilo restas netuŝita dum iom da tempo, kaj ĝi revenas en la momento, kiam vi tuŝas la tuŝplaton. Tiu ŝablono indikas, ke la sendrata ligo eniras energiŝparadon, ne ke la VPN-enirejo rifuzas viajn legitimilojn. Okupata mateno sur la sama profilo estas la pruvo: la tunelo postvivas dum trafiko fluas kaj falas, tuj kiam la radio silentas. Trairu la subajn kontrolojn laŭvice, haltu ĉe la unua, kiu malsukcesas, kaj nur tiam ŝanĝu agordon.

Kontrolo unu: ĉu la interrompo sekvas senaktivecon?

Komencu pruvante la korelacion anstataŭ supozi ĝin. Notu la murhorloĝan tempon de la lasta sendita pako, la tempon, kiam la kliento raportis la tunelon malsupren, kaj ĉu la ekrano malŝaltiĝis intertempe. Se la breĉo estas la sama ĉiufoje, vi havas problemon sur la senaktiveca vojo; se interrompoj okazas hazarde dum aktiva uzo, saltu al la kvina kontrolo.

Malmultekosta testo, kiu kostas nenion por malfari: sendu stabilan malaltfrekvencan ping al via enirejo dum dudek minutoj kaj lasu la maŝinon sola. Se la tunelo restas supren la tutan tempon, konstanta malgranda trafiko kaŝas la simptomon anstataŭ ripari ĝin, kio tamen estas utila pruvo. Mi tenas tiun ping-eliron en skiza terminalo kaj poste komparas ĝin kun la klienta protokolo, ĉar la du horloĝoj malofte kongruas.

Kontrolo du: ĉu temas nur pri VPN-trafiko?

Antaŭ ol kulpigi la tunelon, eltrovu, ĉu la ligo mem ankoraŭ estas uzebla. Dum la tunelo estas morta sed la ekrano ankoraŭ malŝaltita, provu atingi la adreson de la alirpunkto kaj publikan gastiganton per IP. Se ankaŭ la ordinara ping malsukcesas, la radio aŭ la alirpunkto faligis vin, kaj la VPN-kliento estas nur observanto.

Se ordinara trafiko fluas dum la tunelo silentas, la ligo estas sana kaj la problemo kuŝas en la propraj tempigiloj de la tunelo aŭ en tio, kiel la kliento traktas rekomencon. Tiuj estas du malsamaj riparoj, do ne preterlasu ĉi tiun paŝon. Sur tekkomputilo kun kaj Wi-Fi kaj Ethernet, malŝtopu la kablon kaj ripetu la senaktivecan teston: senaktiveca interrompo, kiu malaperas sur kabla Ethernet, estas forta pruvo por la sendrata tavolo.

Kontrolo tri: legu la energiŝparan staton

Plej multaj labortablaj medioj donas al vi markobutonon, sed la markobutono ne estas la stato, en kiu troviĝas la pelilo. Unue legu la propran raporton de la pelilo, poste decidu. Sur Linux kun mac80211 la interfaco respondas rekte:

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

La dua komando estas testo, ne riparo. Ĝi ne postvivas malkonekton, dormon aŭ restartigon, kio faras ĝin pura maniero kontroli la hipotezon sen lasi daŭrajn ŝanĝojn.

Sur Windows powercfg /q SCHEME_CURRENT presas la aktivan skemon, kaj la subarbo de la sendrata adaptilo montras, ĉu oni povas ordoni al la adaptilo ŝpari energion; la sama elekto troviĝas ankaŭ en Device Manager sur la langeto pri energia administrado de la adaptilo. Sur macOS la 802.11-energiŝparado por interfaco ne estas montrata al vi, do rigardu anstataŭe pmset -g por dorma kaj atenda konduto. Tie la paneo kutime montriĝas esti la dorma kaj vekiĝa vojo, ne la senaktiveca konduto de la radio.

Kontrolo kvar: ŝanĝu unu aferon, poste retestu

Ŝanĝu precize unu variablon por kurado kaj ripetu la saman ŝarĝon. Se la tunelo nun postvivas senaktivan horon kun energiŝparado malŝaltita, vi lernis ion realan. Se ĝi ankoraŭ falas, malfaru antaŭ ol testi la sekvan ideon, alie vi restos kun tri interkovrantaj agordoj kaj neniu ideo, kiu gravas.

Tenado de la ligo viva estas la alia sendependa variablo kaj ĝi konstante miksiĝas kun energiŝparado. La PersistentKeepalive = 25 de WireGuard tenas NAT-mapadon varma;OpenVPN uzas keepalive kaj ping-restart ĉe ambaŭ flankoj. Ambaŭ generas trafikon sur alie silenta tunelo, do vivtenado, kiu ŝajne riparas la interrompon, povas kaŝi radian problemon anstataŭ solvi ĝin. Testu ilin aparte, unu post la alia:

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

Kontrolo kvin: kiam la radio estas senkulpa

Se senaktivecaj interrompoj restas kun energiŝparado malŝaltita kaj vivtenado ŝaltita, rigardu ekster la tekkomputilon. Alirpunktoj kaj hejmaj enkursigiloj lasas senaktivecajn NAT- aŭ sesiajn rikordojn eksvalidiĝi laŭ sia propra horaro, kaj VPN-servilo povas faligi sesion sen trafiko.Roaming inter alirpunktoj, kiuj dividas unu SSID, ankaŭ povas restarigi la ligon sen ke la kliento tion klare diru.

Poste komparu kun dua aparato en la sama reto faranta la saman senaktivecan teston. Du aparatoj falantaj je la sama intervalo estas rakonto pri vojo aŭ servilo; unu falanta aparato estas loka rakonto pri pelilo aŭ energio. Tiu komparo kostas dek minutojn kaj ŝparas al vi reverki la malĝustan agordon.

Antaŭ ol vi faros ĝin daŭra

Decidu, kion vi pretas konservi. Skripto por profilo, kiu malŝaltas energiŝparadon nur en la retoj, kie vi vidis la interrompon, estas defendebla. Tutmonda aliĝo, kiu malŝaltas ĉion page per bateria vivo en ĉiu reto, kutime ne.

  • Notu la originan energiŝparan valoron apud la skripto, por ke ĝi povu esti restarigita.
  • Ripetu la senaktivecan teston post ĉiu pelila aŭ klienta ĝisdatigo; defaŭltoj ŝanĝiĝas.
  • Tenu la ping-protokolon kaj la klientan protokolon kune, kiam vi raportas la problemon.
  • Se la dua paŝo malsukcesis, ĉesu ŝanĝi VPN-agordojn kaj traktu tion kiel lokan ligan paneon.

Se vi faros nur unu aferon, faru la duan kontrolon. Ĝi decidas, ĉu la resto de ĉi tiu listo entute koncernas vin, kaj ĝi estas la paŝo, kiun homoj preterlasas, post kiam ili jam decidis, ke la respondo estas energiŝparado.

Rilataj artikoloj