Android 12 i IKEv1 VPN: verzija lansiranja, IKEv2, 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š pristupnik. Razlika nije postavka do koje korisnik može doći: zaštita koja blokira ugrađenu naslijeđenu IKEv1 putanju gleda SDK razinu s kojom je uređaj isporučen, a ne samo izdanje koje sada izvršava. Taj jedan detalj odlučuje ima li usporedba flote smisla, a odlučuje i koja od tri migracijska puta vam stvarno trebaju.

Dva telefona s Androidom 12 nisu isti testni slučaj

Promjena u AOSP-u koja je zaustavila nove uređaje u pokretanju naslijeđenih IKEv1 profila uspoređuje DEVICE_INITIAL_SDK_INT s Androidom S, odnosno API 31. Na ugrađenoj naslijeđenoj putanji pokretanja kvalificirani profil izaziva grešku nepodržane operacije prije nego što uopće postoji korisna veza. Telefon isporučen s Androidom 11 i kasnije ažuriran još prolazi tu zaštitu; model lansiran s Androidom 12 ne prolazi.

Oba broja možete pročitati na uređaju s omoguć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 lansiranja do koje je zaštiti stalo, druga je ono što telefon izvršava danas. Gdje svojstvo nedostaje, oslonite se na dokumentaciju podrške modela umjesto nagađanja iz marketinškog naziva, i ne pretpostavljajte da proizvođačka gradnja čuva svaku putanju kompatibilnosti koju je imalo osnovno izdanje.

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

Put jedan: zadržite ugrađeni naslijeđeni stek gdje još radi

Naslijeđeni stek je onaj koji čita IPsec XAuth PSK, IPsec Hybrid RSA i L2TP/IPsec PSK profile sa sistemskog VPN zaslona. 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 odbija isti profil.

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

Put dva: platformski IKEv2 profili

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

Ovo je put s najduljim životom, i ujedno onaj koji otkriva stvarni rad. Provjera identiteta, autentikacija korisnika, DNS, rute podijeljenog tunela i autorizacija resursa sve moraju preživjeti migraciju; ako uspije samo rukovanje, korisnici ostaju spojeni na tunel koji ništa ne doseže.

Uvođenje obično ide preko MDM-a ili upravljane konfiguracije, a ne preko korisnika koji upisuje polja. Ako ta infrastruktura još ne postoji, plan migracije mora je uključiti, jer ponovni ručni unos IKEv2 profila na svakom uređaju nije operacija koju služba podrške može upiti.

Put tri: klijentska aplikacija treće strane

Neke VPN aplikacije isporučuju vlastitu implementaciju protokola i uopće ne ovise o ugrađenom naslijeđenom steku. To ih čini legitimnim privremenim rješenjem za flotu koja ne može brzo migrirati, ali pitanje kompatibilnosti prelazi na aplikaciju: implementira li točno onaj IKEv1 način kojim govori vaš pristupnik, s autentikacijom i skupovima šifri koje pristupnik zahtijeva.

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

Birajte prema tome što pristupnik može ponuditi

Odluka se sužava kad znate dvije stvari: koji su uređaji lansirani na API 31 ili poslije, i može li pristupnik predstaviti IKEv2 uslugu s istim modelom upisa. Ako može, migrirajte i prestanite ulagati u naslijeđeni profil. Ako još ne može, zadržite IKEv1 za uređaje koji ga još pokreću, a novim uređajima dajte klijenta treće strane kao dokumentiranu, vremenski ograničenu iznimku umjesto neizrečenog zaobilaznog rješenja.

Dvije stvari čine plan obranjivim. Prvo, zabilježite razlog svake iznimke uz model i razinu lansiranja, da revizor vidi kako je granica zaštita platforme, a ne neobjašnjena sklonost. Drugo, tretirajte migraciju kao planirani posao: IKEv1 je zastario prema standardnoj stazi (RFC 9395), što znači da će se preostali uređaji nastaviti smanjivati i iznimke bi trebale isteći zajedno s njima.