Czy przełącznik awaryjny VPN przetrwa restart? Jak to sprawdzić

Restart to najczęstszy sposób, w jaki ludzie testują przełącznik awaryjny, i to test, który najczęściej kłamie. Pole wyboru w kliencie jest tylko preferencją; liczy się to, czy coś wymusza blokadę między momentem, w którym stos sieciowy się podnosi, a momentem, w którym tunel jest faktycznie ustanowiony. W Windows tym czymś jest zwykle filtr w Windows Filtering Platform, w Linuksie zestaw reguł ładowany przez jednostkę, w macOS kotwica pf, w Androidzie własne flagi systemu dla zawsze włączonego i blokady. Te rozwiązania zachowują się bardzo różnie podczas restartu, i tylko te na poziomie platformy są na miejscu, zanim ktokolwiek może się zalogować.

Restart stawia trzy osobne pytania

Podziel pytanie. Po pierwsze, czy polityka istnieje na dysku w formie, którą coś czyta przy starcie? Po drugie, czy ten czytnik działa, zanim jakikolwiek ruch może wyjść? Po trzecie, czy polityka obejmuje ruch, na którym ci zależy, czyli każdy proces, obie rodziny adresów i DNS. Tak na pierwsze i nie na drugie dają dokładnie tę usterkę, którą ludzie zgłaszają jako przełącznik awaryjny nieprzetrwający restartu: ruch wydostaje się na kilka sekund przy starcie, i nikt tego nie zauważa, dopóki ktoś nie pójdzie sprawdzić.

Trzymaj warstwy osobno. Zapisany zestaw reguł zapory, usługa, która startuje przy uruchomieniu, i preferencja klienta to trzy różne obiekty o trzech różnych czasach życia. Preferencja przetrwa restarty, bo jest wartością w pliku konfiguracji. Reguły są jedyną rzeczą, która blokuje pakiety, i znikają razem z jądrem, które je trzymało.

Znajdź obiekt, który przywraca blokadę

W Linuksie reguły netfilter żyją w jądrze. Nic ich nie zapisuje z powrotem przy starcie, chyba że to przygotowałeś: iptables-save plus netfilter-persistent, nftables.service ładuje /etc/nftables.conf, albo jednostka systemd, która uruchamia twój własny skrypt. Sprawdź, co jest włączone, a nie to, co pamiętasz, że skonfigurowałeś.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Pusty zestaw reguł kilka sekund po starcie jest odpowiedzią na pytanie z tytułu. W Windows zapytaj usługę klienta, jak się uruchamia, a następnie zrzuć stan filtra platformy, gdy tunel jest wyłączony.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Druga komenda zapisuje wfpstate.xml w bieżącym katalogu. Szukaj filtrów z akcją blokowania, które już istnieją, zanim klient się połączy. Base Filtering Engine startuje wcześnie przy uruchomieniu i przywraca filtry dodane z trwałą flagą, dlatego niektóre przełączniki awaryjne blokują ruch, zanim istnieje jakiekolwiek okno klienta, a inne nie. W macOS sudo pfctl -s info informuje, czy pf jest włączony, sudo pfctl -s rules pokazuje, co jest załadowane, a klienty VPN zwykle przypinają swoje reguły do kotwicy, a nie do głównego zestawu. Reguła, która nazywa utun3, może po następnym starcie wskazywać na inny interfejs, bo ten numer jest przydzielany w czasie działania.

Obserwuj lukę między podniesieniem sieci a podniesieniem tunelu

Niebezpieczny przedział to nie cały restart, to luka. Interfejs dostaje dzierżawę i trasę domyślną w jednym momencie, usługa VPN startuje w innym, a tunel uwierzytelnia się jeszcze później, czasem dopiero po zalogowaniu użytkownika i uruchomieniu agenta poświadczeń. Jeśli blokada jest stosowana na końcu, wszystko w luce wychodzi jawnie.

