Android 12 i IKEv1 VPN: verzija pri isporuci, IKEv2 i aplikacije trećih strana

Dva telefona oba prikazuju Android 12 u Postavkama, a samo jedan od njih još pokreće stari IPsec XAuth profil koji nudi vaš gateway. Razlika nije postavka do koje korisnik može doći: zaštita koja upravlja native IKEv1 putanjom gleda SDK razinu s kojom je uređaj isporučen, ne samo verziju koja sada radi. Taj jedan detalj odlučuje ima li usporedba flote smisla, a odlučuje i koja vam je od tri migracijske putanje zaista potrebna.

Dva telefona s Androidom 12 nisu isti testni slučaj

Promjena u AOSP-u koja je zaustavila nove uređaje da pokreću stare IKEv1 profile uspoređuje DEVICE_INITIAL_SDK_INT s Android S, što je API 31. U native putanji pokretanja odgovarajući profil vraća grešku nepodržane operacije prije nego što uopće postoji korisna veza. Telefon isporučen s Android 11 i kasnije ažuriran još prolazi tu zaštitu; model koji je izašao s Android 12 ne prolazi.

Dva broja možete pročitati na uređaju s uključenim otklanjanjem pogrešaka:

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

Prva vrijednost je razina isporuke koja zaštitu zanima, druga je ono što telefon izvršava danas. Gdje svojstvo nedostaje, oslonite se na dokumentaciju podrške modela umjesto da nagađate iz marketinškog naziva, i ne pretpostavljajte da proizvođačka gradnja čuva sve putanje kompatibilnosti osnovne verzije.

Još jedna razlika štedi sat izgubljenog vremena podrške: spremljeni profil koji je još na popisu u postavkama VPN-a ne dokazuje ništa o tome hoće li ga platforma pokrenuti. Ponovni unos PSK-a ili izmjena ruta ne mogu ukloniti provjeru podrške protokola koja se izvršava ranije, a kvar izgleda kao problem s vjerodajnicama kad nije.

Putanja jedan: zadržite native stack gdje još radi

Stari stack je onaj koji čita profile IPsec XAuth PSK, IPsec Hybrid RSA i L2TP/IPsec PSK sa sistemskog zaslona VPN-a. Na uređaju isporučenom ispod API 31 ostaje održiva putanja nakon nadogradnje, zato pilot na starijem telefonu može uspjeti dok novi telefon ne pokreće isti profil.

Usporedba koja je važna je po klasi uređaja, ne po verziji Androida: popišite modele u floti, pročitajte njihove API razine isporuke i podijelite ih na uređaje koji profil još pokreću i one koji ne mogu. Sve drugo stvara politiku podrške koja proturječi sama sebi onog trenutka kad korisnik kupi novi telefon.

Putanja dva: platformski IKEv2 profili

Androidov javni model omogućavanja za IKEv2 je drugi objekt, a ne preimenovani IKEv1 profil. Platformski API za IKEv2 profile došao je s API 30 i očekuje IKEv2 s metodom autentifikacije koju gateway nudi, obično na temelju certifikata ili EAP-a. Nema žičano kompatibilne nadogradnje s IKEv1 XAuth ili Hybrid na IKEv2: gateway se mora konfigurirati za novi protokol, a profil mora nositi odgovarajući identitet.

To je putanja s najdužim životom, i upravo ona otkriva pravi posao. Provjera identiteta, autentifikacija korisnika, DNS, rute split-tunela i autorizacija resursa sve moraju preživjeti migraciju; uspješno samo rukovanje ostavlja korisnike vezane za tunel koji nikamo ne stiže.

Uvođenje obično ide kroz MDM ili upravljanu konfiguraciju, umjesto da korisnik upisuje polja. Ako ta infrastruktura još ne postoji, plan migracije je mora uključiti, jer ponovni ručni unos IKEv2 profila na svakom uređaju nije operacija koju servisna služba može apsorbirati.

Putanja tri: klijentska aplikacija treće strane

Neke VPN aplikacije isporučuju vlastitu implementaciju protokola i uopće ne zavise od native stacka. To ih čini legitimnim privremenim rješenjem za flotu koja ne može brzo migrirati, ali pitanje kompatibilnosti seli se na aplikaciju: implementira li točno onaj IKEv1 mod koji vaš gateway govori, s autentifikacijom i skupovima šifri koje gateway zahtijeva.

Uzmite vlastitu matricu podrške aplikacije kao autoritet, a ne opis u trgovini, i testirajte jedan stvarni uređaj protiv stvarnog gatewaya prije nego što je preporučite. Rootanje telefona da bi se vratila uklonjena platformska putanja također nije održivo rješenje; ono seli problem u nepodržanu konfiguraciju koju sljedeće sistemsko ažuriranje može tiho slomiti.

Odaberite po tome što gateway može ponuditi

Odluka se sužava kad znate dvije stvari: koji su uređaji isporučeni na API 31 ili poslije i može li gateway ponuditi IKEv2 uslugu s istim modelom registracije. Ako može, migrirajte i prestanite ulagati u stari profil. Ako još ne može, zadržite IKEv1 za uređaje koji ga još pokreću, a novim uređajima dajte klijent treće strane kao dokumentiran, vremenski ograničen izuzetak, a ne neizgovoreni zaobilazni put.

Dvije stvari čine plan obranjivim. Prvo, zabilježite razlog svakog izuzetka uz model i razinu isporuke, da auditor vidi da je granica platformska zaštita, a ne neobjašnjena preferencija. Drugo, tretirajte migraciju kao planirani posao: IKEv1 je napušten u standardnoj stazi (RFC 9395), što znači da će se preostali uređaji nastaviti smanjivati i izuzeci bi trebali isteći s njima.