VPN padá, když se obrazovka vypne: zámek, ztmavení, nebo spánek?

Když někdo řekne, že VPN zemřela, když se obrazovka ztmavila, první užitečná otázka je, která ze tří událostí se vlastně stala: relace se uzamkla, panel se vypnul, nebo celý stroj usnul. To jsou oddělené mechanismy na oddělených časovačích a jen jeden z nich může úplně zastavit plánování procesu. Projděte kontroly níže popořadě. Zastavte se u první, která na otázku odpoví, protože každá další odpovídá na něco jiného.

První kontrola: oddělte zámek od ztmavení a od spánku

Zámek mění, kdo smí relaci používat; kompozitor dál kreslí, síťový zásobník dál běží a klient VPN si ničeho nevšimne. Ztmavení displeje vypne panel po době nečinnosti a nechá stroj zcela bdělý. Spánek zastaví procesory, což znamená, že se nenaplánuje žádný proces v uživatelském prostoru, takže žádné udržování spojení nemůže vystřelit, ať nastavíte interval jakkoli krátký.

Právě proto „obrazovka ztmavla“ není diagnóza. Stolní počítač nastavený na ztmavení po pěti minutách a spánek po třiceti ukáže tmavou obrazovku v šesté minutě s naprosto zdravým tunelem. Selhání ve třicáté minutě je jiná událost s jiným řešením a obojí vypadá z druhého konce místnosti stejně.

Druhá kontrola: dejte události napájení a sítě na jednu časovou osu

Čtěte protokol pro omezené okno, ne pro celé spuštění, a zahrňte správce přihlášení i vlastníka připojení:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

První příkaz ukazuje žádosti o spánek, probuzení a síťové přechody, které po nich následovaly. Druhý ukazuje, co právě drží inhiberační zámek, což vám řekne, zda něco spánek záměrně blokuje a který program to je. Upravte názvy jednotek, pokud vlastníkem připojení není NetworkManager, a pamatujte, že čtení jednotky jiného uživatele nebo systémového protokolu závisí na místní politice.

Chybějící řádek není negativní výsledek. Pokud protokol vybrané jednotky není pro váš účet viditelný, nepřítomnost záznamu o spánku nic nedokazuje, a závěr „nikdy nespal“ z prázdného filtru je způsob, jakým lidé stráví týden laděním udržování spojení.

Třetí kontrola: pokud usnul, rozhodněte, zda to bylo zamýšlené

Jakmile je přechod do spánku na časové ose, otázka se mění z toho, proč se VPN rozbila, na to, zda měl stroj vůbec spát. Na notebooku je odpověď často ano a výpadek tunelu je očekávané chování, ze kterého se má klient při probuzení vzpamatovat. Na pracovní stanici, která má zůstat dostupná, je věc ke změně politika spánku. Rozhodnout, na který z těch dvou strojů se díváte, vyžaduje jednu otázku, a to není otázka, kterou za vás protokol může zodpovědět.

Změňte ji ovládacími prvky, které patří přihlášené relaci, nebo mechanismem podporovaným správcem, pokud je požadavek pro celý stroj. Úprava nastavení správce displeje, když jste přihlášeni pod jiným účtem, není stejná akce a bude vypadat, že fungovala, dokud nezačne další relace. Úplné vypnutí správy napájení je široká první reakce, která stojí výdrž baterie a skrývá skutečnou otázku politiky.

Čtvrtá kontrola: pokud zůstal bdělý, podívejte se na síť a klienta

Bdělý stroj, který ztratil tunel, má jeden ze tří příběhů: přístupová síť spadla, klient VPN se zastavil nebo restartoval, nebo strana serveru ukončila asociaci, zatímco klient dál věřil, že je připojený. Porovnejte časové značky události základního spoje s událostí tunelu a buďte přesní v tom, která přišla první.

Pak otestujte cestu obnovy odděleně od původní relace. Nový požadavek přes obnovený tunel může uspět, zatímco dlouhodobá relace aplikace otevřená před výpadkem zůstává rozbitá, protože aplikace drží zastaralý socket nebo kešovanou adresu. To je problém aplikace, ne důkaz, že se tunel nevrátil.

Co obsahuje užitečná zpráva

Zapište posloupnost s časovými značkami a vlastníky: kdy se relace uzamkla, kdy obrazovka ztmavla, zda byla zaznamenána žádost o spánek, kdy spoj spadl a vrátil se, kdy tunel změnil stav a co aplikace skutečně udělala. Každá položka má vlastníka, takže každou položku lze předat správnému člověku, místo aby se z ní stala obecná stížnost na Linux.

Pokud některý z těchto řádků chybí, je to další věc k měření, ne další věc ke změně. Časová osa s mezerou je informativnější než změna nastavení provedená na základě dojmu.