Kill switch aplikacji a kill switch zapory: co blokuje każdy z nich

Kill switch na liście funkcji nie mówi prawie nic o tym, co się dzieje, gdy tunel padnie. Jedna implementacja zamyka wybrane procesy, inna instaluje filtry pakietów na granicy systemu operacyjnego, a trzecia po prostu próbuje połączyć się ponownie. Różnica ujawnia się w sekundach po awarii, a nie na ekranie ustawień. Przejdź te kontrole po kolei i zatrzymaj się na pierwszej, na którą nie potrafisz odpowiedzieć uczciwie, bo tam kończy się twoje rzeczywiste pokrycie.

Najpierw nazwij mechanizm egzekwowania

Kończenie procesów to funkcja cyklu życia aplikacji. Znajduje wybrane programy po wykrytej awarii tunelu i zamyka je. Wszystko, co nie jest procesem głównym, przeżywa: usługi pomocnicze, synchronizacja w tle i każda aplikacja uruchomiona sekundę później mają własny cykl życia i własne wyczucie czasu.

Filtrowanie pakietów to funkcja systemu operacyjnego. Odrzuca ruch, który nie idzie dozwoloną ścieżką, co jest mocniejszą obietnicą, ale tylko w zakresie, w jakim reguła faktycznie pasuje. Rodzina adresów, interfejs, wykluczone aplikacje i wyjątki decydują o tym, a nie etykieta w kliencie.

Czy blokada przeżyje klienta?

Zadaj cztery pytania w tej kolejności: co się dzieje przy awarii, przy ręcznym zamknięciu, przy wylogowaniu i przy ponownym uruchomieniu. Reguła utrzymywana przez samego klienta jest zwykle usuwana podczas schludnego zamykania i często zostaje po awarii. Reguła zainstalowana w magazynie platformy może zachowywać się odwrotnie: przeżyć zarówno klienta, jak i czasem dezinstalację.

Zamknij klienta w środku długiego pobierania i zobacz, czy transfer się zatrzyma, czy będzie trwał.

Szukaj standardowych dziur

IPv6 jest pierwsza. Reguła napisana dla adresów IPv4 pozostawia ruch IPv6 nietknięty, a wiele klientów zapisuje tylko połowę v4. Druga to interfejs: tethering USB, drugi adapter Wi-Fi i modem komórkowy mogą nie być objęte regułą ograniczoną do połączenia podstawowego. Wykluczone aplikacje i wyjątki sieci lokalnej to trzecia.

W systemie Windows możesz przeczytać zainstalowane reguły zamiast ufać przełącznikowi: Get-NetFirewallRule -DisplayName '*VPN*' i netsh wfp show filters oba pokazują, co istnieje. W systemie Linux iptables -S, ip6tables -S i nft list ruleset obejmują typowe przypadki, a porównanie wszystkich trzech jest sednem.

DNS to zwykły wyciek

Blokowanie TCP przy otwartym UDP 53 daje bardzo przekonujący kill switch, który nadal odpowiada na każde zapytanie o nazwę hosta. To samo dotyczy sytuacji, gdy DNS jest przekazywany resolverowi na innym interfejsie albo gdy klient blokuje tylko v4, a resolver jest osiągalny przez v6.

Przy opuszczonym tunelu rozwiąż jedną znaną nazwę i sprawdź, czy odpowiedź wraca. Jeśli wraca, ruch nie jest całkowicie zablokowany, cokolwiek mówi ikona stanu.

Testuj przejście, nie przełącznik

Wyłączenie VPN z jego własnego menu to schludne zamknięcie, a przypadek schludny każda implementacja obsługuje dobrze. Przejście, które ma znaczenie, jest brutalne: zabij proces tunelu, wyciągnij sieć, pozwól serwerowi przestać odpowiadać. Potem rozpocznij żądanie i obserwuj, czy zawiedzie, czy po cichu użyje łącza fizycznego.

Wynik z jednego laptopa nie przenosi się na telefon ani router. Inne API platformy, inne wartości domyślne, a w Androidzie różnica jest jaskrawa: tryb always-on z blokowaniem wymusza system, a nie klient, więc działa dalej, gdy klient nie działa. Przewodnik po VPN w Androidzie opisuje ten podział.

Zachowaj drogę powrotną

Blokowanie na poziomie systemu ma odwrotny tryb awarii. Filtry, które przeżyją klienta, mogą po dezinstalacji zostawić maszynę całkowicie bez sieci, co jest zgłoszeniem do pomocy technicznej bez oczywistej przyczyny. Przed włączeniem dowolnego kill switcha, który zapisuje reguły platformy, zanotuj, jak się go usuwa, i trzymaj ścieżkę naprawy od dostawcy tam, gdzie możesz ją znaleźć.

Jeśli nie potrafisz odpowiedzieć na kontrole awarii, IPv6, DNS i przejścia dla swojego klienta, traktuj go jako przełącznik na poziomie aplikacji ze znanymi dziurami i planuj odpowiednio.