Android 12 i IKEv1 VPN: wersja premierowa, IKEv2, aplikacje innych firm

Dwa telefony oba pokazują w Ustawieniach Android 12, a tylko jeden z nich nadal uruchamia stary profil IPsec XAuth oferowany przez Twoją bramę. Różnica nie jest ustawieniem, do którego użytkownik może dotrzeć: zabezpieczenie, które blokuje rodzimą odziedziczoną ścieżkę IKEv1, patrzy na poziom SDK, z jakim urządzenie zostało wydane, a nie tylko na wydanie, które działa teraz. Ten jeden szczegół decyduje, czy porównanie floty ma sens, i decyduje też, której z trzech ścieżek migracji naprawdę potrzebujesz.

Dwa telefony z Androidem 12 to nie ten sam przypadek testowy

Zmiana w AOSP, która uniemożliwiła nowym urządzeniom uruchamianie odziedziczonych profili IKEv1, porównuje DEVICE_INITIAL_SDK_INT z Android S, czyli API 31. W rodzimej odziedziczonej ścieżce startu kwalifikujący się profil wywołuje błąd nieobsługiwanej operacji, zanim powstanie jakiekolwiek użyteczne połączenie. Telefon wydany z Androidem 11 i później zaktualizowany nadal przechodzi tę kontrolę; model wydany z Androidem 12 już nie.

Te dwie liczby można odczytać na urządzeniu z włączonym debugowaniem:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

Pierwsza wartość to poziom premierowy, na którym zależy zabezpieczeniu, druga to to, co telefon uruchamia dziś. Tam, gdzie właściwości brakuje, opieraj się na dokumentacji wsparcia modelu, a nie na domysłach z nazwy marketingowej, i nie zakładaj, że kompilacja producenta zachowuje każdą ścieżkę zgodności, jaką miało wydanie bazowe.

Jeszcze jedna różnica oszczędza godzinę zmarnowanego czasu wsparcia: zapisany profil wciąż widoczny w ustawieniach VPN niczego nie dowodzi co do tego, czy platforma go uruchomi. Ponowne wpisanie PSK albo zmiana tras nie usunie kontroli obsługi protokołu, która działa wcześniej, a błąd wygląda jak problem z poświadczeniami, choć nim nie jest.

Ścieżka pierwsza: zachowaj rodzimy stos odziedziczony tam, gdzie jeszcze działa

Stos odziedziczony to ten, który odczytuje profile IPsec XAuth PSK, IPsec Hybrid RSA i L2TP/IPsec PSK z systemowego ekranu VPN. Na urządzeniu wydanym poniżej API 31 pozostaje on realną ścieżką po aktualizacji, dlatego pilotaż na starszym telefonie może się udać, podczas gdy nowy telefon odrzuca ten sam profil.

Porównanie, które ma znaczenie, odbywa się według klasy urządzenia, a nie według wersji Androida: wypisz modele we flocie, odczytaj ich poziomy premierowe API i podziel je na urządzenia, które nadal uruchamiają profil, i te, które nie mogą. Wszystko inne daje politykę wsparcia, która przeczy sama sobie w chwili, gdy użytkownik kupuje nowy telefon.

Ścieżka druga: profile IKEv2 platformy

Publiczny model provisioningu Androida dla IKEv2 to inny obiekt, a nie przemianowany profil IKEv1. Platformowe API dla profili IKEv2 pojawiło się z API 30 i oczekuje IKEv2 z metodą uwierzytelniania oferowaną przez bramę, zwykle certyfikatową lub EAP. Nie ma aktualizacji zgodnej na poziomie transmisji z IKEv1 XAuth lub Hybrid do IKEv2: brama musi być skonfigurowana dla nowego protokołu, a profil musi nieść pasującą tożsamość.

To ścieżka o najdłuższym życiu, a zarazem ta, która obnaża prawdziwą pracę. Walidacja tożsamości, uwierzytelnianie użytkownika, DNS, trasy split-tunnel i autoryzacja zasobów muszą przetrwać migrację; gdy uda się tylko uścisk dłoni, użytkownicy zostają podłączeni do tunelu, który donikąd nie dociera.

Wdrożenie zwykle idzie przez MDM albo konfigurację zarządzaną, a nie przez użytkownika wpisującego pola. Jeśli tej infrastruktury jeszcze nie ma, plan migracji musi ją objąć, bo ręczne wpisywanie profilu IKEv2 na każdym urządzeniu nie jest operacją, którą help desk może udźwignąć.

Ścieżka trzecia: aplikacja kliencka innej firmy

Niektóre aplikacje VPN dostarczają własną implementację protokołu i wcale nie zależą od rodzimego stosu odziedziczonego. Czyni je to uzasadnionym rozwiązaniem tymczasowym dla floty, która nie może szybko migrować, ale pytanie o zgodność przenosi się na aplikację: czy implementuje dokładnie ten tryb IKEv1, którym mówi Twoja brama, z uwierzytelnianiem i zestawami szyfrów, których brama wymaga.

Traktuj własną matrycę wsparcia aplikacji jako autorytet, a nie opis w sklepie, i przetestuj jedno realne urządzenie z realną bramą, zanim ją polecisz. Rootowanie telefonu, aby przywrócić usuniętą ścieżkę platformy, też nie jest utrzymywanym rozwiązaniem; przenosi problem do nieobsługiwanej konfiguracji, którą następna aktualizacja systemu może po cichu zepsuć.

Wybieraj według tego, co brama może zaoferować

Decyzja zawęża się, gdy wiesz dwie rzeczy: które urządzenia wydano z API 31 lub później i czy brama może przedstawić usługę IKEv2 z tym samym modelem rejestracji. Jeśli może, migruj i przestań inwestować w profil odziedziczony. Jeśli jeszcze nie może, zostaw IKEv1 dla urządzeń, które go jeszcze uruchamiają, a nowym urządzeniom daj klienta innej firmy jako udokumentowany, terminowy wyjątek, a nie przemilczane obejście.

Dwa punkty czynią plan obronnym. Po pierwsze, zapisz powód każdego wyjątku wraz z modelem i poziomem premierowym, aby audytor widział, że granica to zabezpieczenie platformy, a nie niewyjaśniona preferencja. Po drugie, traktuj migrację jako zaplanowaną pracę: IKEv1 jest przestarzały w ścieżce standardów (RFC 9395), co oznacza, że pozostałe urządzenia będą się kurczyć, a wyjątki powinny wygasać razem z nimi.