Android 12 an IKEv1-VPN: Startversioun, IKEv2 an Drëtt-Applikatiounen

Zwou Telefonen, déi allebueden Android 12 an den Astellungen uginn, a just eng vun hinnen nach de ale IPsec-XAuth-Profil start, deen Äre Gateway ubitt. Den Ënnerscheed ass keng Astellung, déi den Benotzer erreeche kann: de Schutz, deen den native Legacy-Pfad IKEv1 spillt, kuckt op de SDK-Niveau, mat deem den Apparat ausgeliwwert gouf, an net nëmmen op d'Versioun, déi en haut leeft. Dëst eenzegt Detail entscheet, ob e Flottenvergläich sënnvoll ass, an et entscheet och, wéi ee vun dräi Migratiounspfade Dir tatsächlech braucht.

Zwou Android 12 Telefone sinn net dee selwechten Testfall

D'AOSP-Ännerung, déi nei Apparater drop gehal huet, legacy IKEv1-Profiler ze starten, vergläicht DEVICE_INITIAL_SDK_INT mam Android S, dat ass API 31. Am nativen Legacy-Startpfad bréngt e qualifizéierende Profil en Ënnerstëtzungsfehler, ier iwwerhaapt eng nëtzlech Verbindung besteet. En Telefon, deen mat Android 11 ausgeliwwert gouf an duerno aktualiséiert gouf, passéiert dee Schutz nach; e Modell, deen op Android 12 gestart ass, net.

Dir kënnt déi zwou Zuelen op engem Apparat mat aktivéiertem Debugging liesen:

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

Den éischte Wäert ass de Startniveau, deen de Schutz ugeet, den zweeten ass deen, deen den Telefon haut leeft. Wou d'Proprietéit fehlt, gräift op déi offiziell Ënnerstëtzungsdokumentatioun vum Modell zréck, amplaz vum Marketingnumm ze roden, a gitt net dovun aus, datt e Vendor-Build all Kompatibilitéitspfad behält, deen de Basisrelease hat.

Eng weider Ënnerscheedung spuert eng Stonn verschwenden Supportzäit: e gespaarten Profil, deen nach an den VPN-Astellungen steet, beweist näischt dofir, ob d'Plattform en start. D'PSK nei anzeginn oder d'Routen ze änneren, kann eng Protokollkompatibilitéitspréifung net ophiewen, déi méi fréi leeft, an de Fehler gesäit aus wéi e Problem mat den Umeldungsdaten, obwuel en et net ass.

Wee een: den nativen Legacy-Stack behalen, wou en nach leeft

Den Legacy-Stack ass deen, deen IPsec-XAuth-PSK, IPsec-Hybrid-RSA an L2TP/IPsec-PSK-Profiler aus dem System-VPN-Écran liest. Op engem Apparat, deen ënner API 31 ausgeliwwert gouf, bleift en nom Upgrade e gangbare Wee, dofir kann e Pilot op engem eelere Gerät geléngen, während en neit Gerät mam selwechte Profil feelt.

De Verglach, deen zielt, ass pro Geräteklass, net pro Android-Versioun: list d'Modeller an der Flott, liest hir Start-API-Niveauen a spléckt se an Apparater, déi de Profil nach starten, an Apparater, déi et net kënnen. Alles anescht ergëtt eng Ënnerstëtzungspolitik, déi sech selwer widderläit, soubal e Benotzer en neien Telefon kaaft.

Wee zwee: Plattform-IKEv2-Profiler

Androids ëffentlecht Provisionierungsmodell fir IKEv2 ass en aneren Objet, keen ëmbenannten IKEv1-Profil. D'Plattform-API fir IKEv2-Profiler ass mat API 30 komm an erwaart IKEv2 mat der Authentifikatiounsmethod, déi de Gateway ubitt, meeschtens zertifikatsbasiert oder EAP. Et gëtt keen dréitkompatibelen Upgrade vun IKEv1 XAuth oder Hybrid op IKEv2: de Gateway muss fir dee neie Protokoll konfiguréiert ginn, an de Profil muss déi passend Identitéit droen.

Dëst ass de Wee mat der längster Liewensdauer, an och deen, deen déi richteg Aarbecht opweist. Identitéitsvalidatioun, Benotzerauthentifikatioun, DNS, Split-Tunnel-Routen a Ressourcenauthorisatioun mussen d'Migratioun iwwerstoen; just den Handshake ze schafen, léisst d'Benotzer an engem Tunnel hänken, deen näischt erreecht.

D'Deployment geet normalerweis iwwer en MDM oder eng verwalt Konfiguratioun, net iwwer ee Benotzer, dee Felder tippt. Wann dës Infrastruktur nach net existéiert, muss de Migratiounsplang se enthalen, well en IKEv2-Profil vun Hand op all Apparat nei anzeginn ass keng Operatioun, déi en Helpdesk verdauen kann.

Wee dräi: eng Drëtt-Applikatioun

E puer VPN-Applikatiounen droen hir eege Protokollimplementatioun an hänken iwwerhaapt net vum nativen Legacy-Stack of. Dofir sinn se eng legitim Iwwerbréckung fir eng Flott, déi net séier migréiere kann, awer d'Kompatibilitéitsfro verréckelt sech op d'App: ob se de genee’en IKEv1-Modus ëmsetzt, deen Äre Gateway schwätzt, mat der Authentifikatioun an de Chiffersuiten, déi de Gateway verlaangt.

Betruecht d'Ënnerstëtzungsmatrix vun der App als Autoritéit, net d'Beschreiwung am Store, an testt een richtegen Apparat géint de richtege Gateway, ier Dir se empfiehlt. En Telefon ze rooten, fir en entfernte Plattformwee ze restauréieren, ass och keng ënnerhalene Léisung; et verréckelt de Problem an eng net ënnerstëtzte Konfiguratioun, déi dat nächst Systemupdate stëll kënne briechen.

Wielt no deem, wat de Gateway ubidden kann

D'Entscheedung verengt sech, soubal Dir zwou Saache wësst: wéi eng Apparater op oder nom API 31 gestart sinn, an ob de Gateway en IKEv2-Service mat deem selwechten Enrollementmodell presentéiere kann. Wann jo, migréiert a stoppt d'Investitioun an de Legacy-Profil. Wann nach net, behält IKEv1 fir d'Apparater, déi en nach starten, a gitt neien Apparater en Drëtt-Client als dokumentéiert, befristet Ausnam, amplaz als onausgeschwate Workaround.

Zwou Punkten maachen de Plang defendéierbar. Éischtens, notéiert de Grond fir all Ausnam mam Modell an dem Startniveau, sou datt en Auditeur gesäit, datt d'Grenz e Plattformschutz ass an net eng onerkläert Preferenz. Zweetens, behandelt d'Migratioun als geplangt Aarbecht: IKEv1 ass vum Standards-Track als deprecated markéiert (RFC 9395), dat heescht, déi reschtlech Apparater ginn ëmmer manner, an d'Ausnamen sollten mat hinnen oflafen.