Bumaba ang VPN kapag dumilim ang screen: lock, blangko, o suspend?
Ang naka-lock na session, madilim na screen, at naka-suspend na makina ay tatlong magkaibang pangyayari. I-ugnay ang mga ito sa journalctl bago sisihin ang mekanismo ng pagpapanatili ng koneksyon ng VPN.
Kapag may nagsabing namatay ang VPN nang dumilim ang screen, ang unang kapaki-pakinabang na tanong ay alin sa tatlong pangyayari ang tunay na nangyari: na-lock ang session, napatay ang panel, o natulog ang buong makina. Ito ay magkaibang mekanismo sa magkaibang timer, at isa lamang sa kanila ang ganap na makakapigil sa isang proseso na maiiskedyul. Dumaan sa mga pagsusuri sa ibaba nang sunud-sunod. Huminto sa una na sumasagot sa tanong, dahil ang bawat pagsusuri pagkatapos nito ay sumasagot sa ibang bagay.
Unang pagsusuri: ihiwalay ang lock sa pagdidilim at sa pagtulog
Binabago ng lock kung sino ang pinapayagang gumamit ng session; patuloy na gumuguhit ang compositor, patuloy na tumatakbo ang network stack, at walang napapansin ang kliyente ng VPN. Ang pagdidilim ng screen ay nagpapatay sa panel pagkatapos ng walang galaw na pagitan at iniiwan ang makina na ganap na gising. Ang suspend ay nagpapatigil sa mga CPU, ibig sabihin walang proseso sa espasyo ng gumagamit ang naiiskedyul, kaya walang pagpapanatili ng koneksyon ang makakapagpadala, gaano man kaikli ang pagitan.
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
Ang talahanayang iyon ang dahilan kung bakit ang «dumilim ang screen» ay hindi diagnosis. Ang desktop na nakatakda na dumilim sa limang minuto at mag-suspend sa tatlumpu ay magpapakita ng madilim na screen sa ikaanim na minuto na may ganap na malusog na tunnel. Ang pagkabigo sa ikatatlumpung minuto ay ibang pangyayari na may ibang lunas, at pareho silang magkamukha mula sa kabilang dulo ng silid.
Ikalawang pagsusuri: ilagay ang mga pangyayari sa enerhiya at network sa isang timeline
Basahin ang journal para sa limitadong pagitan sa halip na ang buong boot, at isama kapwa ang tagapamahala ng pag-login at ang may-ari ng koneksyon:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --listIpinapakita ng unang utos ang mga kahilingan sa pagtulog, ang paggising at ang mga pagbabago sa network na sumunod. Ipinapakita ng ikalawa kung ano ang kasalukuyang may hawak ng hadlang na kandado, na nagsasabi sa iyo kung may sadyang humahadlang sa pagtulog at kung aling programa iyon. Ayusin ang mga pangalan ng unit kung ang may-ari ng iyong koneksyon ay hindi NetworkManager, at tandaan na ang pagbasa ng unit ng ibang gumagamit o ng journal ng system ay nakadepende sa lokal na patakaran.
Ang nawawalang linya ay hindi negatibong resulta. Kung ang journal ng piniling unit ay hindi nakikita ng iyong account, walang pinatutunayan ang kawalan ng talaan ng pagtulog, at ang paghihinuha ng «hindi ito natulog kailanman» mula sa walang laman na filter ay siyang paraan kung paano gumugugol ang mga tao ng isang linggo sa pag-aayos ng pagpapanatili ng koneksyon.
Ikatlong pagsusuri: kung natulog ito, magpasya kung sinasadya
Kapag lumitaw ang paglipat sa pagtulog sa timeline, nagbabago ang tanong mula sa bakit nasira ang VPN tungo sa dapat bang natulog ang makina. Sa laptop ang sagot ay madalas oo, at ang pagkaputol ng tunnel ay inaasahang pag-uugali na dapat mabawi ng kliyente paggising. Sa workstation na dapat manatiling maabot, ang patakaran sa pagtulog ang dapat baguhin. Ang pagpapasya kung alin sa dalawang makinang ito ang tinitingnan mo ay nangangailangan ng isang tanong, at hindi iyon tanong na masasagot ng journal para sa iyo.
Baguhin ito sa pamamagitan ng mga kontrol na pag-aari ng naka-login na session, o sa pamamagitan ng mekanismong sinusuportahan ng administrador kung ang pangangailangan ay para sa buong makina. Ang pag-edit ng setting ng tagapamahala ng display habang naka-login sa ibang account ay hindi parehong aksyon at magmumukhang gumana hanggang magsimula ang susunod na session. Ang ganap na pag-off ng pamamahala ng enerhiya ay malawak na unang reaksyon na kumakain ng buhay ng baterya at nagtatago ng tunay na tanong sa patakaran.
Ikaapat na pagsusuri: kung nanatili itong gising, tingnan ang network at ang kliyente
Ang gising na makinang nawalan ng tunnel ay may isa sa tatlong kuwento: bumagsak ang network ng access, huminto o nag-restart ang kliyente ng VPN, o hinayaang mag-expire ng panig ng server ang asosasyon habang patuloy na naniniwala ang kliyente na konektado ito. Ihambing ang mga timestamp ng pinagbabatayan na pangyayari sa link sa pangyayari sa tunnel, at maging tumpak kung alin ang nauna.
Pagkatapos ay subukan ang landas ng pagbawi nang hiwalay sa orihinal na session. Ang bagong kahilingan sa naibalik na tunnel ay maaaring magtagumpay habang ang pangmatagalang session ng aplikasyon na binuksan bago ang pagkaputol ay nananatiling sira, dahil may hawak ang aplikasyon ng lumang socket o naka-cache na address. Iyon ay problema ng aplikasyon, hindi patunay na hindi bumalik ang tunnel.
Ano ang nilalaman ng kapaki-pakinabang na ulat
Isulat ang pagkakasunod-sunod kasama ang mga timestamp at may-ari: kung kailan na-lock ang session, kung kailan dumilim ang screen, kung may naitalang kahilingan sa pagtulog, kung kailan bumagsak at bumalik ang link, kung kailan nagbago ng estado ang tunnel, at kung ano ang aktwal na ginawa ng aplikasyon. Bawat aytem ay may may-ari, kaya bawat aytem ay maaaring ibigay sa tamang tao sa halip na maging pangkalahatang reklamo tungkol sa Linux.
Kung may nawawalang linya sa mga iyon, iyon ang susunod na susukatin at hindi ang susunod na babaguhin. Ang timeline na may puwang ay mas nagbibigay-kaalaman kaysa sa pagbabago ng setting na ginawa batay sa hula.