Android 12 og IKEv1 VPN: lanseringsnivå, IKEv2 og apper fra tredjeparter

Begge telefonene oppgir Android 12 i Innstillinger, men bare den ene starter fortsatt den gamle IPsec XAuth-profilen som gatewayen tilbyr. Forskjellen ligger ikke i en innstilling brukeren kommer til: kontrollen som sperrer den innebygde arvebanen for IKEv1, ser på SDK-nivået enheten ble levert med og ikke bare versjonen den kjører i dag. Nettopp dette avgjør om en sammenligning på tvers av enhetsflåten er noe verdt, og det avgjør også hvilken av tre veier til migrering du trenger.

To telefoner med Android 12 er ikke samme test

Endringen i AOSP som stanset nye enheter fra å starte arvede IKEv1-profiler, sammenligner DEVICE_INITIAL_SDK_INT med Android S, altså API 31. I den innebygde arvebanen gir en profil som kvalifiserer, en feil om at operasjonen ikke støttes før det finnes en brukbar tilkobling. En telefon som ble levert med Android 11 og oppdatert senere, slipper fortsatt gjennom; en modell som kom med Android 12, gjør det ikke.

Begge tallene kan leses av på en enhet med feilsøking på:

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

Det første tallet er lanseringsnivået kontrollen bryr seg om, det andre er det telefonen kjører i dag. Mangler egenskapen, hold deg til støttedokumentasjonen for modellen i stedet for å gjette ut fra markedsnavnet, og ikke regn med at en leverandørversjon beholder alle kompatibilitetsveiene grunnversjonen hadde.

En ting til sparer en time med bortkastet brukerstøtte: en lagret profil som fortsatt står i VPN-innstillingene, sier ingenting om plattformen vil starte den. Å taste PSK på nytt eller endre ruter fjerner ikke en protokollkontroll som ligger tidligere i løpet, og feilen ser ut som et legitimasjonsproblem uten å være det.

Veien videre, del én: behold den innebygde arvestakken der den virker

Arvestakken er den som leser IPsec XAuth PSK, IPsec Hybrid RSA og L2TP/IPsec PSK fra VPN-skjermen i systemet. På en enhet levert med API-nivå under 31 er den fortsatt en farbar vei etter oppgradering, og derfor kan en prøve på en eldre telefon lykkes mens en ny telefon feiler på samme profil.

Den sammenligningen som nytter, går på enhetsklasse og ikke på Android-versjon: før opp modellene i flåten, les lanseringsnivåene deres og del dem i enheter som fortsatt starter profilen, og enheter som ikke kan. Alt annet gir en støttepraksis som motsier seg selv straks noen kjøper ny telefon.

Veien videre, del to: IKEv2-profiler fra plattformen

Androids åpne provisjoneringsmodell for IKEv2 er et annet objekt, ikke en IKEv1-profil med nytt navn. Plattform-API-et for IKEv2-profiler kom med API 30 og forutsetter IKEv2 med den autentiseringen gatewayen tilbyr, som regel sertifikat eller EAP. Det finnes ingen overgang fra IKEv1 XAuth eller Hybrid til IKEv2 som virker på trådnivå: gatewayen må settes opp for den nye protokollen, og profilen må ha den identiteten som hører til.

Dette er veien med lengst levetid, og samtidig den som viser hvor arbeidet faktisk ligger. Identitetskontroll, brukerautentisering, DNS, ruter for delt tunnel og autorisasjon av ressurser må alle tåle migreringen; lykkes bare håndtrykket, sitter brukerne igjen med en tunnel som ikke når fram til noe.

Utrulling skjer som regel via MDM eller styrt oppsett, ikke ved at brukeren fyller ut felt. Finnes ikke den infrastrukturen ennå, må planen omfatte den, for å legge inn en IKEv2-profil for hånd på hver enhet er ikke noe en brukerstøtte kan ta unna.

Veien videre, del tre: en klientapp fra tredjepart

Noen VPN-apper har sin egen protokollimplementasjon og er ikke avhengige av den innebygde arvestakken i det hele tatt. Det gjør dem til en brukbar mellomløsning for en flåte som ikke rekker å migrere, men spørsmålet om kompatibilitet flytter seg til appen: om den faktisk implementerer den IKEv1-varianten gatewayen din bruker, med den autentiseringen og de chiffersuiteene gatewayen krever.

La støttematrisen til appen selv være fasiten, ikke butikkteksten, og prøv én virkelig enhet mot den virkelige gatewayen før du anbefaler den. Å roote telefonen for å hente tilbake en fjernet plattformvei er heller ikke en løsning som vedlikeholdes; det flytter problemet over i et oppsett uten støtte som neste systemoppdatering kan ødelegge uten varsel.

Velg etter hva gatewayen kan tilby

Valget blir enklere når du vet to ting: hvilke enheter som kom med API 31 eller senere, og om gatewayen kan tilby IKEv2 med samme modell for registrering. Kan den det, migrer og slutt å bruke krefter på arveprofilen. Kan den ikke ennå, behold IKEv1 for enhetene som fortsatt starter den, og gi nye enheter en klient fra tredjepart som et dokumentert unntak med sluttdato, ikke som en uskreven omvei.

To grep gjør planen forsvarlig. For det første: skriv ned grunnen til hvert unntak sammen med modell og lanseringsnivå, slik at en revisor ser at grensen går ved en plattformkontroll og ikke ved en smakssak. For det andre: regn migreringen som planlagt arbeid, for IKEv1 er avviklet i standardsporet (RFC 9395), og det betyr at de gjenværende enhetene blir færre og unntakene bør falle bort sammen med dem.