Aplikacja VPN się wysypała: czy wyłącznik bezpieczeństwa nadal działa?

Zacznij tam, gdzie zaczyna użytkownik: okno klienta zniknęło, ikona w zasobniku przepadła, a przeglądarka albo ładuje, albo nie. Sama ta obserwacja nie powie ci, czy blokada przetrwała. Odpowiedź zależy od tego, który komponent trzyma reguły, czy ten komponent zginął razem z oknem i czy platforma trzyma egzekwowanie poza aplikacją. Przejdź od okna do procesu, potem do zapory, potem do rzeczywistej ścieżki.

Nie restartuj najpierw; restart zwykle niszczy dowody.

Zacznij od tego, co jeszcze działa

Otwórz listę procesów, zanim czegokolwiek dotkniesz. Klient desktopowy zwykle dzieli się na proces interfejsu użytkownika oraz usługę lub demona, a awaria pierwszego nie musi zatrzymywać drugiego. W Windows usługa może wciąż być na liście, w Linuksie jednostka może wciąż być aktywna, a w Androidzie tunel należy do systemu po wyrażeniu zgody. Przeczytaj te trzy fakty w tej kolejności.

Jeśli demon żyje, tunel prawdopodobnie też żyje, a brakujące okno jest tylko kosmetyką.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Czytaj blokadę u egzekwującego, nie w aplikacji

Jeśli klient realizuje swój wyłącznik bezpieczeństwa przez wstawianie reguł zapory, te reguły należą do systemu operacyjnego i przeżywają proces, który je utworzył. Awaria zostawia cię wtedy zablokowanym bez żadnego interfejsu do wyłączenia, co wygląda jak zepsuta sieć, a nie jak ochrona. Jeśli natomiast blokada żyje w obrębie własnej ścieżki pakietów klienta, zabicie procesu usuwa blokadę w tej samej chwili.

Android radzi sobie z tym jeszcze inaczej: always-on VPN z lockdownem to ustawienie platformy, więc blokada trwa niezależnie od procesu aplikacji, a system może zrestartować usługę. Sprawdź dokładne zachowanie w dokumentacji platformy, zamiast zakładać, że odpowiada ono klientowi desktopowemu.

Odróżnij czyste wyjście od awarii

Zwykłe Quit zwykle uruchamia ścieżkę zamykania klienta, która celowo usuwa reguły i zamyka tunel. Awaria pomija tę ścieżkę i zostawia to, co egzekwujący już zainstalował. Różnicę widać w znacznikach czasu reguł względem wyjścia procesu oraz w tym, czy istnieje jeszcze stary interfejs tunelu bez właściciela.

Ta różnica decyduje o odzyskaniu: czyste wyjście może wymagać nowego połączenia, a awaria może wymagać usunięcia pozostałych reguł przez obsługiwaną akcję naprawczą klienta.

Odzyskaj bez psucia innych kontroli

Zrestartuj klienta zgodnie z jego udokumentowanym przepływem pracy, a potem sprawdź obie połowy wymagania: tunel przenosi ruch, a blokada nadal obowiązuje, kiedy powinna. Przepłukanie całej zapory, aby odzyskać łączność, usuwa też niepowiązane kontrole, a ten układ rzadko się opłaca.

Przy powtarzającej się awarii zbierz wersję klienta, kompilację platformy i ograniczone logi, o które prosi dostawca. Profil klienta, klucz prywatny lub pełny log połączenia innego konta nie są potrzebne do zgłoszenia awarii, a ich dołączenie zmienia sprawę wsparcia w problem z przetwarzaniem danych.

Jedna awaria nie jest dowodem wycieku. Dowodem jest zaobserwowany pakiet wychodzący ścieżką, której polityka miała zapobiec, uchwycony w chwili, gdy klient był wyłączony. Przetestuj to celowo, z nieszkodliwym celem, i zapisz, która warstwa egzekwowania się utrzymała.