Android 12 en IKEv1 VPN: lanceerversie, IKEv2, apps van derden

Twee telefoons melden allebei Android 12 in Instellingen, en slechts één ervan start nog het oude IPsec XAuth-profiel dat je gateway biedt. Het verschil is geen instelling die de gebruiker kan bereiken: de bewaking die het oorspronkelijke legacy-IKEv1-pad afschermt, kijkt naar het SDK-niveau waarmee het apparaat is geleverd, niet alleen naar de release die het nu draait. Dat ene detail bepaalt of een fleetvergelijking zinvol is, en het bepaalt ook welk van drie migratiepaden je echt nodig hebt.

Twee Android 12-telefoons zijn niet dezelfde testcase

De AOSP-wijziging die nieuwe apparaten verhinderde legacy-IKEv1-profielen te starten, vergelijkt DEVICE_INITIAL_SDK_INT met Android S, ofwel API 31. In het oorspronkelijke legacypad voor opstarten levert een kwalificerend profiel een fout voor niet-ondersteunde bewerking op voordat er een bruikbare verbinding is. Een telefoon die met Android 11 is geleverd en later is bijgewerkt, passeert die bewaking nog steeds; een model dat met Android 12 is gelanceerd niet.

Je kunt de twee getallen uitlezen op een apparaat met debugging ingeschakeld:

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

De eerste waarde is het lanceerniveau waar de bewaking naar kijkt, de tweede is wat de telefoon vandaag draait. Waar de eigenschap ontbreekt, baseer je op de ondersteuningsdocumentatie van het model in plaats van te gokken op de marketingnaam, en ga er niet van uit dat een leveranciersbuild elk compatibiliteitspad van de basisrelease behoudt.

Nog een onderscheid bespaart een uur verspilde supporttijd: een opgeslagen profiel dat nog in de VPN-instellingen staat, bewijst niets over de vraag of het platform het start. De PSK opnieuw invoeren of routes aanpassen kan een protocolondersteuningscontrole die eerder draait niet wegnemen, en de fout ziet eruit als een inloggegevensprobleem terwijl dat het niet is.

Pad één: houd de oorspronkelijke legacystack waar hij nog draait

De legacystack is degene die IPsec XAuth PSK-, IPsec Hybrid RSA- en L2TP/IPsec PSK-profielen leest uit het systeem-VPN-scherm. Op een apparaat dat onder API 31 is geleverd, blijft hij na een upgrade een levensvatbaar pad, waardoor een pilot op een ouder toestel kan slagen terwijl een nieuw toestel op hetzelfde profiel faalt.

De vergelijking die telt is per apparaatklasse, niet per Android-versie: lijst de modellen in de fleet op, lees hun lanceer-API-niveaus en splits ze in apparaten die het profiel nog starten en apparaten die dat niet kunnen. Al het andere levert een supportbeleid op dat zichzelf tegenspreekt zodra een gebruiker een nieuwe telefoon koopt.

Pad twee: platform-IKEv2-profielen

Androids openbare provisioneringsmodel voor IKEv2 is een ander object, geen omgedoopt IKEv1-profiel. De platform-API voor IKEv2-profielen kwam met API 30 en verwacht IKEv2 met de authenticatiemethode die de gateway biedt, meestal op certificaat gebaseerd of EAP. Er is geen draadcompatibele upgrade van IKEv1 XAuth of Hybrid naar IKEv2: de gateway moet voor het nieuwe protocol worden geconfigureerd, en het profiel moet de bijpassende identiteit dragen.

Dit is het pad met de langste levensduur, en ook het pad dat het echte werk blootlegt. Identiteitsvalidatie, gebruikersauthenticatie, DNS, split-tunnelroutes en resourceautorisatie moeten allemaal de migratie overleven; alleen de handshake laten slagen laat gebruikers achter op een tunnel die niets bereikt.

Uitrol verloopt meestal via een MDM of beheerde configuratie, niet doordat een gebruiker velden intypt. Bestaat die infrastructuur nog niet, dan moet het migratieplan die bevatten, want een IKEv2-profiel handmatig op elk apparaat opnieuw invoeren is geen operatie die een helpdesk kan absorberen.

Pad drie: een clientapplicatie van een derde

Sommige VPN-apps leveren hun eigen protocolimplementatie en zijn helemaal niet afhankelijk van de oorspronkelijke legacystack. Dat maakt ze een legitieme noodoplossing voor een fleet die niet snel kan migreren, maar de compatibiliteitsvraag verschuift naar de app: of die precies de IKEv1-modus implementeert die je gateway spreekt, met de authenticatie en ciphersuites die de gateway vereist.

Beschouw de eigen ondersteuningsmatrix van de app als de autoriteit en niet de winkelbeschrijving, en test één echt apparaat tegen de echte gateway voordat je hem aanbeveelt. Een telefoon rooten om een verwijderd platformpad te herstellen is ook geen onderhouden oplossing; het verplaatst het probleem naar een niet-ondersteunde configuratie die de volgende systeemupdate stil kan breken.

Kies op basis van wat de gateway kan bieden

De beslissing vernauwt zodra je twee dingen weet: welke apparaten op of na API 31 zijn gelanceerd, en of de gateway een IKEv2-dienst kan presenteren met hetzelfde enrollmentmodel. Kan hij dat, migreer dan en stop met investeren in het legacy-profiel. Kan hij dat nog niet, houd IKEv1 voor de apparaten die het nog starten, en geef nieuwe apparaten een client van een derde als gedocumenteerde, tijdelijke uitzondering in plaats van een onuitgesproken omweg.

Twee punten maken het plan verdedigbaar. Ten eerste, leg de reden voor elke uitzondering vast met het model en het lanceerniveau, zodat een auditor kan zien dat de grens een platformbewaking is en geen onverklaarde voorkeur. Ten tweede, behandel de migratie als gepland werk: IKEv1 is verouderd volgens de standaardtracering (RFC 9395), wat betekent dat de resterende apparaten blijven krimpen en de uitzonderingen daarmee moeten aflopen.