VPN nutrūksta, kai ekranas patamsėja: užrakinimas, išjungimas ar miegojimas?
Užrakinta sesija, patamsėjęs ekranas ir mieganti mašina yra trys skirtingi įvykiai. Susiekite juos su journalctl, prieš kaltindami VPN ryšio palaikymo mechanizmą.
Kai kas nors sako, kad VPN mirė, kai ekranas patamsėjo, pirmas naudingas klausimas yra kuris iš trijų įvykių iš tikrųjų įvyko: sesija buvo užrakinta, skydelis išsijungė, ar visa mašina užmigo. Tai atskiri mechanizmai su atskirais laikmačiais, ir tik vienas iš jų gali visiškai sutrukdyti planuoti procesą. Peržiūrėkite žemiau pateiktus patikrinimus iš eilės. Sustokite prie pirmo, kuris atsako į klausimą, nes kiekvienas vėlesnis patikrinimas atsako į ką nors kita.
Pirmas patikrinimas: atskirkite užrakinimą nuo išjungimo ir nuo miegojimo
Užrakinimas pakeičia, kam leidžiama naudotis sesija; kompozitorius toliau piešia, tinklo stekas toliau veikia, o VPN klientas nieko nepastebi. Ekrano išjungimas išjungia skydelį po neveiklumo intervalo ir palieka mašiną visiškai pabudusią. Miegojimas sustabdo procesorius, o tai reiškia, kad nė vienas naudotojo erdvės procesas neplanuojamas, todėl joks ryšio palaikymo signalas negali suveikti, kad ir koks trumpas būtų intervalas.
| 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 |
Būtent ši lentelė yra priežastis, kodėl „ekranas patamsėjo“ nėra diagnozė. Darbalaukis, nustatytas patamsėti po penkių minučių ir užmigti po trisdešimties, šeštą minutę rodys tamsų ekraną su visiškai sveiku tuneliu. Gedimas trisdešimtą minutę yra kitas įvykis su kitu sprendimu, ir abu atrodo vienodai iš kitos kambario pusės.
Antras patikrinimas: sudėkite energijos ir tinklo įvykius į vieną laiko juostą
Skaitykite žurnalą apribotam laikotarpiui, o ne visam paleidimui, ir įtraukite tiek prisijungimo tvarkyklę, tiek ryšio savininką:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list
Pirmoji komanda rodo miegojimo prašymus, pabudimą ir tinklo perėjimus, kurie įvyko po jų. Antroji rodo, kas šiuo metu laiko inhibitoriaus užraktą, o tai pasako, ar kažkas tyčia blokuoja miegojimą, ir kuri programa tai daro. Pakoreguokite vienetų pavadinimus, jei jūsų ryšio savininkas nėra NetworkManager, ir atminkite, kad kito naudotojo vieneto ar sistemos žurnalo skaitymas priklauso nuo vietinės politikos.
Trūkstama eilutė nėra neigiamas rezultatas. Jei pasirinkto vieneto žurnalas nėra matomas jūsų paskyrai, miegojimo įrašo nebuvimas nieko neįrodo, o išvada „jis niekada nemiegojo“ iš tuščio filtro yra kelias, kuriuo žmonės praleidžia savaitę derindami ryšio palaikymo signalus.
Trečias patikrinimas: jei jis užmigo, nuspręskite, ar tai buvo tyčia
Kai tik miegojimo perėjimas atsiranda laiko juostoje, klausimas keičiasi iš „kodėl VPN sugedo“ į „ar mašina apskritai turėjo miegoti“. Nešiojamajame kompiuteryje atsakymas dažnai yra taip, o tunelio nutrūkimas yra laukiamas elgesys, nuo kurio klientas turėtų atsigauti pabudęs. Darbo stotyje, kuri turėtų likti pasiekiama, keisti reikia miegojimo politiką. Nuspręsti, kurią iš šių dviejų mašinų matote, reikia vieno klausimo, ir tai nėra klausimas, į kurį žurnalas gali atsakyti už jus.
Pakeiskite ją per valdiklius, priklausančius prisijungusiai sesijai, arba per administratoriaus palaikomą mechanizmą, jei reikalavimas taikomas visai mašinai. Ekrano tvarkyklės nustatymo redagavimas, kai esate prisijungę kitu naudotoju, yra ne tas pats veiksmas ir atrodys, kad veikė, iki prasidės kita sesija. Visiškas energijos valdymo išjungimas yra platus pirmasis atsakas, kuris kainuoja baterijos veikimo laiką ir paslepia tikrąjį politikos klausimą.
Ketvirtas patikrinimas: jei jis liko pabudęs, pažiūrėkite į tinklą ir klientą
Pabudusi mašina, kuri prarado tunelį, turi vieną iš trijų istorijų: prieigos tinklas nutrūko, VPN klientas sustojo arba buvo paleistas iš naujo, arba serverio pusė leido asociacijai pasibaigti, kol klientas vis dar tikėjo esąs prisijungęs. Palyginkite pagrindinio ryšio įvykio laiko žymes su tunelio įvykiu ir būkite tikslūs, kuris buvo pirmas.
Tada atskirai nuo pradinės sesijos išbandykite atkūrimo kelią. Nauja užklausa per atkurtą tunelį gali pavykti, o ilgalaikė programos sesija, atidaryta prieš nutrūkimą, lieka sugedusi, nes programa laiko pasenusį lizdą arba podėlyje esantį adresą. Tai programos problema, o ne įrodymas, kad tunelis negrįžo.
Ką turi naudinga ataskaita
Užrašykite seką su laiko žymėmis ir savininkais: kada sesija buvo užrakinta, kada ekranas patamsėjo, ar buvo užregistruotas miegojimo prašymas, kada ryšys nutrūko ir grįžo, kada tunelis pakeitė būseną ir ką programa iš tikrųjų padarė. Kiekvienas punktas turi savininką, todėl kiekvieną punktą galima perduoti tinkamam žmogui, o ne paversti bendru skundu apie Linux.
Jei kurios nors iš šių eilučių trūksta, tai yra kitas dalykas, kurį reikia išmatuoti, o ne kitas, kurį reikia pakeisti. Laiko juosta su spraga yra informatyvesnė nei nustatymų pakeitimas, atliktas remiantis nuojauta.