Android 12 og IKEv1 VPN: versionsniveau ved levering, IKEv2 og tredjepartsapps

To telefoner viser begge Android 12 i Indstillinger, og kun den ene starter stadig den gamle IPsec XAuth-profil, som din gateway tilbyder. Forskellen er ikke en indstilling, brugeren kan nå: den vagt, der styrer den native IKEv1-vej, ser på det SDK-niveau, enheden blev leveret med, ikke kun den version, den kører nu. Den ene detalje afgør, om en flådesammenligning giver mening, og den afgør også, hvilken af tre migreringsveje du faktisk har brug for.

To telefoner med Android 12 er ikke samme testtilfælde

Ændringen i AOSP, der stoppede nye enheder fra at starte gamle IKEv1-profiler, sammenligner DEVICE_INITIAL_SDK_INT med Android S, som er API 31. På den native opstartsvej udløser en kvalificerende profil en fejl om ikke-understøttet handling, før der overhovedet findes en brugbar forbindelse. En telefon leveret med Android 11 og senere opdateret passerer stadig den vagt; en model, der startede med Android 12, gør ikke.

Du kan læse de to tal på en enhed med fejlfinding slået til:

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

Den første værdi er det leveringsniveau, vagten interesserer sig for, den anden er det, telefonen kører i dag. Hvor egenskaben mangler, skal du støtte dig på modellens supportdokumentation i stedet for at gætte ud fra marketingnavnet, og ikke antage, at producentens build bevarer alle kompatibilitetsveje fra basisversionen.

Én mere skelnen sparer en time spildt supporttid: en gemt profil, der stadig står i VPN-indstillingerne, beviser intet om, hvorvidt platformen vil starte den. At indtaste PSK igen eller redigere ruter kan ikke fjerne et protokolstøtjetjek, der kører tidligere, og fejlen ligner et legitimationsproblem, når den ikke er det.

Vej et: behold den native stak, hvor den stadig kører

Den gamle stak er den, der læser IPsec XAuth PSK, IPsec Hybrid RSA og L2TP/IPsec PSK-profiler fra systemets VPN-skærm. På en enhed leveret under API 31 forbliver den en brugbar vej efter en opgradering, og derfor kan en pilot på en ældre telefon lykkes, mens en ny telefon ikke kan starte samme profil.

Den sammenligning, der betyder noget, er pr. enhedsklasse, ikke pr. Android-version: list modellerne i flåden, læs deres API-niveauer ved levering, og del dem i enheder, der stadig starter profilen, og enheder, der ikke kan. Alt andet giver en supportpolitik, der modsiger sig selv i det øjeblik, en bruger køber en ny telefon.

Vej to: platformens IKEv2-profiler

Androids offentlige provisioningmodel for IKEv2 er et andet objekt, ikke en omdøbt IKEv1-profil. Platformens API til IKEv2-profiler kom med API 30 og forventer IKEv2 med den godkendelsesmetode, gatewayen tilbyder, normalt certifikatbaseret eller EAP. Der er ingen trådkompatibel opgradering fra IKEv1 XAuth eller Hybrid til IKEv2: gatewayen skal konfigureres til den nye protokol, og profilen skal bære den matchende identitet.

Det er vejen med det længste liv og også den, der afslører det egentlige arbejde. Identitetsvalidering, brugergodkendelse, DNS, split-tunnel-ruter og ressourceautorisation skal alle overleve migreringen; at få kun håndtrykket til at lykkes efterlader brugerne på en tunnel, der ikke når noget.

Udrulning går normalt gennem MDM eller en administreret konfiguration i stedet for at brugeren skriver felter. Hvis den infrastruktur ikke findes endnu, skal migreringsplanen omfatte den, fordi at indtaste en IKEv2-profil manuelt på hver enhed ikke er en operation, en helpdesk kan absorbere.

Vej tre: en klientapp fra tredjepart

Nogle VPN-apps leverer deres egen protokolimplementering og afhænger slet ikke af den native stak. Det gør dem til en legitim midlertidig løsning for en flåde, der ikke kan migrere hurtigt, men kompatibilitetsspørgsmålet flytter til appen: om den implementerer præcis den IKEv1-tilstand, din gateway taler, med den godkendelse og de cipher suites, gatewayen kræver.

Behandl appens egen supportmatrix som autoriteten i stedet for butiksbeskrivelsen, og test en rigtig enhed mod den rigtige gateway, før du anbefaler den. At roote en telefon for at gendanne en fjernet platformsvej er heller ikke en vedligeholdt løsning; det flytter problemet til en ikke-understøttet konfiguration, som den næste systemopdatering kan bryde lydløst.

Vælg efter, hvad gatewayen kan tilbyde

Beslutningen indsnævres, når du ved to ting: hvilke enheder der blev lanceret på eller efter API 31, og om gatewayen kan tilbyde en IKEv2-tjeneste med samme tilmeldingsmodel. Hvis den kan, migrer, og stop med at investere i den gamle profil. Hvis den ikke kan endnu, behold IKEv1 til de enheder, der stadig starter den, og giv nye enheder en tredjepartsklient som en dokumenteret, tidsbegrænset undtagelse i stedet for en usagt omvej.

To ting gør planen forsvarlig. For det første, registrer årsagen til hver undtagelse sammen med model og leveringsniveau, så en revisor kan se, at grænsen er en platformsvagt og ikke en uforklaret præference. For det andet, behandl migreringen som planlagt arbejde: IKEv1 er forældet på standardsporet (RFC 9395), hvilket betyder, at de resterende enheder vil fortsætte med at skrumpe, og undtagelserne bør udløbe med dem.