Kaks telefoni näitavad mõlemad seadetes Android 12 ja ainult üks neist käivitab veel vana IPsec XAuth profiili, mida teie lüüs pakub. Erinevus ei ole seade, milleni kasutaja ulatub: natiivset IKEv1 teed kontrolliv valvur vaatab SDK taset, millega seade tarniti, mitte ainult versiooni, mis praegu töötab. See üks detail otsustab, kas fleedi võrdlusel on mõtet, ja otsustab ka, millist kolmest migratsiooniteest te tegelikult vajate.

Kaks Android 12 telefoni ei ole sama katsejuhtum

AOSP muudatus, mis keelas uutel seadmetel vanu IKEv1 profiile käivitada, võrdleb DEVICE_INITIAL_SDK_INT Android S-iga, see tähendab API 31. Natiivsel käivitusteele tekitab sobiv profiil toetamata toimingu vea enne, kui üldse tekib kasulik ühendus. Android 11-ga tarnitud ja hiljem uuendatud telefon läbib selle valvuri endiselt; Android 12-ga turule tulnud mudel mitte.

Neid kahte arvu saab lugeda seadmest, kus on silumine lubatud:

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

Esimene väärtus on tarnekäivituse tase, mida valvur jälgib, teine on see, mida telefon täna käitab. Kui omadus puudub, toetuge mudeli tugidokumentatsioonile, mitte ärge oletage turundusnime põhjal, ja ärge eeldage, et tootja build säilitab kõik baasversiooni ühilduvusteed.

Veel üks eristus säästab tunni raisatud tugiaega: VPN-seadetes veel loetletud salvestatud profiil ei tõesta midagi selle kohta, kas platvorm selle käivitab. PSK uuesti sisestamine või marsruutide muutmine ei saa eemaldada varem töötavat protokolli toe kontrolli ja tõrge näeb välja nagu mandaadiprobleem, kuigi see pole seda.

Tee üks: hoidke natiivset virna seal, kus see veel töötab

Vana virn on see, mis loeb IPsec XAuth PSK, IPsec Hybrid RSA ja L2TP/IPsec PSK profiile süsteemi VPN-ekraanilt. API 31-st allpool tarnitud seadmes jääb see pärast uuendust toimivaks teeks, seepärast võib proov vanemal seadmel õnnestuda, samal ajal kui uus seade sama profiili ei käivita.

Oluline võrdlus on seadmeklassi, mitte Androidi versiooni järgi: loetlege fleedi mudelid, lugege nende tarne-API tasemed ja jagage need seadmeteks, mis profiili veel käivitavad, ja nendeks, mis ei suuda. Kõik muu loob tugipoliitika, mis on iseendale vastuises hetkel, kui kasutaja ostab uue telefoni.

Tee kaks: platvormi IKEv2 profiilid

Androidi avalik IKEv2 tarne mudel on teine objekt, mitte ümbernimetatud IKEv1 profiil. Platvormi API IKEv2 profiilide jaoks tuli API 30-ga ja eeldab IKEv2-t lüüsi pakutava autentimismeetodiga, tavaliselt sertifikaadipõhine või EAP. IKEv1 XAuth või Hybrid pealt IKEv2-le pole juhtmekompatiibelset uuendust: lüüs tuleb uue protokolli jaoks seadistada ja profiil peab kandma vastavat identiteeti.

See on pikima elueaga tee ja ka see, mis paljastab tegeliku töö. Identiteedi valideerimine, kasutaja autentimine, DNS, split-tunneli marsruudid ja ressursside autoriseerimine peavad migratsiooni üle elama; ainult kätlemise õnnestumine jätab kasutajad tunnelisse, mis ei jõua kuhugi.

Kasutuselevõtt käib tavaliselt MDM-i või hallatava konfiguratsiooni kaudu, mitte kasutaja väljade sisestamise teel. Kui seda taristut veel pole, peab migratsiooniplaan selle sisaldama, sest IKEv2 profiili käsitsi igasse seadmesse uuesti sisestamine pole toiming, mida tugiteenus suudab neelata.

Tee kolm: kolmanda osapoole kliendirakendus

Mõned VPN-rakendused toovad oma protokolliimplementatsiooni ega sõltu natiivsest virnast üldse. See teeb neist õiguspärase ajutise lahenduse fleedile, mis ei saa kiiresti migreeruda, kuid ühilduvusküsimus liigub rakendusele: kas see rakendab täpselt seda IKEv1 režiimi, mida teie lüüs räägib, lüüsi nõutava autentimise ja šifrikomplektidega.

Võtke rakenduse enda tugimaatriks autoriteediks, mitte poe kirjeldus, ja testige ühte reaalset seadet reaalse lüüsi vastu enne selle soovitamist. Telefoni rootimine eemaldatud platvormitee taastamiseks pole samuti hooldatud lahendus; see viib probleemi toetamata konfiguratsiooni, mille järgmine süsteemiuuendus võib vaikselt rikkuda.

Valige selle järgi, mida lüüs suudab pakkuda

Otsus kitseneb, kui teate kahte asja: millised seadmed tulid turule API 31 või hiljem ja kas lüüs suudab pakkuda IKEv2 teenust sama registreerimismudeliga. Kui suudab, migreeruge ja lõpetage vanasse profiili investeerimine. Kui veel ei suuda, jätke IKEv1 seadmetele, mis seda veel käivitavad, ja andke uutele seadmetele kolmanda osapoole klient dokumenteeritud, ajaliselt piiratud erandina, mitte väljaütlemata möödasõiduna.

Kaks asja teevad plaani kaitstavaks. Esiteks kirjutage iga erandi põhjus mudeli ja tarnekäivituse tasemega üles, et audiitor näeks, et piir on platvormi valvur, mitte selgitamata eelistus. Teiseks käsitlege migratsiooni planeeritud tööna: IKEv1 on standardite teel vananenud (RFC 9395), mis tähendab, et ülejäänud seadmeid jääb vähemaks ja erandid peaksid nendega lõppema.

Seotud artiklid