Android 12 og IKEv1 VPN: lanseringsversjon, IKEv2, tredjepartsapper

To telefoner viser begge Android 12 i Innstillinger, og bare én av dem starter fortsatt den gamle IPsec XAuth-profilen gatewayen din tilbyr. Forskjellen er ikke en innstilling brukeren kan nå: vakten som styrer den opprinnelige arvebanen for IKEv1 ser på SDK-nivået enheten ble levert med, ikke bare utgivelsen den kjører nå. Den ene detaljen avgjør om en flåtesammenligning er meningsfull, og den avgjør også hvilken av tre migreringsbaner du faktisk trenger.

To Android 12-telefoner er ikke samme testtilfelle

AOSP-endringen som hindret nye enheter i å starte arvede IKEv1-profiler, sammenligner DEVICE_INITIAL_SDK_INT med Android S, som er API 31. I den opprinnelige arvebanen for oppstart gir en kvalifiserende profil en feil om ikke-støttet operasjon før noen nyttig tilkobling finnes. En telefon levert med Android 11 og senere oppdatert passerer fortsatt den vakten; en modell lansert med Android 12 gjør det ikke.

Du kan lese de to tallene på en enhet med feilsøking aktivert:

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 verdien er lanseringsnivået vakten bryr seg om, den andre er det telefonen kjører i dag. Der egenskapen mangler, støtt deg på modellens støttedokumentasjon i stedet for å gjette fra markedsføringsnavnet, og ikke anta at en leverandørbygg bevarer hver kompatibilitetsbane basisutgivelsen hadde.

Nok en forskjell sparer en time bortkastet støttetid: en lagret profil som fortsatt står i VPN-innstillingene, beviser ingenting om hvorvidt plattformen vil starte den. Å legge inn PSK på nytt eller redigere ruter kan ikke fjerne en protokollstøttekontroll som kjører tidligere, og feilen ser ut som et legitimasjonsproblem når den ikke er det.

Bane én: behold den opprinnelige arvestakken der den fortsatt kjører

Arvestakken er den som leser IPsec XAuth PSK, IPsec Hybrid RSA og L2TP/IPsec PSK-profiler fra systemets VPN-skjerm. På en enhet levert under API 31 forblir den en levedyktig bane etter oppgradering, og derfor kan en pilot på en eldre telefon lykkes mens en ny telefon feiler på samme profil.

Sammenligningen som betyr noe, er per enhetsklasse, ikke per Android-versjon: list modellene i flåten, les lanserings-API-nivåene deres, og del dem i enheter som fortsatt starter profilen og enheter som ikke kan. Alt annet gir en støttepolicy som motsier seg selv i det øyeblikket en bruker kjøper en ny telefon.

Bane to: plattformens IKEv2-profiler

Androids offentlige provisjoneringsmodell for IKEv2 er et annet objekt, ikke en omdøpt IKEv1-profil. Plattform-API-et for IKEv2-profiler kom med API 30 og forventer IKEv2 med autentiseringsmetoden gatewayen tilbyr, vanligvis sertifikatbasert eller EAP. Det finnes ingen trådkompatibel oppgradering fra IKEv1 XAuth eller Hybrid til IKEv2: gatewayen må konfigureres for den nye protokollen, og profilen må bære den samsvarende identiteten.

Dette er banen med lengst levetid, og også den som avslører det virkelige arbeidet. Identitetsvalidering, brukerautentisering, DNS, split-tunnel-ruter og ressursautorisasjon må alle overleve migreringen; lykkes bare håndtrykket, blir brukerne sittende i en tunnel som ikke når noe.

Utrulling skjer vanligvis via MDM eller administrert konfigurasjon, ikke ved at en bruker skriver inn felt. Finnes ikke den infrastrukturen ennå, må migreringsplanen omfatte den, fordi å legge inn en IKEv2-profil manuelt på hver enhet ikke er en operasjon en brukerstøtte kan absorbere.

Bane tre: en tredjepartsklientapp

Noen VPN-apper leverer sin egen protokollimplementasjon og er ikke avhengige av den opprinnelige arvestakken i det hele tatt. Det gjør dem til en legitim mellomløsning for en flåte som ikke kan migrere raskt, men kompatibilitetsspørsmålet flytter seg til appen: om den implementerer nøyaktig den IKEv1-modusen gatewayen din snakker, med autentiseringen og chifferssettene gatewayen krever.

Behandle appens egen støttematrise som autoriteten og ikke butikkbeskrivelsen, og test én reell enhet mot den reelle gatewayen før du anbefaler den. Å roote en telefon for å gjenopprette en fjernet plattformbane er heller ikke en vedlikeholdt løsning; det flytter problemet inn i en konfigurasjon som ikke støttes og som neste systemoppdatering kan bryte stille.

Velg ut fra hva gatewayen kan tilby

Beslutningen snevres inn når du vet to ting: hvilke enheter som ble lansert på eller etter API 31, og om gatewayen kan presentere en IKEv2-tjeneste med samme registreringsmodell. Kan den det, migrer og slutt å investere i arveprofilen. Kan den ikke ennå, behold IKEv1 for enhetene som fortsatt starter den, og gi nye enheter en tredjepartsklient som et dokumentert, tidsbegrenset unntak i stedet for en uuttalt omvei.

To punkter gjør planen forsvarlig. For det første, registrer årsaken til hvert unntak med modell og lanseringsnivå, slik at en revisor kan se at grensen er en plattformvakt og ikke en uforklart preferanse. For det andre, behandle migreringen som planlagt arbeid: IKEv1 er avviklet i standardsporet (RFC 9395), som betyr at de gjenværende enhetene vil fortsette å krympe og unntakene bør utløpe med dem.