Ayusin ang pagkaputol ng VPN habang walang ginagawa: isang checklist para sa Wi-Fi power save

Namamatay ang tunnel mo matapos manatiling hindi hinahawakan ang laptop nang ilang sandali, at bumabalik ito sa sandaling hawakan mo ang trackpad. Ang pattern na iyon ay tumuturo sa wireless link na pumapasok sa power save, hindi sa VPN gateway na tumatanggi sa iyong mga kredensyal. Ang abalang umaga sa parehong profile ang patunay: nabubuhay ang tunnel habang umaagos ang trapiko at bumabagsak kapag tumahimik ang radyo. Daanan ang mga tseke sa ibaba nang sunod-sunod, huminto sa unang mabigo, at pagkatapos lang ay baguhin ang isang setting.

Unang tseke: sinusundan ba ng pagkaputol ang kawalan ng ginagawa?

Magsimula sa pagpapatunay ng ugnayan sa halip na ipagpalagay ito. Itala ang oras ng dingding ng huling packet na ipinadala mo, ang oras na iniulat ng client na bumagsak ang tunnel, at kung namatay ang screen sa pagitan. Kung pareho ang agwat sa bawat pagkakataon, may problema ka sa landas ng kawalan ng ginagawa; kung random ang pagkaputol habang aktibong ginagamit, tumalon sa ikalimang tseke.

Isang murang pagsubok na walang gastos na bawiin: magpadala ng tuloy-tuloy na ping na mababa ang rate sa iyong gateway sa loob ng dalawampung minuto at iwanang mag-isa ang makina. Kung mananatili ang tunnel sa buong pagsubok, tinatakpan ng palagiang maliit na trapiko ang sintomas sa halip na ayusin ito, na kapaki-pakinabang pa ring ebidensya. Itinatago ko ang output ng ping na iyon sa isang draft terminal at pagkatapos ay inihahambing sa log ng client, dahil bihirang magkasundo ang dalawang orasan.

Ikalawang tseke: trapiko ba ng VPN lang ito?

Bago sisihin ang tunnel, alamin kung magagamit pa ang link mismo. Habang patay ang tunnel pero nakapatay pa ang screen, subukang maabot ang address ng access point at isang pampublikong host sa pamamagitan ng IP. Kung nabigo rin ang ordinaryong ping, iniwan ka ng radyo o ng access point, at ang VPN client ay manonood lamang.

Kung umaagos ang ordinaryong trapiko habang tahimik ang tunnel, malusog ang link at ang problema ay nasa mga timer ng tunnel mismo o sa paraan ng paghawak ng client sa pagpapatuloy. Dalawang magkaibang pagtatama iyon, kaya huwag laktawan ang hakbang na ito. Sa laptop na may Wi-Fi at Ethernet nang sabay, tanggalin ang cable at ulitin ang pagsubok sa kawalan ng ginagawa: ang pagkaputol na nawawala sa may-kable na Ethernet ay malakas na ebidensya para sa wireless layer.

Ikatlong tseke: basahin ang estado ng power save

Karamihan sa mga desktop ay nagbibigay sa iyo ng checkbox, pero ang checkbox ay hindi ang estadong kinalalagyan ng driver. Basahin muna ang sariling ulat ng driver, pagkatapos ay magpasya. Sa Linux na may mac80211, direktang sumasagot ang interface:

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

Ang pangalawang utos ay pagsubok, hindi pagtatama. Hindi ito nakakaligtas sa disconnect, pagtulog o reboot, kaya nagiging malinis na paraan ito upang subukan ang hypothesis nang walang naiiwang permanenteng pagbabago.

Sa Windows powercfg /q SCHEME_CURRENT ipinapakita nito ang aktibong scheme, at ang subtree ng wireless adapter ay nagpapakita kung maaaring utusan ang adapter na magtipid ng enerhiya; ang parehong pagpipilian ay nasa Device Manager din sa tab ng pamamahala ng enerhiya ng adapter. Sa macOS, ang power save na 802.11 bawat interface ay hindi inilalantad sa iyo, kaya tumingin sa halip sa pmset -g para sa gawi sa pagtulog at standby. Doon, ang sira ay kadalasang lumalabas na landas ng pagtulog at paggising at hindi ang gawi ng radyo sa kawalan ng ginagawa.

Ikaapat na tseke: baguhin ang isang bagay, pagkatapos ay subukan muli

Baguhin ang eksaktong isang variable bawat takbo at ulitin ang parehong karga. Kung nakakalusot na ngayon ang tunnel sa isang oras na walang ginagawa nang patay ang power save, may natutunan kang totoo. Kung bumabagsak pa rin, ibalik ito bago subukan ang susunod na ideya, kung hindi ay maiiwan ka sa tatlong magkakapatong na setting at walang ideya kung alin ang mahalaga.

Ang pagpapanatiling buhay ng koneksyon ang isa pang malayang variable at palagi itong napagkakamalang power save. Ang PersistentKeepalive = 25 ng WireGuard ay nagpapanatiling mainit ng isang NAT mapping;OpenVPN sa dalawang dulo keepalive at ping-restart ang ginagamit. Pareho silang gumagawa ng trapiko sa isang tunnel na kung hindi ay tahimik, kaya ang pagpapanatiling buhay na tila nag-aayos ng pagkaputol ay maaaring nagtatago ng problema sa radyo sa halip na lutasin ito. Subukan sila nang hiwalay, isa-isa:

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

Ikalimang tseke: kapag walang kasalanan ang radyo

Kung nagpapatuloy ang pagkaputol sa kawalan ng ginagawa kahit patay ang power save at buhay ang pagpapanatili, tumingin sa labas ng laptop. Ang mga access point at router sa bahay ay hinahayaang mag-expire ang mga entry ng NAT o session kapag walang ginagawa ayon sa sarili nilang iskedyul, at ang isang VPN server ay maaaring mag-drop ng session na walang trapiko.Ang roaming sa pagitan ng mga access point na nagbabahagi ng isang SSID ay maaari ring i-reset ang link nang hindi ito malinaw na sinasabi ng client.

Pagkatapos ay ihambing sa isang pangalawang device sa parehong network na gumagawa ng parehong pagsubok sa kawalan ng ginagawa. Dalawang device na bumabagsak sa parehong agwat ay kuwento ng landas o server; isang device na bumabagsak ay lokal na kuwento ng driver o enerhiya. Ang paghahambing na iyon ay tumatagal ng sampung minuto at inililigtas ka sa muling pagsulat ng maling configuration.

Bago mo gawing permanente

Magpasya kung ano ang handa kang itago. Ang script bawat profile na nagpapatay ng power save lamang sa mga network kung saan nakita mo ang pagkaputol ay katanggaptanggap. Ang pandaigdigang pagbabago na nagpapatay ng lahat at binabayaran ng buhay ng baterya sa bawat network ay karaniwang hindi.

• Itala ang orihinal na halaga ng power save sa tabi ng script upang maibalik ito.
• Ulitin ang pagsubok sa kawalan ng ginagawa pagkatapos ng bawat update ng driver o client; nagbabago ang mga default.
• Panatilihing magkasama ang ping log at ang client log kapag iniuulat mo ang problema.
• Kung nabigo ang ikalawang hakbang, itigil ang pagbabago ng mga setting ng VPN at ituring itong lokal na sira ng link.

Kung isang bagay lang ang gagawin mo, gawin ang ikalawang tseke. Iyon ang nagpapasya kung talagang naaangkop sa iyo ang natitirang listahan, at iyon ang hakbang na nilalaktawan ng mga tao kapag napagpasya na nilang power save ang sagot.