Android 12 eta IKEv1 VPN: abiarazteko bertsioa, IKEv2 eta hirugarrenen aplikazioak

Bi telefonok Android 12 erakusten dute Ezarpenetan, eta horietako batek soilik abiarazten du zure atebideak eskaintzen duen IPsec XAuth profil zaharra. Aldea ez da erabiltzaileak irits dezakeen ezarpen bat: IKEv1 bide natiboa kontrolatzen duen zaintzaileak gailua zein SDK mailarekin bidali zen hartzen du kontuan, orain exekutatzen duen bertsioa soilik ez. Xehetasun bakar horrek erabakitzen du flota alderaketa batek zentzurik duen, eta hiru migrazio bideetatik zein behar duzun ere bai.

Bi Android 12 telefono ez dira proba kasu bera

Gailu berriek IKEv1 profil zaharrak abiaraztea eragotzi zuen AOSP aldaketak DEVICE_INITIAL_SDK_INT Android S-rekin alderatzen du, hau da, API 31. Abiarazte bide natiboan, profil egokiak eragiketa onartugabe baten hutsegitea sortzen du konexio erabilgarririk egon aurretik. Android 11-rekin bidalitako eta gero eguneratutako telefonok zaintzaile hori gainditzen du oraindik; Android 12-rekin abiarazi zen modeloak ez.

Bi zenbakiak arazketa gaituta duen gailu batean irakur ditzakezu:

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

Lehen balioa zaintzaileari axola zaion abiarazte maila da, bigarrena telefonoak gaur exekutatzen duena. Propietatea falta denean, modeloaren laguntza dokumentazioan oinarritu merkataritza izenetik asmatu beharrean, eta ez pentsatu fabrikatzailearen eraikuntzak oinarrizko bertsioaren bateragarritasun bide guztiak gordetzen dituenik.

Beste bereizketa batek ordu bat laguntza denbora galduta aurrezten du: VPN ezarpenetan oraindik zerrendatuta dagoen profil gordeak ez du ezer frogatzen plataformak abiaraziko duen ala ez. PSK berriro sartzeak edo ibilbideak editatzeak ezin du lehenago exekutatzen den protokolo laguntza egiaztapen bat kendu, eta hutsegitea kredentzialen arazoa dirudi, ez denean.

Bat bidea: mantendu stak zaharra oraindik dabilen tokian

Stak zaharra sistema VPN pantailatik IPsec XAuth PSK, IPsec Hybrid RSA eta L2TP/IPsec PSK profilak irakurtzen dituena da. API 31 azpitik bidalitako gailuan eguneraketaren ondoren bide bideragarria izaten jarraitzen du, horregatik proba bat telefono zahar batean arrakastatsua izan daiteke telefono berri batek profil bera abiarazten ez duen bitartean.

Garrantzizko alderaketa gailu klasearen araberakoa da, ez Android bertsioaren araberakoa: zerrendatu flotako modeloak, irakurri haien abiarazte API mailak eta banatu profila oraindik abiarazten duten gailuen eta ezin dutenen artean. Beste edozein gauzak erabiltzaileak telefono berria erosten duen unean bere buruari kontraesaten dion laguntza politika sortzen du.

Bi bidea: plataformako IKEv2 profilak

Androiden IKEv2-rako hornikuntza eredu publikoa beste objektu bat da, ez IKEv1 profil berrizendatua. IKEv2 profiletarako plataforma APIa API 30ekin iritsi zen eta atebideak eskaintzen duen autentifikazio metodoarekin IKEv2 espero du, normalean ziurtagirian oinarritua edo EAP. Ez dago kablez bateragarria den berritzerik IKEv1 XAuth edo Hybrid-etik IKEv2-ra: atebidea protokolo berrirako konfiguratu behar da, eta profilak dagokion identitatea eraman behar du.

Bizitza luzeena duen bidea da, eta lan erreala agerian uzten duena ere bai. Identitatearen baliozkotzea, erabiltzailearen autentifikazioa, DNSa, tunel zatituaren ibilbideak eta baliabideen baimena migrazioak gainditu behar ditu; esku-ematea soilik lortzeak erabiltzaileak inora iristen ez den tunel batera konektatuta uzten ditu.

Hedapena normalean MDM edo kudeatutako konfigurazio baten bidez egiten da, erabiltzaileak eremuak idazten dituen ordez. Azpiegitura hori oraindik existitzen ez bada, migrazio planak sartu behar du, IKEv2 profila gailu bakoitzean eskuz berriro sartzea ez baita laguntza zerbitzu batek xurga dezakeen eragiketa.

Hiru bidea: hirugarrenen bezero aplikazioa

VPN aplikazio batzuek beren protokolo inplementazioa ekartzen dute eta ez dute batere menpe stak natibotik. Honek flota azkar migratu ezin duenarentzat behin-behineko irtenbide zilegia egiten ditu, baina bateragarritasun galdera aplikaziora pasatzen da: zure atebideak hitz egiten duen IKEv1 modu zehatza inplementatzen duen, atebideak eskatzen dituen autentifikazio eta zifratze multzoekin.

Hartu aplikazioaren laguntza matrizea autoritate gisa, ez dendako deskribapena, eta probatu gailu erreal bat atebide errealaren aurka gomendatu aurretik. Telefono bat rootatzea kendutako plataforma bide bat leheneratzeko ez da mantendutako irtenbidea ere; arazoa hurrengo sistema eguneraketak isilka hauts dezakeen konfigurazio ez-onartu batera eramaten du.

Aukeratu atebideak eskain dezakeenaren arabera

Erabakia estutu egiten da bi gauza dakizkizunean: zein gailu abiarazi ziren API 31 edo geroago, eta atebideak IKEv2 zerbitzua eskain dezakeen erregistro eredu berarekin. Ahal badu, migratu eta utzi profil zaharrean inbertitzeari. Oraindik ezin badu, mantendu IKEv1 oraindik abiarazten duten gailuentzat, eta eman gailu berriei hirugarrenen bezero bat dokumentatutako, denboran mugatutako salbuespen gisa, ez deklaratutako konponbide gisa.

Bi gauzak egiten dute plana defendagarria. Lehenik, erregistratu salbuespen bakoitzaren arrazoia modeloarekin eta abiarazte mailarekin, auditore batek muga plataforma zaintzaile bat dela ikus dezan, azaldu gabeko lehentasuna ez dela. Bigarrenik, tratatu migrazioa lan planifikatu gisa: IKEv1 zaharkituta dago estandarren bidean (RFC 9395), hau da, gainerako gailuak gutxitzen jarraituko dute eta salbuespenak haiekin batera iraungi beharko lukete.