Android 12 och IKEv1 VPN: lanseringsversion, IKEv2, tredjepartsappar

Två telefoner visar båda Android 12 i Inställningar, och bara en av dem startar fortfarande den gamla IPsec XAuth-profilen som din gateway erbjuder. Skillnaden är inte en inställning som användaren kan nå: skyddet som spärrar den inbyggda äldre IKEv1-vägen tittar på SDK-nivån enheten levererades med, inte bara versionen den kör nu. Den enda detaljen avgör om en jämförelse av flottan är meningsfull, och den avgör också vilken av tre migreringsvägar du faktiskt behöver.

Två Android 12-telefoner är inte samma testfall

Ändringen i AOSP som stoppade nya enheter från att starta ärvda IKEv1-profiler jämför DEVICE_INITIAL_SDK_INT med Android S, det vill säga API 31. I den inbyggda äldre startvägen ger en kvalificerande profil ett fel om åtgärden inte stöds innan det ens finns en användbar anslutning. En telefon som levererades med Android 11 och uppdaterades senare passerar fortfarande det skyddet; en modell som lanserades med Android 12 gör det inte.

De två talen kan läsas av på en enhet med felsökning aktiverad:

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

Det första värdet är lanseringsnivån som skyddet bryr sig om, det andra är vad telefonen kör i dag. Där egenskapen saknas, luta dig mot modellens supportdokumentation i stället för att gissa från marknadsföringsnamnet, och utgå inte från att ett leverantörsbygge bevarar varje kompatibilitetsväg som basversionen hade.

Ännu en skillnad sparar en timme bortkastad supporttid: en sparad profil som fortfarande listas i VPN-inställningarna bevisar ingenting om huruvida plattformen startar den. Att ange PSK igen eller redigera rutter tar inte bort en protokollkontroll som körs tidigare, och felet ser ut som ett inloggningsproblem när det inte är det.

Väg ett: behåll den inbyggda äldre stacken där den fortfarande fungerar

Den äldre stacken är den som läser IPsec XAuth PSK-, IPsec Hybrid RSA- och L2TP/IPsec PSK-profiler från systemets VPN-skärm. På en enhet som levererades under API 31 är den fortfarande en gångbar väg efter uppgraderingen, och därför kan en pilot på en äldre telefon lyckas medan en ny telefon misslyckas på samma profil.

Jämförelsen som spelar roll är per enhetsklass, inte per Android-version: lista modellerna i flottan, läs deras lanserings-API-nivåer och dela in dem i enheter som fortfarande startar profilen och enheter som inte kan. Allt annat ger en supportpolicy som motsäger sig själv i samma stund som en användare köper en ny telefon.

Väg två: plattformens IKEv2-profiler

Androids offentliga etableringsmodell för IKEv2 är ett annat objekt, inte en omdöpt IKEv1-profil. Plattforms-API:t för IKEv2-profiler kom med API 30 och förväntar sig IKEv2 med den autentiseringsmetod som gatewayen erbjuder, vanligen certifikatbaserad eller EAP. Det finns ingen trådkompatibel uppgradering från IKEv1 XAuth eller Hybrid till IKEv2: gatewayen måste konfigureras för det nya protokollet, och profilen måste bära den matchande identiteten.

Det här är vägen med längst livslängd, och också den som blottar det verkliga arbetet. Identitetsvalidering, användarautentisering, DNS, split-tunnel-rutter och resursauktorisering måste alla överleva migreringen; lyckas bara handskakningen sitter användarna kvar i en tunnel som inte når något.

Utrullning sker oftast via MDM eller hanterad konfiguration, inte genom att en användare skriver in fält. Finns inte den infrastrukturen ännu måste migreringsplanen omfatta den, för att ange en IKEv2-profil manuellt på varje enhet är inte en operation som en helpdesk kan absorbera.

Väg tre: en tredjepartsklientapp

Vissa VPN-appar levererar sin egen protokollimplementering och är inte beroende av den inbyggda äldre stacken alls. Det gör dem till en legitim tillfällig lösning för en flotta som inte kan migrera snabbt, men kompatibilitetsfrågan flyttar till appen: om den implementerar exakt det IKEv1-läge som din gateway talar, med den autentisering och de chiffersviter som gatewayen kräver.

Behandla appens egen supportmatris som auktoriteten och inte butiksbeskrivningen, och testa en verklig enhet mot den verkliga gatewayen innan du rekommenderar den. Att roota en telefon för att återställa en borttagen plattformsväg är inte heller en underhållen lösning; det flyttar problemet in i en konfiguration som inte stöds och som nästa systemuppdatering kan bryta tyst.

Välj utifrån vad gatewayen kan erbjuda

Beslutet snävas in när du vet två saker: vilka enheter som lanserades på eller efter API 31, och om gatewayen kan presentera en IKEv2-tjänst med samma registreringsmodell. Kan den det, migrera och sluta investera i den äldre profilen. Kan den inte ännu, behåll IKEv1 för de enheter som fortfarande startar den, och ge nya enheter en tredjepartsklient som ett dokumenterat, tidsbegränsat undantag i stället för en outtalad kringgång.

Två punkter gör planen försvarbar. För det första, registrera orsaken till varje undantag tillsammans med modell och lanseringsnivå, så att en revisor ser att gränsen är ett plattformsskydd och inte en oförklarad preferens. För det andra, behandla migreringen som planerat arbete: IKEv1 är utfasad enligt standardspåret (RFC 9395), vilket betyder att de kvarvarande enheterna fortsätter att krympa och undantagen bör löpa ut med dem.