Android 12 i IKEv1 VPN: verzija pri lansiranju, 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 nivo s kojim je uređaj isporučen, ne samo verziju koja sada radi. Taj jedan detalj odlučuje ima li poređenje flote smisla, a odlučuje i koja vam je od tri migracione 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 poredi DEVICE_INITIAL_SDK_INT sa Android S, što je API 31. U native putanji pokretanja odgovarajući profil vraća grešku nepodržane operacije prije nego što uopšte 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 greš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 nivo lansiranja koji 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: sačuvani profil koji je još na listi 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 akreditivima 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 ekrana 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.

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

Putanja dva: platformski IKEv2 profili

Androidov javni model provisioninga za IKEv2 je drugi objekat, 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 zasnovanom na certifikatu ili EAP-u. Nema žičano kompatibilne nadogradnje s IKEv1 XAuth ili Hybrid na IKEv2: gateway se mora konfigurisati 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 apsorbovati.

Putanja tri: klijentska aplikacija treće strane

Neke VPN aplikacije isporučuju vlastitu implementaciju protokola i uopšte ne zavise od native stacka. To ih čini legitimnim privremenim rješenjem za flotu koja ne može brzo migrirati, ali pitanje kompatibilnosti se seli na aplikaciju: implementira li tač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. Rootovanje 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.

Birajte po tome šta gateway može ponuditi

Odluka se sužava kad znate dvije stvari: koji uređaji su lansirani na ili poslije API 31 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 dokumentovan, vremenski ograničen izuzetak, a ne neizgovoreni zaobilazni put.

Dvije stvari čine plan odbranjivim. Prvo, zabilježite razlog svakog izuzetka uz model i nivo lansiranja, 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 preostali uređaji nastaviti da se smanjuju i izuzeci bi trebali isteći s njima.