Android 12 og IKEv1 VPN: útgáfan við afhendingu, IKEv2 og forrit þriðja aðila

Tveir símar sýna báðir Android 12 í Stillingum, og aðeins annar þeirra ræsir enn gamla IPsec XAuth sniðið sem hliðið þitt býður. Munurinn er ekki stilling sem notandinn kemst að: vörðurinn sem stýrir innbyggðu IKEv1 leiðinni horfir á SDK-stigið sem tækið var afhent með, ekki bara útgáfuna sem það keyrir núna. Þetta eina smáatriði ræður því hvort samanburður á flota hefur merkingu, og hann ræður líka hvorri af þremur flutningsleiðum þú þarft í raun.

Tveir Android 12 símar eru ekki sama prófunartilfellið

Breytingin í AOSP sem stöðvaði ný tæki frá því að ræsa gömul IKEv1 snið ber DEVICE_INITIAL_SDK_INT saman við Android S, sem er API 31. Á innbyggðu ræsingarleiðinni veldur hæfu sniði bilun um óstudda aðgerð áður en nokkur nytsamleg tenging er til. Sími sem var afhentur með Android 11 og uppfærður síðar fer enn í gegnum þennan vörð; módel sem kom með Android 12 gerir það ekki.

Þú getur lesið tölurnar tvær á tæki með aflúsun virka:

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

Fyrra gildið er afhendingarstigið sem varðinum er umhugað um, það síðara er það sem síminn keyrir í dag. Þar sem eiginleikinn vantar skal styðjast við stuðningsskjöl módelins í stað þess að giska út frá markaðsheitinu, og ekki gera ráð fyrir að bygging framleiðandans varðveiti allar samhæfnisleiðir grunnútgáfunnar.

Ein aðgreining til viðbótar sparar klukkustund af sóuðum stuðningstíma: vistað snið sem er enn á listanum í VPN-stillingum sannar ekkert um hvort kerfið muni ræsa það. Að slá PSK inn aftur eða breyta leiðum getur ekki fjarlægt stuðningsprófun samskiptareglu sem keyrir fyrr, og bilunin lítur út eins og vandamál með skírteini þegar það er það ekki.

Leið eitt: halda innbyggða staflinum þar sem hann gengur enn

Gamli staflinn er sá sem les IPsec XAuth PSK, IPsec Hybrid RSA og L2TP/IPsec PSK snið frá VPN-skjánum kerfisins. Á tæki sem var afhent undir API 31 helst hann fær leið eftir uppfærslu, þess vegna getur tilraun á eldri síma heppnast á meðan nýr sími ræsir ekki sama snið.

Samanburðurinn sem skiptir máli er eftir tækjaflokki, ekki eftir Android-útgáfu: skráið módelin í flotanum, lesið afhendingar-API-stig þeirra og skiptið þeim í tæki sem ræsa sniðið enn og tæki sem geta það ekki. Allt annað framleiðir stuðningsstefnu sem segir sjálfri sér mótsögn á þeirri stundu sem notandi kaupir nýjan síma.

Leið tvö: IKEv2 snið kerfisins

Opinbera veitulíkan Android fyrir IKEv2 er annar hlutur, ekki endurnefnt IKEv1 snið. API kerfisins fyrir IKEv2 snið kom með API 30 og væntir IKEv2 með þeirri auðkenningaraðferð sem hliðið býður, venjulega byggðri á skírteini eða EAP. Engin snúru-samhæf uppfærsla er frá IKEv1 XAuth eða Hybrid yfir í IKEv2: stilla þarf hliðið fyrir nýju samskiptaregluna og sniðið verður að bera samsvarandi auðkenni.

Þetta er leiðin með lengsta líftíma, og líka sú sem afhjúpar raunverulegu vinnuna. Auðkenning auðkennis, auðkenning notanda, DNS, leiðir í klofnu tunli og heimild fyrir auðlindir verða öll að standast flutninginn; að láta aðeins handabandið heppnast skilur notendur eftir tengda við tunil sem nær hvergi.

Útfelling fer venjulega í gegnum MDM eða stýrða uppsetningu í stað þess að notandinn skrifi reiti. Ef sá grunnur er ekki til enn verður flutningsáætlunin að innihalda hann, því að slá IKEv2 sniði handvirkt inn á hvert tæki er ekki aðgerð sem stuðningsborð getur melt.

Leið þrjú: biðlaraforrit þriðja aðila

Sum VPN forrit koma með eigin útfærslu samskiptareglunnar og eru alls ekki háð innbyggða staflinum. Það gerir þau að lögmætri bráðabirgðalausn fyrir flota sem getur ekki flutt sig hratt, en samhæfisspurningurinn flyst til forritsins: hvort það útfæri nákvæmlega það IKEv1 ham sem hliðið þitt talar, með þeirri auðkenningu og þeim dulritunarsettum sem hliðið krefst.

Lítið á stuðningsfylki forritsins sjálfs sem valdið, ekki lýsinguna í versluninni, og prófið eitt raunverulegt tæki gegn raunverulegu hliði áður en þið mælið með því. Að róta síma til að endurheimta fjarlægða kerfisleið er heldur ekki viðhaldið lausn; það flytur vandamálið í óstudda uppsetningu sem næsta kerfisuppfærsla getur brotið hljóðlega.

Veljið eftir því sem hliðið getur boðið

Ákvörðunin þrengist þegar þú veist tvennt: hvaða tæki komu með API 31 eða síðar, og hvort hliðið getur boðið IKEv2 þjónustu með sama skráningarlíkani. Ef það getur, flyttu og hættu að fjárfesta í gamla sniðinu. Ef það getur ekki enn, haltu IKEv1 fyrir tækin sem ræsa það enn, og gefðu nýjum tækjum biðlara þriðja aðila sem skjalfesta, tímatakmarkaða undantekningu, ekki sem ósagða krókaleið.

Tvennt gerir áætlunina verjanlega. Í fyrsta lagi skráið ástæðu hverrar undantekningar ásamt módelinu og afhendingarstiginu, svo endurskoðandi sjái að mörkin eru kerfisvörður en ekki óútskýrður áhugi. Í öðru lagi meðhöndlið flutninginn sem skipulagt verk: IKEv1 er úrelt á staðlarleiðinni (RFC 9395), sem þýðir að tækin sem eftir eru munu halda áfram að fækka og undantekningarnar ættu að renna út með þeim.