Kill switch dla poszczególnych aplikacji a blokada całego urządzenia: co się zmienia
Decyduj według chronionego zbioru, nie etykiety: co zatrzymuje się dla wykluczonych aplikacji, pomocników działających w tle i nowych połączeń, i jak przetestować każdy przypadek.
Kill switch dla poszczególnych aplikacji brzmi jak ostrożny wybór: gdy tunel pada, sieć traci tylko klient pracy, a wszystko inne działa dalej. Potem ktoś zauważa, że osobista przeglądarka mimo to wczytała stronę, pomocnik synchronizacji z tego samego pakietu wciąż ponawiał próby, a nazwa z pamięci podręcznej nadal rozwiązywała się na adres, który nigdy nie dotknął tunelu. Etykieta funkcji i zbiór połączeń, które naprawdę chroni, to dwie różne rzeczy. Najpierw ustal chroniony zbiór, bo to on decyduje, czy uczciwym opisem jest egzekwowanie dla poszczególnych aplikacji, czy blokada całego urządzenia.
Zacznij od zbioru, nie od etykiety
Polityka dla poszczególnych aplikacji chroni wybrane aplikacje. Blokada urządzenia celuje w szerszą granicę sieci, zwykle z udokumentowanymi wyjątkami dla drukowania lokalnego, ruchu zarządzającego lub portali captive. Żadna z etykiet nie jest pełna, dopóki nie odpowiesz na trzy pytania: co dzieje się z wykluczonymi aplikacjami, co dzieje się z pomocnikami, które te aplikacje uruchamiają, i co dzieje się z połączeniami otwieranymi, gdy ochrona jest niedostępna.
Zapisz te odpowiedzi, zanim dotkniesz jakiegokolwiek ustawienia klienta. Jeśli wymaganie brzmi "ten klient płacowy nigdy nie może rozmawiać z internetem poza tunelem, a moja przeglądarka może", zbiór jest mały i egzekwowanie dla poszczególnych aplikacji pasuje. Jeśli wymaganie brzmi "nic na tym urządzeniu nie dociera do internetu bez ochrony, poza usługą aktualizacji", żadna polityka dla poszczególnych aplikacji tego nie da, bo problemem są aplikacje, których nie wymieniłeś.
Egzekwowanie dla poszczególnych aplikacji dopasowuje identyfikatory, nie nazwy programów
Android udostępnia VPN dla poszczególnych aplikacji przez pakiety, a jego dokumentacja VpnService opisuje, jak współdziała to z trybem zawsze włączonym i blokowaniem. iOS konfiguruje VPN dla poszczególnych aplikacji przez profil zarządzania i dopasowuje według aplikacji lub według domeny. Windows i Linux nie mają w ogóle trasy według procesu, więc ten sam pomysł przybliża reguła zapory ograniczona do programu albo reguła pasująca do użytkownika będącego właścicielem.
Granicą jest identyfikator, a identyfikatory łatwo obejść. Aplikacja, która przekazuje URL przeglądarce systemowej lub otwiera dokument w przeglądarce plików, przechodzi do procesu, którego twoja polityka nigdy nie wymieniła. Opcja zakończenia przy zerwaniu też nie jest filtrem pakietów: zabija skonfigurowaną aplikację, podczas gdy proces potomny, pracownik kolejki lub karta przeglądarki mogą utrzymać istniejący socket przy życiu.
Blokada obejmuje to, czego polityka dla poszczególnych aplikacji nie widzi
Blokada całego urządzenia usuwa wybór. Każdy pakiet wychodzący, który nie należy do tunelu, jest odrzucany, łącznie z ruchem procesów, o których twoja polityka aplikacji nigdy nie wiedziała. W Androidzie to VPN zawsze włączony w połączeniu z ustawieniem blokowania połączeń, a egzekwowanie odbywa się w systemie, nie w oknie klienta. Na komputerze to trwała reguła zapory lub trasa domyślna wskazująca nieosiągalną bramę.
Kosztem jest to, że wszystko inne się zatrzymuje, więc wyjątki stają się częścią projektu, a nie późniejszą myślą. Drukarki lokalne, wykrywanie usług, logowanie do portali captive, agenci zarządzania i aktualizacje systemu potrzebują każdy udokumentowanej dziury, bo każdy z nich jest ścieżką, która pozostaje otwarta, gdy tunel nie działa. Blokada jest tylko tak silna, jak najkrótszy wpis na tej liście.
DNS, IPv6 i pomocnicy w tle ukrywają wycieki
To, że chroniona aplikacja nie rozwiązuje nazwy, nie dowodzi, że odpowiedzi z pamięci podręcznej lub bezpośredni ruch IP są blokowane. Jeśli resolver jest nadal osiągalny poza tunelem, nazwa się rozwiązuje, a połączenie zawodzi, co wygląda jak działający kill switch i nim nie jest. Gorzej, wpis w pamięci podręcznej może wskazywać adres, którego tunel nie przenosi, więc połączenie wychodzi bezpośrednio, podczas gdy aplikacja zgłasza błąd VPN.
IPv6 wymaga własnej reguły na każdej platformie, która go uruchamia, bo reguła odrzucania dla v4 nie obejmuje trasy v6. Na urządzeniu mobilnym ustawienie prywatnego DNS może przenieść rozwiązywanie do szyfrowanego kanału, którego polityka urządzenia nie sprawdza. A pomocnicy w tle to zwykły winowajca na komputerze: proces aktualizacji lub synchronizacji w zasobniku startuje przed klientem VPN i trzyma własne połączenie, więc nigdy nie widzi zmienionej trasy.
Przetestuj trzy aplikacje i dwa przejścia
| Test | What it proves |
|---|---|
| Included app, by name and by direct IP | the policy is applied, not just the resolver |
| Excluded app, same checks | the exclusion is intentional and documented |
| Helper or updater process | nothing inherited an older route |
| Tunnel drop, then Wi-Fi to cellular | the block survives the transition |
Uruchom każdy wiersz dwa razy, raz z nazwą hosta i raz z adresem dosłownym, i jeszcze raz przez IPv6, jeśli sieć to oferuje. Zaliczenie oznacza, że dołączona aplikacja się zatrzymała, wykluczona zachowała się tak, jak zapisałeś, a pomocnik nie wymknął się. Zapisz zachowanie bezpośrednie, które uznałeś za dopuszczalne, aby następny administrator odróżnił celowy wyjątek od awarii.
Następnie opisz wynik jednym zdaniem, które wymienia aplikacje i warunki, na przykład: klient płacowy nie ma trasy poza tunelem, przeglądarka jest bezpośrednia z założenia, a wszystko inne zatrzymuje się, gdy tunel nie działa. Jeśli to zdanie trudno napisać, polityka wciąż jest dwiema politykami walczącymi ze sobą.