VPN pade, ko zaslon potemni: zaklep, ugasnjen zaslon ali spanje?
Zaklenjena seja, potemnel zaslon in uspana naprava so trije različni dogodki. Povežite jih z journalctl, preden okrivite mehanizem za ohranjanje povezave VPN.
Ko nekdo reče, da je VPN umrl, ko je zaslon potemnel, je prvo koristno vprašanje, kateri od treh dogodkov se je dejansko zgodil: seja se je zaklenila, plošča se je izklopila ali je cela naprava odšla v spanje. To so ločeni mehanizmi na ločenih časovnikih in le eden od njih lahko povsem prepreči razvrščanje procesa. Pojdite skozi spodnja preverjanja po vrsti. Ustavite se pri prvem, ki odgovori na vprašanje, ker vsako naslednje odgovarja na nekaj drugega.
Prvo preverjanje: ločite zaklep od potemnitve in od spanja
Zaklep spremeni, kdo sme uporabljati sejo; sestavljalnik še naprej riše, omrežni sklad še naprej deluje, odjemalec VPN pa ničesar ne opazi. Potemnitev zaslona izklopi ploščo po obdobju nedejavnosti in napravo pusti popolnoma budno. Spanje ustavi procesorje, kar pomeni, da se noben proces v uporabniškem prostoru ne razvrsti, zato se noben signal za ohranjanje povezave ne more sprožiti, ne glede na to, kako kratek interval nastavite.
| 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 |
Prav ta tabela je razlog, da „zaslon je potemnel“ ni diagnoza. Namizni računalnik, nastavljen na potemnitev po petih minutah in spanje po tridesetih, bo v šesti minuti pokazal temen zaslon s popolnoma zdravim tunelom. Okvara v trideseti minuti je drug dogodek z drugo rešitvijo, in oba sta z drugega konca sobe videti enako.
Drugo preverjanje: postavite dogodke napajanja in omrežja na eno časovnico
Berite dnevnik za omejeno okno, ne za ves zagon, in vključite tako upravitelja prijave kot lastnika povezave:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list
Prvi ukaz prikaže zahteve za spanje, prebujanje in omrežne prehode, ki so jim sledili. Drugi prikaže, kaj trenutno drži inhibitorno ključavnico, kar vam pove, ali kaj namerno blokira spanje in kateri program je to. Prilagodite imena enot, če lastnik vaše povezave ni NetworkManager, in ne pozabite, da je branje enote drugega uporabnika ali sistemskega dnevnika odvisno od lokalne politike.
Manjkajoča vrstica ni negativen rezultat. Če dnevnik izbrane enote ni viden vašemu računu, odsotnost zapisa o spanju ničesar ne dokazuje, in sklep „nikoli ni spal“ iz praznega filtra je pot, po kateri ljudje preživijo teden dni z nastavljanjem ohranjanja povezave.
Tretje preverjanje: če je odšla v spanje, odločite, ali je bilo to namerno
Ko se prehod v spanje pojavi na časovnici, se vprašanje spremeni iz zakaj se je VPN zlomil v ali bi naprava sploh morala spati. Na prenosniku je odgovor pogosto da, in prekinitev tunela je pričakovano vedenje, od katerega si mora odjemalec opomoči ob prebujanju. Na delovni postaji, ki mora ostati dosegljiva, je treba spremeniti politiko spanja. Da bi ugotovili, na katero od teh dveh naprav gledate, potrebujete eno vprašanje, in to ni vprašanje, na katero bi dnevnik lahko odgovoril namesto vas.
Spremenite jo prek kontrolnikov, ki pripadajo prijavljeni seji, ali prek mehanizma, ki ga podpira skrbnik, če se zahteva nanaša na celo napravo. Urejanje nastavitve upravitelja zaslona, medtem ko ste prijavljeni z drugim računom, ni isto dejanje in bo videti, kot da deluje, dokler se ne začne naslednja seja. Popolna izključitev upravljanja porabe energije je širok prvi odziv, ki stane življenjsko dobo baterije in skrije pravo politično vprašanje.
Četrto preverjanje: če je ostala budna, poglejte omrežje in odjemalca
Budna naprava, ki je izgubila tunel, ima eno od treh zgodb: dostopno omrežje je padlo, odjemalec VPN se je ustavil ali znova zagnal, ali pa je strežniška stran pustila povezavo, da poteče, medtem ko je odjemalec še naprej verjel, da je povezan. Primerjajte časovne žige dogodka povezave z dogodkom tunela in bodite natančni, kateri je bil prvi.
Nato preizkusite pot obnovitve ločeno od prvotne seje. Nova zahteva skozi obnovljeni tunel lahko uspe, medtem ko dolgotrajna seja aplikacije, odprta pred prekinitvijo, ostane pokvarjena, ker aplikacija drži zastarel vtič ali predpomnjen naslov. To je težava aplikacije, ne dokaz, da se tunel ni vrnil.
Kaj vsebuje koristno poročilo
Zapišite zaporedje s časovnimi žigi in lastniki: kdaj se je seja zaklenila, kdaj je zaslon potemnel, ali je bila zabeležena zahteva za spanje, kdaj je povezava padla in se vrnila, kdaj je tunel spremenil stanje in kaj je aplikacija dejansko storila. Vsaka postavka ima lastnika, zato lahko vsako postavko predate pravi osebi, namesto da postane splošna pritožba čez Linux.
Če katera od teh vrstic manjka, je to naslednja stvar, ki jo je treba izmeriti, in ne naslednja stvar, ki jo je treba spremeniti. Časovnica z vrzeljo je bolj poučna kot sprememba nastavitev, narejena po občutku.