Czy kill switch blokuje ruch, zanim uruchomi się aplikacja VPN?

Kill switch może obejmować albo nie obejmować okna przed uruchomieniem jego aplikacji, a różnicę rozstrzyga polityka systemu operacyjnego, a nie strona marketingowa klienta. Pole wyboru automatycznego uruchamiania dowodzi, że coś jest zaplanowane do startu. Nie dowodzi, że reguły blokowania istnieją w momencie, gdy sieć się podnosi. To dwa zdarzenia i tylko jedno z nich chroni ruch.

Przejdź listę kontrolną po kolei, bo każdy krok zawęża to, co naprawdę testujesz.

Skąd blokada faktycznie pochodzi

Istnieją dwie rodziny implementacji. Albo platforma instaluje blokadę, bo zna tunel, zanim uruchomi się jakakolwiek aplikacja, albo klient sam instaluje blokadę po uruchomieniu. Pierwsza może istnieć przed zalogowaniem. Druga nie może istnieć przed swoim procesem, niezależnie od tego, jak wcześnie ten proces jest zaplanowany. Ustal, na której rodzinie się opierasz, zanim czegokolwiek przetestujesz.

W Androidzie stale włączony VPN w połączeniu z ustawieniem blokowania połączeń bez VPN to polityka platformy, konfigurowana w ustawieniach systemowych, a nie tylko wewnątrz klienta. Na urządzeniach zarządzanych może być ustawiona za ciebie. Klient, który po prostu startuje przy rozruchu, to nie ten sam mechanizm.

Oddziel okno od usługi

Zamknięte okno nie jest dowodem, że egzekwowanie ustało, a otwarte okno nie jest dowodem, że tunel jest gotowy. Wiele klientów rozdziela interfejs, demona i aplikację w zasobniku. Zasobnik to to, co widzisz; demon to to, co trzyma reguły.

Testuj komponent, a nie ikonę.

Testuj bezpiecznie interwał startowy

Testowany interwał zaczyna się przy ponownym uruchomieniu lub zalogowaniu i kończy, gdy tunel się uwierzytelni. Aplikacje w tle łączą się w tym okresie, a sprawdzanie aktualizacji to zwykli winowajcy. Użyj nieszkodliwej aktywności i udokumentowanej procedury dostawcy zamiast blokować własny dostęp. Potem powtórz po normalnym ponownym połączeniu, bo ścieżka ponownego połączenia i ścieżka zimnego startu wykonują inny kod.

Test wykonany po tym, jak tunel już stoi, nie dowodzi niczego o starcie.

Przeczytaj zachowanie przy ponownym uruchomieniu, jeśli trwałość jest wymaganiem. Ustawienie może przetrwać w konfiguracji, podczas gdy jego egzekwowanie zaczyna się później, i oba fakty się liczą: zapisana polityka i moment, w którym staje się aktywna.

Czytaj politykę dla każdej platformy

Android udostępnia stale włączony i blokowanie jako osobne przełączniki i oba muszą być włączone, aby chronić przed startem. Windows ma koncepcję stale włączonego tunelu urządzenia konfigurowanego przez politykę, co nie jest tym samym co wcześnie startujący klient w trybie użytkownika. OpenVPN Connect dokumentuje własne zachowanie kill switcha dla każdej platformy i to udokumentowany zakres jest tym, co testujesz. Nie przenoś nazwy ustawienia z jednego systemu do drugiego i nie zakładaj, że znaczenie podróżowało razem z nią.

Profil wymagający interaktywnego hasła ma inne zależności startowe niż tunel maszyny.

Co zapisać

Zapisz, który mechanizm obowiązuje, na jakim etapie staje się aktywny i jaki ruch był próbowany przed tym etapem. Zapisz wersję platformy, bo to zachowanie zmienia się między wydaniami oraz między konfiguracjami zarządzanymi i osobistymi. Zanotuj, czy politykę posiada klient, czy system, ponieważ to decyduje, kto może naprawić lukę. Potem przetestuj ponownie po każdej aktualizacji klienta lub systemu.

Jeśli luka ma znaczenie, trwałym rozwiązaniem jest polityka platformy, a nie krótsze opóźnienie startu.

To jest odpowiedź na pierwotne pytanie, wyrażona jako warunek: kill switch chroni ruch przed startem aplikacji tylko wtedy, gdy blokadę instaluje coś, co istnieje przed aplikacją.