Android 12 a IKEv1 VPN: verzia pri uvedení, IKEv2, aplikácie tretích strán

Dva telefóny oba v Nastaveniach hlásia Android 12 a iba jeden z nich ešte spúšťa starý profil IPsec XAuth, ktorý ponúka vaša brána. Rozdiel nie je nastavenie, ku ktorému sa používateľ dostane: ochrana, ktorá blokuje natívnu staršiu cestu IKEv1, sa pozerá na úroveň SDK, s ktorou bolo zariadenie dodané, nie len na vydanie, ktoré práve beží. Ten jediný detail rozhoduje, či má porovnanie flotily zmysel, a tiež rozhoduje, ktorú z troch migračných ciest vlastne potrebujete.

Dva telefóny s Androidom 12 nie sú rovnaký testovací prípad

Zmena v AOSP, ktorá zabránila novým zariadeniam spúšťať staršie profily IKEv1, porovnáva DEVICE_INITIAL_SDK_INT s Androidom S, teda API 31. Na natívnej staršej štartovacej ceste vyvolá kvalifikovaný profil zlyhanie nepodporovanej operácie skôr, než vôbec vznikne použiteľné pripojenie. Telefón dodaný s Androidom 11 a neskôr aktualizovaný touto ochranou stále prejde; model uvedený s Androidom 12 nie.

Obe čísla si prečítate na zariadení so zapnutým ladením:

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

Prvá hodnota je úroveň pri uvedení, na ktorej ochrane záleží, druhá je to, čo telefón dnes spúšťa. Kde vlastnosť chýba, opierajte sa o dokumentáciu podpory modelu namiesto hádania z marketingového názvu a nepredpokladajte, že zostava výrobcu zachováva každú cestu kompatibility, akú malo základné vydanie.

Ešte jeden rozdiel ušetrí hodinu premárneného času podpory: uložený profil, ktorý je stále v zozname v nastaveniach VPN, nič nedokazuje o tom, či ho platforma spustí. Opätovné zadanie PSK alebo úprava trás neodstráni kontrolu podpory protokolu, ktorá beží skôr, a zlyhanie vyzerá ako problém s prihlasovacími údajmi, hoci ním nie je.

Cesta prvá: ponechať natívny starší zásobník tam, kde ešte beží

Starší zásobník je ten, ktorý číta profily IPsec XAuth PSK, IPsec Hybrid RSA a L2TP/IPsec PSK zo systémovej obrazovky VPN. Na zariadení dodanom pod API 31 zostáva po aktualizácii životaschopnou cestou, preto pilot na staršom telefóne môže uspieť, kým nový telefón ten istý profil odmietne.

Porovnanie, na ktorom záleží, je podľa triedy zariadenia, nie podľa verzie Androidu: vypíšte modely vo flotile, prečítajte ich úrovne API pri uvedení a rozdeľte ich na zariadenia, ktoré profil ešte spúšťajú, a zariadenia, ktoré nemôžu. Čokoľvek iné vytvorí politiku podpory, ktorá si odporuje v okamihu, keď si používateľ kúpi nový telefón.

Cesta druhá: platformové profily IKEv2

Verejný model provisioningu Androidu pre IKEv2 je iný objekt, nie premenovaný profil IKEv1. Platformové API pre profily IKEv2 prišlo s API 30 a očakáva IKEv2 s metódou overenia, ktorú brána ponúka, zvyčajne na báze certifikátu alebo EAP. Neexistuje drôtovo kompatibilný upgrade z IKEv1 XAuth alebo Hybrid na IKEv2: bránu treba nakonfigurovať pre nový protokol a profil musí niesť zodpovedajúcu identitu.

Toto je cesta s najdlhšou životnosťou a zároveň tá, ktorá odhalí skutočnú prácu. Overenie identity, autentifikácia používateľov, DNS, trasy deleného tunela a autorizácia zdrojov musia všetky prežiť migráciu; ak sa podarí len handshake, používatelia zostanú pripojení k tunelu, ktorý nikam nevedie.

Nasadenie zvyčajne ide cez MDM alebo spravovanú konfiguráciu, nie cez používateľa, ktorý vypĺňa polia. Ak táto infraštruktúra ešte neexistuje, migračný plán ju musí zahrnúť, pretože opätovné ručné zadávanie profilu IKEv2 na každom zariadení nie je operácia, ktorú help desk zvládne.

Cesta tretia: klientska aplikácia tretej strany

Niektoré VPN aplikácie dodávajú vlastnú implementáciu protokolu a vôbec nezávisia od natívneho staršieho zásobníka. To z nich robí legitímne dočasné riešenie pre flotilu, ktorá nedokáže rýchlo migrovať, ale otázka kompatibility sa presúva na aplikáciu: či implementuje presne ten režim IKEv1, ktorým hovorí vaša brána, s overením a šifrovacími sadami, ktoré brána vyžaduje.

Berte vlastnú maticu podpory aplikácie ako autoritu, nie popis v obchode, a pred odporúčaním otestujte jedno skutočné zariadenie proti skutočnej bráne. Rootovanie telefónu, aby sa obnovila odstránená platformová cesta, tiež nie je udržiavané riešenie; presúva problém do nepodporovanej konfigurácie, ktorú môže ďalšia aktualizácia systému potichu pokaziť.

Vyberajte podľa toho, čo brána dokáže ponúknuť

Rozhodnutie sa zúži, keď viete dve veci: ktoré zariadenia boli uvedené s API 31 alebo neskôr a či brána dokáže ponúknuť službu IKEv2 s rovnakým modelom zápisu. Ak dokáže, migrujte a prestaňte investovať do staršieho profilu. Ak ešte nedokáže, ponechajte IKEv1 pre zariadenia, ktoré ho ešte spúšťajú, a novým zariadeniam dajte klienta tretej strany ako zdokumentovanú, časovo ohraničenú výnimku namiesto nevyslovenej obchádzky.

Dva body robia plán obhájiteľným. Po prvé, zaznamenajte dôvod každej výnimky spolu s modelom a úrovňou pri uvedení, aby audítor videl, že hranica je ochrana platformy a nie nevysvetlená preferencia. Po druhé, berte migráciu ako plánovanú prácu: IKEv1 je zastaraný podľa štandardnej línie (RFC 9395), čo znamená, že zostávajúce zariadenia budú ubúdať a výnimky by mali vypršať spolu s nimi.