Profile VPN IKEv2 w Androidzie są przypisane do użytkownika, nie do urządzenia

Określenie wbudowany VPN obejmuje w Androidzie dwie niepowiązane rzeczy: implementację protokołu, którą platforma uruchamia w Twoim imieniu, oraz ten kształt ustawień, który producent zdecydował się pokazać. To nie ten sam obiekt i żadna z nich nie gwarantuje, że tunel należy do użytkownika, którego aplikacje go potrzebują. Tworzenie profilu odbywa się w konkretnym użytkowniku z konkretnym pakietem wywołującym, a wszystko dalej dziedziczy ten kontekst. Przeczytaj łańcuch własności, zanim przeczytasz ekran ustawień.

Co platforma buduje za Ciebie

Od Androida 11 platforma udostępnia tworzenie profili VPN przez VpnManager. Zatwierdzona aplikacja opisuje profil IKEv2, a platforma sama prowadzi wymianę IPsec i IKE, więc aplikacja nigdy nie dotyka pakietów. To istotna różnica wobec własnej aplikacji VPN, która implementuje VpnService i buduje tunel we własnym procesie.

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

Powyższe wywołanie to szkic kształtu, a nie blok do skopiowania: builder ma kilka przeciążeń uwierzytelniania, różnią się one w zależności od poziomu API, a profil niesie też materiał zaufania certyfikatu serwera. To, co ważne dla pytania o własność, jest węższe niż składnia.

Z tego projektu wynikają dwie właściwości. Profil jest danymi, więc może go utworzyć administrator zamiast wpisywać ręcznie. A tunel jest siecią platformy, więc aplikacjom jawi się jako sieć z transportem VPN, a nie jako gniazdo innej aplikacji.

Własność to najpierw użytkownik, potem pakiet

Wielu użytkowników w Androidzie to prawdziwe rozdzielenie, nie etykieta. Profil służbowy to odrębny użytkownik z własnymi zainstalowanymi pakietami, własnymi danymi aplikacji, własnym keystore i własnymi kotwicami zaufania. Ten sam produkt zainstalowany w obu miejscach to dwie instancje o różnych identyfikatorach użytkownika, nawet gdy ikony w launcherze i nazwy produktu są identyczne.

Utworzenie profilu jest rejestrowane na pakiecie wywołującym w tym użytkowniku. Aplikacja do tworzenia profili działająca w profilu osobistym tworzy więc tunel osobisty, a aplikacje służbowe w profilu służbowym nic z niego nie widzą. Odwrotnie też jest prawdą, dlatego tunel profilu służbowego jest niewidoczny dla aplikacji osobistych bez wyraźnej polityki mówiącej inaczej.

Kontroler polityki urządzenia może tworzyć profile w imieniu profilu zarządzanego i to wyjaśnia wpis, którego nikt w biurze nie pamięta, że go utworzył. Jeśli audytujesz telefon, to prawdopodobny właściciel wyszarzonego profilu, a usunięcie go jako eksperymentu nie należy do Ciebie.

Trzy bramy, zanim pakiet ruszy

Pierwsza brama to uprawnienie: zarządzanie musi w ogóle dopuszczać VPN, a niektóre wdrożenia ograniczają zarówno typ, jak i samo istnienie. Druga to tożsamość: certyfikat klienta lub poświadczenia muszą być dostępne w użytkowniku, który jest właścicielem profilu, bo certyfikat zaimportowany do osobistego keystore nie jest widoczny dla profilu służbowego.

Trzecia to zgoda i polityka. Użytkownik zwykle zatwierdza połączenie przy pierwszym użyciu, a administrator może dodatkowo przypiąć je jako zawsze włączone, opcjonalnie z blokadą, aby ruch nie mógł wychodzić poza tunel. Te ustawienia decydują, co się dzieje, gdy tunel padnie, i tę część użytkownicy zauważają.

Zakres to miejsce, w którym te trzy się spotykają. Profil określa bramę i tożsamość, natomiast warstwa polityki decyduje, które aplikacje mogą korzystać z tunelu i czy ruch jest przez niego wymuszany. Dwa telefony z identycznymi adresami bramy mogą więc zachowywać się zupełnie różnie.

Dlaczego połączenie osobiste nie obejmuje aplikacji służbowych

Ruch z aplikacji służbowej powstaje w użytkowniku służbowym, a polityka sieciowa, która ma zastosowanie, to ta w tym użytkowniku. Tunel ustanowiony w profilu osobistym go nie przenosi, niezależnie od tego, jak zdrowy wygląda wskaźnik. Ten jeden fakt wyjaśnia większość zgłoszeń, w których użytkownik przysięga, że VPN jest połączony, a jedna konkretna aplikacja wciąż nie sięga usługi wewnętrznej.

Rozwiązywanie nazw podlega tej samej granicy. Prywatne sufiksy DNS i kotwice zaufania są na użytkownika, więc wewnętrzna nazwa hosta, która rozwiązuje się w profilu osobistym, może zawieść w profilu służbowym nawet przy pozornie równoważnym tunelu, bo polityka resolvera i magazyn CA to różne obiekty.

Weryfikuj na prawdziwej rejestracji, nie na telefonie laboratoryjnym

Na urządzeniu najpierw ustal właściciela wpisu: który użytkownik, który pakiet i czy profil pochodzi od dostawcy platformy, czy od aplikacji implementującej własną usługę VPN. Potem potwierdź, że tożsamość oczekiwana przez profil faktycznie jest w keystore tego użytkownika.

Testuj cykl życia, nie tylko połączenie. Zaloguj się, odblokuj magazyn poświadczeń, pozwól profilowi służbowemu odpocząć przez wieczór, następnie przywróć go i sprawdź, czy tunel wraca bez ręcznego stuknięcia. Profil służbowy, który wyłącza się po godzinach, zabiera ze sobą tunel, i jest to zachowanie oczekiwane, a nie usterka, pod warunkiem że oczekiwany stan niedostępności jest zapisany.

Na koniec przetestuj samą aplikację służbową wobec znanego wewnętrznego punktu końcowego i porównaj z wynikiem profilu osobistego. Oba mogą się różnić; różnić nie może się model własności. Jeśli tunel należy do niewłaściwego użytkownika, ponowne wystawianie certyfikatu nic nie naprawi.

Nie wymuszaj sprawy, uruchamiając ukryte działania ustawień, aby odsłonić menu, i nie kopiuj kluczy prywatnych między profilami, aby połączenie zaczęło wyglądać. Dokumentacja VpnManager opisuje, co wywołujący może utworzyć; jeśli zatwierdzona ścieżka nie obejmuje Twojego przypadku, to decyzja dla administratora, a nie problem z ustawieniami.