Android 12 kaj IKEv1 VPN: eldonversio, IKEv2 kaj triapartaj aplikaĵoj

Du telefonoj ambaŭ montras Android 12 en Agordoj, kaj nur unu el ili ankoraŭ lanĉas la malnovan IPsec XAuth-profilon, kiun via enirejo proponas. La diferenco ne estas agordo, kiun la uzanto povas atingi: la gardo, kiu regas la denaskan IKEv1-vojon, rigardas la SDK-nivelon kun kiu la aparato estis liverita, ne nur la version, kiun ĝi nun rulas. Tiu sola detalo decidas, ĉu komparo de floto havas sencon, kaj ĝi ankaŭ decidas, kiun el la tri migraj vojoj vi vere bezonas.

Du telefonoj Android 12 ne estas la sama testa kazo

La ŝanĝo en AOSP, kiu malhelpis novajn aparatojn lanĉi malnovajn IKEv1-profilojn, komparas DEVICE_INITIAL_SDK_INT kun Android S, tio estas API 31. En la denaska lanĉovojo taŭga profilo kaŭzas fiaskon de neapogata operacio antaŭ ol ekzistas iu ajn utila konekto. Telefono liverita kun Android 11 kaj poste ĝisdatigita ankoraŭ trapasas tiun gardon; modelo lanĉita kun Android 12 ne.

Vi povas legi la du nombrojn sur aparato kun ŝaltita sencimigado:

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

La unua valoro estas la lanĉa nivelo, pri kiu zorgas la gardo, la dua estas tio, kion la telefono rulas hodiaŭ. Kie la eco mankas, apogu vin sur la subtena dokumentaro de la modelo anstataŭ diveni el la merkata nomo, kaj ne supozu, ke la konstruo de la fabrikanto konservas ĉiujn kongruecajn vojojn de la baza eldono.

Ankoraŭ unu distingo ŝparas horon da perdita subtena tempo: konservita profilo ankoraŭ listigita en la VPN-agordoj pruvas nenion pri tio, ĉu la platformo lanĉos ĝin. Reenigi la PSK aŭ redakti itinerojn ne povas forigi protokolan subtenkontrolon, kiu ruliĝas pli frue, kaj la fiasko aspektas kiel akreditaĵa problemo, kiam ĝi ne estas.

Vojo unu: teni la denaskan stakon tie, kie ĝi ankoraŭ funkcias

La malnova stako estas tiu, kiu legas IPsec XAuth PSK, IPsec Hybrid RSA kaj L2TP/IPsec PSK-profilojn el la sistema VPN-ekrano. Sur aparato liverita sub API 31 ĝi restas uzebla vojo post ĝisdatigo, tial provo sur pli malnova aparato povas sukcesi, dum nova aparato ne lanĉas la saman profilon.

La komparo, kiu gravas, estas laŭ aparatklaso, ne laŭ Android-versio: listigu la modelojn en la floto, legu iliajn lanĉajn API-nivelojn kaj dividu ilin al aparatoj, kiuj ankoraŭ lanĉas la profilon, kaj tiuj, kiuj ne povas. Io ajn alia produktas subtenpolitikon, kiu kontraŭdiras sin mem en la momento, kiam uzanto aĉetas novan telefonon.

Vojo du: platformaj IKEv2-profiloj

La publika provizmodelo de Android por IKEv2 estas alia objekto, ne renomita IKEv1-profilo. La platforma API por IKEv2-profiloj venis kun API 30 kaj atendas IKEv2 kun la aŭtentikiga metodo, kiun la enirejo proponas, kutime surbaze de atestilo aŭ EAP. Ne ekzistas drate kongrua ĝisdatigo de IKEv1 XAuth aŭ Hybrid al IKEv2: la enirejo devas esti agordita por la nova protokolo, kaj la profilo devas porti la respondan identecon.

Ĝi estas la vojo kun la plej longa vivo, kaj ankaŭ tiu, kiu malkaŝas la veran laboron. Identeckontrolo, uzantaŭtentikigo, DNS, itineroj de dividita tunelo kaj rajtigo de rimedoj ĉiuj devas postvivi la migradon; sukcesigi nur la manpremon lasas uzantojn ligitaj al tunelo, kiu atingas nenien.

La disfaldiĝo kutime iras tra MDM aŭ administrata agordo anstataŭ ke la uzanto tajpu kampojn. Se tiu infrastrukturo ankoraŭ ne ekzistas, la migra plano devas inkluzivi ĝin, ĉar reenigi IKEv2-profilon permane sur ĉiu aparato ne estas operacio, kiun helpa servo povas sorbigi.

Vojo tri: triaparta klienta aplikaĵo

Kelkaj VPN-aplikaĵoj liveras sian propran protokolrealigon kaj tute ne dependas de la denaska stako. Tio faras ilin legitima provizora solvo por floto, kiu ne povas rapide migri, sed la kongrueca demando transiras al la aplikaĵo: ĉu ĝi realigas ĝuste tiun IKEv1-reĝimon, kiun parolas via enirejo, kun la aŭtentikigo kaj la ĉifraj suitoj, kiujn la enirejo postulas.

Konsideru la propran subtenan matricon de la aplikaĵo kiel la aŭtoritaton, ne la priskribon en la butiko, kaj testu unu realan aparaton kontraŭ la reala enirejo antaŭ ol rekomendi ĝin. Rooti telefonon por restarigi forigitan platforman vojon ankaŭ ne estas prizorgata solvo; ĝi movas la problemon al neapogata agordo, kiun la sekva sistema ĝisdatigo povas silente rompi.

Elektu laŭ tio, kion la enirejo povas proponi

La decido mallarĝiĝas, kiam vi scias du aferojn: kiuj aparatoj lanĉiĝis je aŭ post API 31, kaj ĉu la enirejo povas proponi IKEv2-servon kun la sama registriĝmodelo. Se ĝi povas, migru kaj ĉesu investi en la malnovan profilon. Se ĝi ankoraŭ ne povas, konservu IKEv1 por la aparatoj, kiuj ankoraŭ lanĉas ĝin, kaj donu al novaj aparatoj triapartan klienton kiel dokumentitan, tempolimigitan escepton, ne kiel nedeklaritan ĉirkaŭvojon.

Du punktoj faras la planon defendebla. Unue, registru la kialon de ĉiu escepto kun la modelo kaj la lanĉa nivelo, por ke revizoro vidu, ke la limo estas platforma gardo, ne neklarigita prefero. Due, traktu la migradon kiel planitan laboron: IKEv1 estas eksvalidigita en la normiga vojo (RFC 9395), kio signifas, ke la restantaj aparatoj daŭre malmultiĝos kaj la esceptoj devus finiĝi kun ili.