VPN pada kad se ekran zamrači: zaključavanje, prazan ekran ili suspenzija?
Zaključana sesija, zamračen ekran i suspendirano računalo tri su različita događaja. Povežite ih s journalctl prije nego okrivite VPN-ov mehanizam za održavanje veze.
Kada netko kaže da je VPN umro kad se ekran zamračio, prvo korisno pitanje je koji se od tri događaja zapravo dogodio: sesija se zaključala, ploča se isključila ili je cijelo računalo otišlo u san. To su odvojeni mehanizmi na odvojenim tajmerima i samo jedan od njih može potpuno zaustaviti zakazivanje procesa. Prođite kroz provjere ispod redom. Zaustavite se na prvoj koja odgovara na pitanje, jer svaka sljedeća odgovara na nešto drugo.
Prva provjera: razdvojite zaključavanje od praznog ekrana i od sna
Zaključavanje mijenja kome je dopušteno koristiti sesiju; kompozitor nastavlja crtati, mrežni stog nastavlja raditi, a VPN klijent ništa ne primjećuje. Zamračivanje ekrana isključuje ploču nakon razdoblja mirovanja i ostavlja računalo potpuno budnim. Suspenzija zaustavlja procesore, što znači da se nijedan proces u korisničkom prostoru ne zakazuje, pa nikakvo održavanje veze ne može krenuti, koliko god interval bio kratak.
| 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 |
Ta tablica je razlog zašto „ekran se zamračio“ nije dijagnoza. Radna stanica podešena da se zamrači nakon pet minuta i da ode u san nakon trideset pokazat će taman ekran u šestoj minuti s potpuno zdravim tunelom. Kvar u tridesetoj minuti drugi je događaj s drugim rješenjem, a oba izgledaju isto s druge strane sobe.
Druga provjera: stavite događaje napajanja i mreže na jednu vremensku crtu
Čitajte dnevnik za ograničen vremenski prozor, a ne za cijelo podizanje, i uključite i upravitelja prijave i vlasnika veze:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list
Prva naredba pokazuje zahtjeve za san, buđenje i mrežne prijelaze koji su ih slijedili. Druga pokazuje što trenutačno drži inhibitornu bravu, što vam govori blokira li nešto san namjerno i koji je to program. Prilagodite nazive jedinica ako vlasnik vaše veze nije NetworkManager i zapamtite da čitanje jedinice drugog korisnika ili sistemskog dnevnika ovisi od lokalne politike.
Linija koja nedostaje nije negativan rezultat. Ako dnevnik odabrane jedinice nije vidljiv vašem računu, odsutnost zapisa o snu ništa ne dokazuje, a zaključak „nikad nije spavalo“ iz praznog filtra je put kojim ljudi provedu tjedan podešavajući održavanje veze.
Treća provjera: ako je otišlo u san, odlučite je li to bilo namjerno
Kad se prijelaz u san pojavi na vremenskoj crti, pitanje se mijenja od zašto se VPN slomio na je li računalo uopće trebalo spavati. Na prijenosniku je odgovor često da, a prekid tunela je očekivano ponašanje iz kojeg se klijent treba oporaviti pri buđenju. Na radnoj stanici koja treba ostati dostupna, politika sna je ono što treba mijenjati. Odluka na koje od ta dva računala gledate traži jedno pitanje, a to nije pitanje na koje dnevnik može odgovoriti umjesto vas.
Promijenite je kroz kontrole koje pripadaju prijavljenoj sesiji ili kroz mehanizam koji podržava administrator ako zahtjev vrijedi za cijelo računalo. Uređivanje postavke upravitelja ekrana dok ste prijavljeni na drugi račun nije ista radnja i izgledat će kao da je uspjelo do početka sljedeće sesije. Potpuno isključivanje upravljanja napajanjem široka je prva reakcija koja košta trajanja baterije i skriva stvarno pitanje politike.
Četvrta provjera: ako je ostalo budno, pogledajte mrežu i klijenta
Budno računalo koje je izgubilo tunel ima jednu od tri priče: pristupna mreža je pala, VPN klijent se zaustavio ili ponovno pokrenuo, ili je strana poslužitelja istekla asocijaciju dok je klijent dalje vjerovao da je povezan. Usporedite vremenske oznake temeljnog događaja veze s događajem tunela i budite precizni koji je došao prvi.
Zatim testirajte put oporavka odvojeno od izvorne sesije. Novi zahtjev kroz oporavljeni tunel može uspjeti dok dugotrajna sesija aplikacije otvorena prije prekida ostaje slomljena, jer aplikacija drži zastarjeli socket ili keširanu adresu. To je problem aplikacije, a ne dokaz da se tunel nije vratio.
Što sadrži koristan izvještaj
Zapišite slijed s vremenskim oznakama i vlasnicima: kada se sesija zaključala, kada se ekran zamračio, je li zabilježen zahtjev za san, kada je veza pala i vratila se, kada je tunel promijenio stanje i što je aplikacija zapravo učinila. Svaka stavka ima vlasnika, pa se svaka stavka može predati pravoj osobi umjesto da postane opća pritužba na Linux.
Ako bilo koji od tih redaka nedostaje, to je sljedeće što treba izmjeriti, a ne sljedeće što treba promijeniti. Vremenska crta s prazninom informativnija je od promjene postavki donesene na osnovu pretpostavke.