Android 12 en IKEv1 VPN: leveringsferzje, IKEv2 en apps fan tredden

Twa telefoans litte beide Android 12 sjen yn Ynstellingen, en mar ien fan harren start noch it âlde IPsec XAuth-profyl dat jo gateway oanbiedt. It ferskil is gjin ynstelling dêr’t de brûker by komme kin: de wachter dy’t it native IKEv1-paad bestjoert, sjocht nei it SDK-nivo dêr’t it apparaat mei levere is, net allinnich nei de ferzje dy’t it no draait. Dat iene detail beslút oft in floatferliking sin hat, en it beslút ek hokker fan de trije migraasjepaden jo wier nedich hawwe.

Twa Android 12-telefoans binne net deselde test

De feroaring yn AOSP dy’t nije apparaten tsjinkearde om âlde IKEv1-profylen te starten, ferliket DEVICE_INITIAL_SDK_INT mei Android S, dat is API 31. Op it native startpaad jout in geskikt profyl in flater fan net-stipe bewerking foardat der ea in brûkbere ferbining is. In telefoan levere mei Android 11 en letter bywurke, passearret dy wachter noch; in model dat mei Android 12 kaam, net.

Jo kinne de twa sifers lêze op in apparaat mei debuggen oan:

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

De earste wearde is it leveringsnivo dêr’t de wachter nei sjocht, de twadde is wat de telefoan hjoed draait. Dêr’t it eigenskip mist, stypje jo op de stypdokumintaasje fan it model ynstee fan te rieden út de marketingnamme, en nim net oan dat de build fan de fabrikant alle kompatibiliteitspaden fan de basisferzje behâldt.

Noch ien ûnderskie sparret in oere ferlerne styp tiid: in bewarre profyl dat noch yn de VPN-ynstellingen stiet, bewiist neat oer oft it platfoarm it start. De PSK op’nij ynfiere of rûtes bewurkje kin gjin protokolstypkontrôle dy’t earder rint, fuorthelje, en de flater liket in oanmeldprobleem, wylst it dat net is.

Paad ien: hâld de âlde stack dêr’t er noch rint

De âlde stack is dejinge dy’t IPsec XAuth PSK, IPsec Hybrid RSA en L2TP/IPsec PSK-profylen fan it systeem-VPN-skerm lêst. Op in apparaat levere ûnder API 31 bliuwt it nei in bywurking in wurkber paad, dêrom kin in proef op in âlder tastel slagje wylst in nij tastel itselde profyl net start.

De ferliking dy’t telt is per apparaatklasse, net per Android-ferzje: list de modellen yn de float op, lês harren leverings-API-nivoos en diel se yn apparaten dy’t it profyl noch starte en apparaten dy’t it net kinne. Al it oare jout in stypbelied dat himsels tsjinsprekt op it stuit dat in brûker in nije telefoan keapet.

Paad twa: IKEv2-profylen fan it platfoarm

It iepenbiere foarsjenningmodel fan Android foar IKEv2 is in oar objekt, net in omneamd IKEv1-profyl. De platfoarm-API foar IKEv2-profylen kaam mei API 30 en ferwachtet IKEv2 mei de autentikaasjemetoade dy’t de gateway oanbiedt, meast op basis fan sertifikaat of EAP. Der is gjin triedkompatibele fernijing fan IKEv1 XAuth of Hybrid nei IKEv2: de gateway moat foar it nije protokol konfigurearre wurde en it profyl moat de byhearrende identiteit drage.

Dat is it paad mei it langste libben, en ek datjinge dat it echte wurk sjen lit. Identiteitsfalidaasje, brûkersautentikaasje, DNS, rûtes fan split-tunnel en autorisaasje fan boarnen moatte allegear de migraasje oerlibje; allinnich de hânskudding slagje litte lit brûkers ferbûn oan in tunnel dy’t nearne komt.

De útrulling giet meast fia MDM of in beheard konfiguraasje ynstee fan dat de brûker fjilden typt. As dy ynfrastruktuer der noch net is, moat it migraasjeplan dy opnimme, want in IKEv2-profyl mei de hân op elk apparaat op’nij ynfiere is gjin operaasje dy’t in helpdesk opslokke kin.

Paad trije: in klantapp fan tredden

Guon VPN-apps leverje har eigen protokolymplemintaasje en binne hielendal net ôfhinklik fan de native stack. Dat makket se in legitim tydlik oplossing foar in float dy’t net fluch migrearje kin, mar de kompatibiliteitsfraach ferhúzet nei de app: oft dy krekt de IKEv1-modus ymplemintearret dy’t jo gateway praat, mei de autentikaasje en de sifersuites dy’t de gateway freget.

Nim de stypmatrix fan de app as autoriteit, net de beskriuwing yn de winkel, en test ien echt apparaat tsjin de echte gateway foardat jo it oanriede. In telefoan roote om in fuorthelle platfoarmpaad werom te heljen is ek gjin ûnderhâlden oplossing; it ferpleatst it probleem nei in net-stipe konfiguraasje dy’t de folgjende systeemfernijing stil brekke kin.

Kies nei wat de gateway biede kin

It beslút fersmalt as jo twa dingen witte: hokker apparaten mei API 31 of letter kamen, en oft de gateway in IKEv2-tsjinst biede kin mei itselde ynskriuwmodel. As it kin, migrearje en stop mei ynvestearjen yn it âlde profyl. As it noch net kin, hâld IKEv1 foar de apparaten dy’t it noch starte, en jou nije apparaten in klant fan tredden as in dokumintearre, tiidbeheinde útsûndering, net as in ûnútsprutsen omwei.

Twa punten meitsje it plan ferdigenber. Earst, skriuw de reden fan elke útsûndering op mei it model en it leveringsnivo, sadat in auditor sjocht dat de grins in platfoarmwachter is en net in net-ferklearre foarkar. Twadde, behannelje de migraasje as pland wurk: IKEv1 is ferâldere op it standertpaad (RFC 9395), wat betsjut dat de oerbleaune apparaten trochgeane mei krimpen en de útsûnderingen dêrmei einigje moatte.