Na hostach systemd czytaj kolejność, zamiast jej zgadywać. Uruchom systemctl cat na jednostkach VPN i zapory i szukaj After= lub Before= wobec network-pre.target i network-online.target. Jednostka zapory uporządkowana po network-online.target przegrywa z interfejsem; ta wymagana przez i uporządkowana przed network-pre.target wygrywa. W Windows równoważnymi pytaniami są typ uruchomienia usługi i jej zależności, bo usługa ustawiona na Manual nie może zablokować procesu przy starcie. Jeśli twoje wymaganie obejmuje ruch przed logowaniem, spełnia je tylko rozwiązanie na poziomie urządzenia: tunel urządzenia Always On VPN uwierzytelnia się certyfikatem maszyny i łączy się, zanim użytkownik się zaloguje, a Microsoft dokumentuje konfigurację tunelu urządzenia osobno od tunelu użytkownika. Android idzie inną drogą, wymusza zawsze włączony VPN i blokuje połączenia bez niego z poziomu systemu, a nie procesu aplikacji.

Wykonaj test, a potem porównaj dwie osie czasu

Zrestartuj z celem, który nic nie kosztuje, jeśli wycieknie, i zarejestruj stan w trakcie luki, a nie po niej. Najczystszą metodą jest sonda startowa: jednostka oneshot albo zadanie harmonogramu, które startuje tak wcześnie, jak pozwala platforma, zapisuje trasę domyślną i stan zapory, próbuje jednego żądania z krótkim limitem i dopisuje wiersz do lokalnego pliku. Porównaj ten zapis z czasem startu usługi VPN z journalctl -b -u albo dziennika systemu.

Potem wykonaj zwykły test: tunel w górę, zerwij połączenie, obserwuj, czy ruch bezpośredni jest blokowany, przywróć. Zaliczenie drugiego i porażka w pierwszym to normalny wynik, i oznacza, że egzekwowanie jest po stronie klienta, stosowane przy połączeniu klienta, a nie przy starcie. Na ostatniej maszynie, którą audytowałem, blokada pochodziła ze skryptu dyspozytora NetworkManagera: obecna i poprawna i bezużyteczna dla sekund przed podniesieniem interfejsu. Zapisz oba wyniki, bo przetrwanie restartu znaczy coś dopiero wtedy, gdy powiesz, która warstwa przetrwała i od którego momentu.

Zamknij lukę bez odcinania drogi powrotu

Jeśli blokady brakuje przy starcie, przenieś egzekwowanie warstwę niżej, zamiast dodawać drugą regułę klienta. Zapisz zestaw reguł i ładuj go z jednostki uporządkowanej przed tym, jak sieć stanie się użyteczna, i upewnij się, że ta jednostka nie potrzebuje zapytania DNS ani montowania sieciowego, które ma chronić. Zakres jest tak samo ważny jak czas: reguły dopasowane do ID użytkownika albo cgroup zostawiają każdy demon systemowy poza blokadą, a zestaw reguł obsługujący tylko IPv4 zostawia IPv6 i DNS osiągalne.

Zostaw sobie drogę powrotu. Maszyna, która przy starcie blokuje wszystko i potem nie może się uwierzytelnić, nie ma sieci w ogóle, a poprawką nie jest usunięcie blokady, lecz naprawa poświadczeń albo kolejności. Utrzymuj udokumentowaną procedurę konsoli lokalnej i wąski, świadomy wyjątek na to, czego tunel naprawdę potrzebuje, jak adres serwera i resolver używany, zanim tunel istnieje.

Zanim zaufasz temu układowi, potwierdź cztery rzeczy po kolei. Polityka jest zapisana tam, gdzie czyta ją start. Ten czytnik działa, zanim interfejs jest użyteczny. Blokada obejmuje obie rodziny adresów i DNS. VPN nadal może się uwierzytelnić, gdy blokada jest aktywna. Kiedy wszystkie cztery zachodzą, restart niczego nie zmienia.