VPN pada po wyłączeniu ekranu: który cykl życia?

Transfer zatrzymuje się w chwili, gdy ekran gaśnie, a odznaka pojawia się kilka sekund później. Trzy różne rzeczy tworzą ten obraz: proces klienta zostaje ograniczony, ścieżka przechodzi w bezczynność i traci swoje mapowanie, albo aplikacja traci sesję, której tunel nigdy nie zauważył. Każda ma własne dowody, a każde rozwiązanie należy do innej warstwy. Kolejność poniżej rozdziela je jednym kontrolowanym testem zamiast przeglądu wszystkich ustawień.

Trzy awarie, które wyglądają identycznie

Ograniczony proces w tle przestaje wysyłać keepalive, a druga strona w końcu ogłasza tunel martwym. Bezczynne mapowanie na ścieżce może wygasnąć, gdy urządzenie śpi, więc ruch powrotny nigdy nie dociera do klienta, który wciąż jest całkowicie żywy. Aplikacja może utracić własne połączenie, gdy tunel stoi, co daje okno błędu ze zdrową odznaką VPN w tle. Z punktu widzenia użytkownika wszystkie trzy czytają się jak VPN, który padł przy wyłączaniu ekranu.

Rozróżnienie ma znaczenie, bo środki zaradcze w praktyce sobie przeczą. Wyłączenie klienta z ograniczeń energetycznych naprawia pierwszy przypadek i nic nie robi dla wygasłego mapowania. Wydłużenie keepalive naprawia drugi i marnuje baterię w trzecim, gdzie od początku nic sieciowego nie było źle.

Porównaj stan aktywny i bezczynny w kontrolowanych warunkach

Utrzymuj wszystko bez zmian: to samo urządzenie, ta sama sieć, ten sam punkt końcowy, ta sama aplikacja. Zablokuj ekran na krótki stały interwał i zapisz trzy obserwacje: czy klient zgłasza rozłączenie, czy nowe żądanie działa po odblokowaniu i czy istniejący transfer został wznowiony. Następnie powtórz z działającym keepalive lub żądaniem okresowym i porównaj oba przebiegi. Jedna zmieniona zmienna między dwoma przebiegami jest warta więcej niż tydzień anegdotycznych raportów.

Czas należy do zapisu. Spadek po dziewięćdziesięciu sekundach pachnie mapowaniem lub interwałem keepalive, natomiast spadek w chwili blokady wskazuje na wstrzymanie procesu. Zapisz zarówno wyzwalacz, jak i interwał, bo następna próba potrzebuje czegoś do porównania.

Przeczytaj politykę tła platformy

W Androidzie cykl życia usługi VPN jest częścią platformy, a always-on i block-without-VPN to osobne przełączniki o osobnych skutkach. Klient, który nie jest always-on, może zostać zatrzymany, gdy system odbiera zasoby, i żadne ustawienie w aplikacji tego nie zmienia. iOS stosuje własne limity tła do dostawcy tunelu, a udokumentowane zachowanie różni się od demona pulpitu, który po prostu działa dalej. Czytaj dokumentację platformy dla danego komponentu, a nie ogólny poradnik optymalizacji baterii.

Zarządzane urządzenia dodają kolejną warstwę. Zasada może nadpisać ustawienie osobiste, więc zmiana, która wygląda na działającą, cofa się przy następnym odświeżeniu zasad. Użyj wspieranego przez organizację procesu wyjątku, jeśli wymóg jest rzeczywisty, i zapisz, dlaczego wyjątek istnieje.

Co urządzenie robi po wybudzeniu

Automatyczne ponowne połączenie to nie to samo co blokowanie ruchu w czasie luki. Sprawdź jedno i drugie: czy tunel wraca i czy aplikacja, która próbowała wysłać w czasie luki, wyszła bez ochrony. Klient, który łączy się ponownie w dwie sekundy, ale w pierwszej przecieka zapytanie DNS, ma złą politykę awaryjną dla urządzenia służbowego. Testuj nieszkodliwymi żądaniami i celem, który kontrolujesz.

Odtworzenie aplikacji to trzecie pytanie. Tunel, który wraca, nie naprawia sesji SSH, której upłynął czas, a użytkownicy często zgłaszają tę utratę sesji jako awarię VPN. Trzymaj razem w raporcie wyzwalacz, kompilację klienta i dokładny czas, bo ta kombinacja oddziela przewidywalny cykl wyłączania ekranu od serwera, który zawodzi niezależnie od urządzenia.