Gdzie musi znajdować się reguła zapory Androida, gdy VPN jest włączony
Tylko jedna usługa VpnService może być aktywna, więc aplikacja zapory i aplikacja VPN nie łączą się w stos. Prześledź jedno żądanie i umieść każdą regułę tam, gdzie jej ruch naprawdę przechodzi.
Masz jedno zdanie polityki: ta aplikacja może docierać do usługi służbowej i do niczego innego. Kolejne pytanie wygląda na wybór produktu, ale jest pytaniem o lokalizację, bo każdy potencjalny punkt egzekwowania widzi inny podzbiór ruchu telefonu. Brama widzi tylko to, co wchodzi do tunelu. Filtr po stronie telefonu widzi tylko to, co wolno mu obserwować. Przeprowadzenie jednego żądania przez oba punkty czyni odpowiedź oczywistą.
Zacznij od zdania, nie od produktu
Rozwiń wymaganie, zanim cokolwiek wybierzesz. To znaczy pakiet i profil, w którym działa, bo aplikacja w profilu służbowym to inny użytkownik niż ta sama aplikacja w profilu osobistym. To znaczy miejsce docelowe: host, port i protokół, a nie nazwa usługi. To znaczy ścieżka DNS, która rozwiązuje tę nazwę, oraz to, co powinno się stać, gdy tunel nie jest dostępny.
Zapisana polityka dla przykładu ma cztery wiersze: aplikacja służbowa może docierać do usługi służbowej; aplikacja służbowa nie może docierać do niczego innego; pozostałe aplikacje pozostają bez zmian; bez tunelu aplikacja służbowa jest blokowana, a nie przechodzi na połączenie bezpośrednie. Każdy wiersz ma właściciela i nie wszyscy są tym samym właścicielem.
Krok 1: co może wymusić sam telefon
Nierootowa zapora Android to usługa VpnService, która przechwytuje ruch lokalnie, nawet gdy nie ma za nią zdalnego tunelu. Android zezwala na jedną aktywną usługę VPN na profil użytkownika, więc druga aplikacja zapory nie podłącza się za pierwszą. Zastępuje ją, a interfejs, który filtrowała pierwsza aplikacja, znika.
Dlatego instalowanie zapory obok klienta VPN rzadko daje kombinację, której ludzie oczekują. Jeśli zapora startuje, a VPN się rozłącza, nic nie zostało połączone; te dwa elementy zamieniły się miejscami. Zamiana interfejsu nie jest współpracą, a objawem jest tunel, który ciągle się zrywa, ilekroć otworzysz drugą aplikację.
Obsługiwane układy jednak istnieją: filtrowanie wbudowane w klienta VPN, którego już używasz, zarządzane mechanizmy platformy przez kontroler polityki urządzenia lub profil służbowy, albo architektura opisana przez producenta. Wszystko inne to eksperyment, który trzeba ponownie weryfikować po każdej aktualizacji aplikacji.
Krok 2: co może wymusić brama
Gdy ruch zostanie odszyfrowany na drugim końcu, brama może ograniczyć przekazywane pakiety do zatwierdzonych adresów, usług lub uwierzytelnionych tożsamości VPN. To prawdziwe egzekwowanie dla wszystkiego, co wychodzi przez nią, i właściwe miejsce do ograniczania dostępu do podsieci prywatnych.
Nie otrzymuje jednak tożsamości aplikacji telefonu przypisanej do każdego zwykłego pakietu IP. Kilka aplikacji dzielących jeden adres tunelu to dla bramy jeden podmiot, chyba że projekt nada im osobne adresy lub osobne uwierzytelnione tożsamości. Reguła na użytkownika na bramie nie jest więc regułą na aplikację na telefonie, niezależnie od tego, jak nazywa ją konsola zarządzania.
Krok 3: wypisz to, co nigdy nie dociera
Aplikacja wyłączona z VPN, która łączy się z pobliskim urządzeniem, nigdy nie dociera do bramy, więc zapora wyjściowa nie może odrzucić pakietu, którego nigdy nie otrzymuje. To samo dotyczy niezamierzonej trasy bezpośredniej podczas awarii i ekspozycji przychodzącej w lokalnej sieci dostępowej. To granice lokalne z definicji.
Zachodzi też odwrotność: lokalna reguła, która pozwala na połączenie, nie przyznaje dostępu przez listę ACL sieci prywatnej bramy. Jedno żądanie może podlegać obu granicom, a spełnienie jednej nic nie mówi o drugiej.
Krok 4: przypisz każdą regułę do ścieżki
Umieść decyzję w tabeli, zanim cokolwiek skonfigurujesz, bo puste komórki to miejsca, w których projekty zawodzą.
| Path | Who can enforce it | Blind spot |
|---|---|---|
| Work app to the work service, tunnel up | Gateway ACL on address and service, plus a local block on other paths | The gateway cannot see which app sent the packet |
| Work app to other destinations, tunnel up | Local app-aware filter, or the gateway if those destinations are addressed there | The local filter must be the active VpnService |
| Work app with no tunnel | Local deny, so the app cannot take a direct path | Requires the filter to survive the tunnel going away |
| Nearby LAN device | Local policy only | The gateway never sees it |
Działający kształt to dwie granice z dwoma zadaniami. Lokalna granica świadoma aplikacji rządzi zachowaniem telefonu, w tym bezpośrednim obejściem, a granica bramy rządzi zasobami zdalnymi. Strona bramy może zezwolić na usługę służbową i odrzucić każdą inną podsieć prywatną, podczas gdy polityka po stronie telefonu sama decyduje o bezpośredniej trasie, którą aplikacja mogłaby inaczej wybrać.
Krok 5: utrzymaj transport przy życiu, potem weryfikuj
Niezależnie od wybranej polityki lokalnej musi ona przepuszczać transport, który ustanawia i utrzymuje VPN. Zablokowanie tego transportu zostawia telefon bez tunelu i bez polityki, co niczego spójnie nie egzekwuje i jest trudne do zdiagnozowania, bo aplikacja po prostu nie ma sieci.
Następnie zweryfikuj każdy wiersz pierwotnego zdania, a nie ogólne wrażenie: aplikacja służbowa dociera do usługi służbowej, ta sama aplikacja jest odrzucana w innym miejscu docelowym, aplikacja niesłużbowa zachowuje się jak wcześniej, a przy zatrzymanym tunelu aplikacja służbowa nie przechodzi na połączenie bezpośrednie. Sprawdź osobno ścieżkę DNS, bo prywatny DNS lub szyfrowany resolver mogą ominąć filtr, który sprawdza tylko adresy.
Jeśli któregoś z tych kroków nie da się spełnić na telefonie, wymaganie jest pytaniem o architekturę, a nie ustawieniem zapory. Podział polityki między urządzenie, które kontrolujesz, a bramę, którą kontrolujesz, jest zwykle uczciwą odpowiedzią, a dokumentacja łączności VPN dla Androida to miejsce, w którym potwierdzisz, co platforma pozwoli, a czego nie pozwoli zrobić jednej usłudze.