Android 12 in IKEv1 VPN: različica ob izdaji, IKEv2, aplikacije tretjih ponudnikov

Dva telefona oba v Nastavitvah prikazujeta Android 12, in le eden od njiju še zažene stari profil IPsec XAuth, ki ga ponuja vaš prehod. Razlika ni nastavitev, do katere bi uporabnik lahko prišel: varovalo, ki zapira vgrajeno zapuščeno pot IKEv1, gleda raven SDK, s katero je bila naprava dobavljena, ne le izdaje, ki jo izvaja zdaj. Ta podatek odloči, ali je primerjava flote smiselna, in odloči tudi, katero od treh poti selitve v resnici potrebujete.

Dva telefona z Androidom 12 nista isti preskusni primer

Sprememba v AOSP, ki je novim napravam preprečila zaganjanje zapuščenih profilov IKEv1, primerja DEVICE_INITIAL_SDK_INT z Androidom S, to je API 31. Na vgrajeni zapuščeni poti zagona ustrezen profil sproži napako nepodprte operacije, preden sploh obstaja kakšna uporabna povezava. Telefon, dobavljen z Androidom 11 in pozneje posodobljen, to varovalo še prestane; model, izdan z Androidom 12, ga ne.

Obe števili lahko preberete na napravi z omogočenim razhroščevanjem:

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

Prva vrednost je raven izdaje, ki je pomembna varovalu, druga je tisto, kar telefon izvaja danes. Kjer lastnosti ni, se oprite na dokumentacijo o podpori modela, namesto da bi ugibali iz trženjskega imena, in ne predpostavljajte, da dobaviteljeva gradnja ohranja vsako pot združljivosti, ki jo je imela osnovna izdaja.

Še ena razlika prihrani uro zapravljenega časa podpore: shranjen profil, ki je še na seznamu v nastavitvah VPN, ne dokazuje ničesar o tem, ali ga bo platforma zagnala. Ponovni vnos PSK ali urejanje poti ne more odstraniti preverjanja podpore protokola, ki teče prej, in napaka je videti kot težava s poverilnicami, čeprav ni.

Pot ena: ohranite vgrajeni zapuščeni sklad tam, kjer še deluje

Zapuščeni sklad je tisti, ki bere profile IPsec XAuth PSK, IPsec Hybrid RSA in L2TP/IPsec PSK z sistemskega zaslona VPN. Na napravi, dobavljeni pod API 31, po nadgradnji ostane izvedljiva pot, zato lahko preskus na starejšem telefonu uspe, medtem ko novi telefon isti profil zavrne.

Primerjava, ki šteje, je po razredu naprave, ne po različici Androida: naštejte modele v floti, preberite njihove ravni API ob izdaji in jih razdelite na naprave, ki profil še zaženejo, in naprave, ki ga ne morejo. Vse drugo ustvari politiko podpore, ki si nasprotuje v trenutku, ko uporabnik kupi nov telefon.

Pot dve: platformski profili IKEv2

Androidov javni model priprave za IKEv2 je drug objekt, ne preimenovan profil IKEv1. Platformski API za profile IKEv2 je prišel z API 30 in pričakuje IKEv2 z metodo preverjanja, ki jo ponuja prehod, običajno s potrdilom ali EAP. Ni žično združljive nadgradnje iz IKEv1 XAuth ali Hybrid v IKEv2: prehod je treba nastaviti za novi protokol, profil pa mora nositi ustrezno identiteto.

To je pot z najdaljšo življenjsko dobo in tudi tista, ki razkrije resnično delo. Preverjanje identitete, overjanje uporabnikov, DNS, poti razdeljenega tunela in dovoljenja za vire morajo vsi prestati selitev; če uspe le rokovanje, uporabniki ostanejo povezani v tunel, ki ne doseže ničesar.

Uvajanje običajno poteka prek MDM ali upravljane konfiguracije, ne tako, da uporabnik vnaša polja. Če te infrastrukture še ni, jo mora načrt selitve vključevati, ker ponovno ročno vnašanje profila IKEv2 na vsaki napravi ni operacija, ki bi jo pomoč uporabnikom zmogla.

Pot tri: odjemalska aplikacija tretjega ponudnika

Nekatere aplikacije VPN prinašajo svojo izvedbo protokola in sploh niso odvisne od vgrajenega zapuščenega sklada. Zato so zakonita začasna rešitev za floto, ki se ne more hitro seliti, vendar se vprašanje združljivosti preseli na aplikacijo: ali izvaja natanko tisti način IKEv1, ki ga govori vaš prehod, s preverjanjem in šifrirnimi nizi, ki jih prehod zahteva.

Kot merodajno vzemite matriko podpore same aplikacije, ne opisa v trgovini, in pred priporočilom preskusite eno resnično napravo proti resničnemu prehodu. Rootanje telefona, da bi obnovili odstranjeno platformsko pot, tudi ni vzdrževana rešitev; težavo prestavi v nepodprto konfiguracijo, ki jo lahko naslednja sistemska posodobitev tiho pokvari.

Izberite po tem, kaj prehod lahko ponudi

Odločitev se zoži, ko veste dve stvari: katere naprave so bile izdane z API 31 ali pozneje, in ali lahko prehod predstavi storitev IKEv2 z istim modelom vpisa. Če lahko, selite se in prenehajte vlagati v zapuščeni profil. Če še ne more, obdržite IKEv1 za naprave, ki ga še zaženejo, novim napravam pa dajte odjemalca tretjega ponudnika kot dokumentirano, časovno omejeno izjemo, ne pa kot neizrečeno obvoznico.

Dve stvari naredita načrt obrambno vzdržen. Prvič, zabeležite razlog vsake izjeme skupaj z modelom in ravnjo izdaje, da bo revizor videl, da je meja varovalo platforme in ne nerazložena preferenca. Drugič, selitev obravnavajte kot načrtovano delo: IKEv1 je po standardni poti zastarel (RFC 9395), kar pomeni, da bo preostalih naprav vedno manj in izjeme bi morale izteči z njimi.