VPN pada, gdy ekran gaśnie: blokada, wygaszenie czy uśpienie?

Gdy ktoś mówi, że VPN padł, gdy ekran pociemniał, pierwsze użyteczne pytanie brzmi, które z trzech zdarzeń faktycznie nastąpiło: sesja została zablokowana, panel został wyłączony, czy cała maszyna przeszła w stan uśpienia. To odrębne mechanizmy na odrębnych licznikach czasu, i tylko jeden z nich może całkowicie uniemożliwić zaplanowanie procesu. Przejdź poniższe kontrole po kolei. Zatrzymaj się na pierwszej, która odpowiada na pytanie, bo każda następna odpowiada na coś innego.

Kontrola pierwsza: oddziel blokadę od wygaszenia i od uśpienia

Blokada zmienia, kto może korzystać z sesji; kompozytor nadal rysuje, stos sieciowy nadal działa, a klient VPN niczego nie zauważa. Wygaszenie ekranu wyłącza panel po okresie bezczynności i pozostawia maszynę całkowicie obudzoną. Uśpienie zatrzymuje procesory, co oznacza, że żaden proces w przestrzeni użytkownika nie jest planowany, więc żaden sygnał podtrzymania nie może zadziałać, niezależnie od tego, jak krótki ustawisz interwał.

To właśnie ta tabela jest powodem, dla którego „ekran pociemniał“ nie jest diagnozą. Komputer stacjonarny ustawiony na wygaszenie po pięciu minutach i uśpienie po trzydziestu pokaże ciemny ekran w szóstej minucie przy całkowicie zdrowym tunelu. Awaria w trzydziestej minucie to inne zdarzenie z innym rozwiązaniem, a oba wyglądają tak samo z drugiego końca pokoju.

Kontrola druga: umieść zdarzenia zasilania i sieci na jednej osi czasu

Czytaj dziennik dla ograniczonego okna, a nie dla całego rozruchu, i uwzględnij zarówno menedżera logowania, jak i właściciela połączenia:

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

Pierwsze polecenie pokazuje żądania uśpienia, wybudzenie i przejścia sieciowe, które po nich nastąpiły. Drugie pokazuje, co obecnie trzyma blokadę inhibitora, co mówi ci, czy coś celowo blokuje uśpienie i który to program. Dostosuj nazwy jednostek, jeśli właścicielem twojego połączenia nie jest NetworkManager, i pamiętaj, że czytanie jednostki innego użytkownika lub dziennika systemowego zależy od lokalnej polityki.

Brakująca linia nie jest wynikiem negatywnym. Jeśli dziennik wybranej jednostki nie jest widoczny dla twojego konta, brak wpisu o uśpieniu niczego nie dowodzi, a wniosek „nigdy nie spał“ z pustego filtra to droga, na której ludzie spędzają tydzień, dostrajając podtrzymywanie połączenia.

Kontrola trzecia: jeśli maszyna usnęła, zdecyduj, czy tak miało być

Gdy tylko przejście w uśpienie pojawi się na osi czasu, pytanie zmienia się z „dlaczego VPN się zepsuł“ na „czy maszyna w ogóle powinna spać“. Na laptopie odpowiedź często brzmi tak, a przerwa w tunelu jest oczekiwanym zachowaniem, z którego klient powinien się podnieść po wybudzeniu. Na stacji roboczej, która ma pozostać dostępna, zmienić trzeba politykę uśpienia. Rozstrzygnięcie, na którą z tych dwóch maszyn patrzysz, wymaga jednego pytania, i nie jest to pytanie, na które dziennik może odpowiedzieć za ciebie.

Zmień ją przez kontrolki należące do zalogowanej sesji albo przez mechanizm obsługiwany przez administratora, jeśli wymóg dotyczy całej maszyny. Edytowanie ustawienia menedżera wyświetlania, gdy jesteś zalogowany na innym koncie, nie jest tą samą czynnością i będzie wyglądać, jakby działało, dopóki nie zacznie się następna sesja. Całkowite wyłączenie zarządzania energią to szeroka pierwsza reakcja, która kosztuje żywotność baterii i ukrywa właściwe pytanie o politykę.

Kontrola czwarta: jeśli maszyna została obudzona, spójrz na sieć i klienta

Obudzona maszyna, która straciła tunel, ma jedną z trzech historii: sieć dostępowa padła, klient VPN zatrzymał się lub uruchomił ponownie, albo strona serwera pozwoliła wygasnąć asocjacji, podczas gdy klient nadal wierzył, że jest połączony. Porównaj znaczniki czasu zdarzenia łącza z zdarzeniem tunelu i bądź precyzyjny co do tego, które nastąpiło pierwsze.

Następnie przetestuj ścieżkę odzyskiwania oddzielnie od pierwotnej sesji. Nowe żądanie przez odzyskany tunel może się udać, podczas gdy długotrwała sesja aplikacji otwarta przed przerwą pozostaje zepsuta, ponieważ aplikacja trzyma nieaktualne gniazdo lub adres z pamięci podręcznej. To problem aplikacji, a nie dowód, że tunel nie wrócił.

Co zawiera przydatny raport

Zapisz sekwencję ze znacznikami czasu i właścicielami: kiedy sesja została zablokowana, kiedy ekran pociemniał, czy zarejestrowano żądanie uśpienia, kiedy łącze padło i wróciło, kiedy tunel zmienił stan i co aplikacja faktycznie zrobiła. Każdy element ma właściciela, więc każdy element można przekazać właściwej osobie zamiast zamieniać go w ogólną skargę na Linuksa.

Jeśli brakuje któregoś z tych wierszy, to jest następna rzecz do zmierzenia, a nie następna rzecz do zmiany. Oś czasu z luką jest bardziej pouczająca niż zmiana ustawień dokonana na wyczucie.