Android 12 og IKEv1 VPN: lanseringsversjon, IKEv2, tredjepartsappar

To telefonar viser begge Android 12 i Innstillingar, og berre éin av dei startar framleis den gamle IPsec XAuth-profilen gatewayen din tilbyr. Skilnaden er ikkje ei innstilling brukaren kan nå: vakta som styrer den opphavlege arvebanen for IKEv1 ser på SDK-nivået eininga vart levert med, ikkje berre utgåva ho køyrer no. Den eine detaljen avgjer om ein flåtesamanlikn er meiningsfull, og han avgjer òg kva av tre migreringsbaner du faktisk treng.

To Android 12-telefonar er ikkje same testtilfelle

AOSP-endringa som hindra nye einingar i å starte arva IKEv1-profilar, samanliknar DEVICE_INITIAL_SDK_INT med Android S, som er API 31. I den opphavlege arvebanen for oppstart gir ein kvalifiserande profil ein feil om ikkje-støtta operasjon før noka nyttig tilkopling finst. Ein telefon levert med Android 11 og seinare oppdatert passerer framleis den vakta; ein modell lansert med Android 12 gjer det ikkje.

Du kan lese dei to tala på ei eining med feilsøking slått på:

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 vakta bryr seg om, den andre er det telefonen køyrer i dag. Der eigenskapen manglar, støtt deg på støttedokumentasjonen til modellen i staden for å gjette frå marknadsføringsnamnet, og ikkje gå ut frå at ein leverandørbygg bevarer kvar kompatibilitetsbane grunnutgåva hadde.

Endå ein skilnad sparar ein time bortkasta støttetid: ein lagra profil som framleis står i VPN-innstillingane, beviser ingenting om plattforma vil starte han. Å leggje inn PSK på nytt eller redigere ruter kan ikkje fjerne ein protokollstøttekontroll som køyrer tidlegare, og feilen ser ut som eit legitimasjonsproblem når han ikkje er det.

Bane éin: hald den opphavlege arvestakken der han framleis køyrer

Arvestakken er den som les IPsec XAuth PSK, IPsec Hybrid RSA og L2TP/IPsec PSK-profilar frå VPN-skjermen i systemet. På ei eining levert under API 31 blir han verande ein levedyktig bane etter oppgradering, og difor kan ein pilot på ein eldre telefon lukkast medan ein ny telefon feilar på same profil.

Samanlikninga som tel, er per einingklasse, ikkje per Android-versjon: list modellane i flåten, les lanserings-API-nivåa deira, og del dei i einingar som framleis startar profilen og einingar som ikkje kan. Alt anna gir ein støttepolicy som seier imot seg sjølv i det augeblikket ein brukar kjøper ein ny telefon.

Bane to: plattforma sine IKEv2-profilar

Androids offentlege provisjoneringsmodell for IKEv2 er eit anna objekt, ikkje ein omdøypt IKEv1-profil. Plattform-API-et for IKEv2-profilar kom med API 30 og ventar IKEv2 med autentiseringsmetoden gatewayen tilbyr, vanlegvis sertifikatbasert eller EAP. Det finst inga trådkompatibel oppgradering frå IKEv1 XAuth eller Hybrid til IKEv2: gatewayen må konfigurerast for den nye protokollen, og profilen må bere den samsvarande identiteten.

Dette er banen med lengst levetid, og òg den som avdekkjer det verkelege arbeidet. Identitetsvalidering, brukarautentisering, DNS, split-tunnel-ruter og ressursautorisasjon må alle overleve migreringa; lukkast berre handtrykket, blir brukarane sitjande i ein tunnel som ikkje når noko.

Utrulling skjer vanlegvis via MDM eller styrt konfigurasjon, ikkje ved at ein brukar skriv inn felt. Finst ikkje den infrastrukturen enno, må migreringsplanen omfatte han, fordi å leggje inn ein IKEv2-profil manuelt på kvar eining ikkje er ein operasjon ein brukarstøtte kan svelgje.

Bane tre: ein tredjepartsklientapp

Nokre VPN-appar leverer si eiga protokollimplementering og er ikkje avhengige av den opphavlege arvestakken i det heile. Det gjer dei til ei legitim mellomløysing for ein flåte som ikkje kan migrere raskt, men kompatibilitetsspørsmålet flyttar seg til appen: om han implementerer nøyaktig den IKEv1-modusen gatewayen din snakkar, med autentiseringa og chiffersetta gatewayen krev.

Behandle støttematrisa til appen som autoriteten og ikkje butikkbeskrivinga, og test éi reell eining mot den reelle gatewayen før du tilrår han. Å roote ein telefon for å gjenopprette ein fjerna plattformbane er heller ikkje ei vedlikehalden løysing; det flyttar problemet inn i ein konfigurasjon som ikkje er støtta og som neste systemoppdatering kan bryte stille.

Vel ut frå kva gatewayen kan tilby

Avgjerda blir trongare når du veit to ting: kva einingar som vart lanserte på eller etter API 31, og om gatewayen kan presentere ei IKEv2-teneste med same registreringsmodell. Kan han det, migrer og slutt å investere i arveprofilen. Kan han det ikkje enno, hald IKEv1 for einingane som framleis startar han, og gi nye einingar ein tredjepartsklient som eit dokumentert, tidsavgrensa unntak i staden for ein usagd omveg.

To punkt gjer planen forsvarlig. For det første, før opp årsaka til kvart unntak med modell og lanseringsnivå, slik at ein revisor kan sjå at grensa er ei plattformvakt og ikkje ei uforklart preferanse. For det andre, behandl migreringa som planlagt arbeid: IKEv1 er avvikla i standardsporet (RFC 9395), som tyder at dei gjenverande einingane vil halde fram med å krympe og unntaka bør gå ut saman med dei.