Android 12 ir IKEv1 VPN: paleidimo versija, IKEv2, trečiųjų šalių programos

Du telefonai nustatymuose rodo Android 12, tačiau tik vienas jų vis dar paleidžia senąjį IPsec XAuth profilį, kurį siūlo jūsų šliuzas. Skirtumas nėra nustatymas, kurį vartotojas gali pasiekti: apsauga, kuri riboja natyvųjį senąjį IKEv1 kelią, žiūri į SDK lygį, su kuriuo įrenginys buvo išleistas, o ne tik į versiją, kurią jis naudoja dabar. Ši viena detalė lemia, ar parko palyginimas turi prasmę, ir ji taip pat lemia, kurio iš trijų migracijos kelių jums iš tikrųjų reikia.

Du Android 12 telefonai nėra tas pats bandymo atvejis

AOSP pakeitimas, sustabdęs naujų įrenginių senųjų IKEv1 profilių paleidimą, lygina DEVICE_INITIAL_SDK_INT su Android S, tai yra API 31. Natyviajame senojo paleidimo kelyje tinkamas profilis sukelia nepalaikomos operacijos klaidą, kol dar nėra jokio naudingo ryšio. Telefonas, išleistas su Android 11 ir vėliau atnaujintas, šią apsaugą vis dar praeina; modelis, paleistas su Android 12, jos nepraeina.

Abu skaičius galite perskaityti įrenginyje, kuriame įjungtas derinimas:

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

Pirmoji reikšmė yra paleidimo lygis, kuris rūpi apsaugai, antroji – tai, ką telefonas naudoja šiandien. Kai savybės nėra, remkitės modelio palaikymo dokumentacija, o ne spėliokite pagal rinkodaros pavadinimą, ir nemanokite, kad pardavėjo kompiliacija išlaiko kiekvieną suderinamumo kelią, kurį turėjo bazinė versija.

Dar vienas skirtumas sutaupo valandą švaistomo palaikymo laiko: išsaugotas profilis, vis dar matomas VPN nustatymuose, nieko neįrodo apie tai, ar platforma jį paleis. PSK įvedimas iš naujo ar maršrutų keitimas negali pašalinti protokolo palaikymo patikros, kuri vyksta anksčiau, o klaida atrodo kaip prisijungimo duomenų problema, nors ja nėra.

Pirmasis kelias: išlaikyti natyviąją senąją krūvą ten, kur ji dar veikia

Senoji krūva yra ta, kuri skaito IPsec XAuth PSK, IPsec Hybrid RSA ir L2TP/IPsec PSK profilius iš sistemos VPN ekrano. Įrenginyje, išleistame žemiau API 31, ji išlieka perspektyviu keliu po atnaujinimo, todėl bandomasis diegimas senesniame telefone gali pavykti, o naujas telefonas tą patį profilį atmeta.

Svarbus palyginimas yra pagal įrenginių klasę, o ne pagal Android versiją: išvardykite parko modelius, perskaitykite jų paleidimo API lygius ir suskirstykite juos į įrenginius, kurie profilį dar paleidžia, ir įrenginius, kurie negali. Visa kita sukuria palaikymo politiką, kuri prieštarauja pati sau, kai tik vartotojas nusiperka naują telefoną.

Antrasis kelias: platformos IKEv2 profiliai

Android viešasis IKEv2 paruošimo modelis yra kitas objektas, o ne pervadintas IKEv1 profilis. Platformos API IKEv2 profiliams atsirado su API 30 ir tikisi IKEv2 su autentifikavimo metodu, kurį siūlo šliuzas, dažniausiai sertifikatu pagrįsto arba EAP. Nėra laidu suderinamo atnaujinimo iš IKEv1 XAuth ar Hybrid į IKEv2: šliuzas turi būti sukonfigūruotas naujam protokolui, o profilis turi turėti atitinkamą tapatybę.

Tai ilgiausią gyvavimo laiką turintis kelias, ir būtent jis atskleidžia tikrąjį darbą. Tapatybės patikra, vartotojų autentifikavimas, DNS, split-tunnel maršrutai ir išteklių autorizacija turi išgyventi migraciją; jei pavyksta tik rankos paspaudimas, vartotojai lieka tunelyje, kuris nieko nepasiekia.

Diegimas paprastai vyksta per MDM arba valdomą konfigūraciją, o ne per vartotoją, įvedantį laukus. Jei tokios infrastruktūros dar nėra, migracijos planas turi ją įtraukti, nes IKEv2 profilio įvedimas rankiniu būdu kiekviename įrenginyje nėra operacija, kurią gali pajėgti pagalbos tarnyba.

Trečiasis kelias: trečiosios šalies kliento programa

Kai kurios VPN programos turi savo protokolo įgyvendinimą ir visiškai nepriklauso nuo natyviosios senosios krūvos. Tai daro jas teisėtu laikinu sprendimu parkui, kuris negali greitai migruoti, tačiau suderinamumo klausimas persikelia į programą: ar ji įgyvendina būtent tą IKEv1 režimą, kurį kalba jūsų šliuzas, su autentifikavimu ir šifravimo rinkiniais, kurių šliuzas reikalauja.

Programos palaikymo matricą laikykite autoritetu, o ne parduotuvės aprašymą, ir prieš rekomenduodami išbandykite vieną realų įrenginį su realiu šliuzu. Telefono rootinimas siekiant atkurti pašalintą platformos kelią taip pat nėra palaikomas sprendimas; jis perkelia problemą į nepalaikomą konfigūraciją, kurią kitas sistemos atnaujinimas gali tyliai sugadinti.

Rinkitės pagal tai, ką šliuzas gali pasiūlyti

Sprendimas susiaurėja, kai žinote du dalykus: kurie įrenginiai išleisti su API 31 arba vėliau, ir ar šliuzas gali pateikti IKEv2 paslaugą su tuo pačiu registracijos modeliu. Jei gali, migruokite ir nustokite investuoti į senąjį profilį. Jei dar negali, palikite IKEv1 įrenginiams, kurie jį dar paleidžia, o naujiems įrenginiams duokite trečiosios šalies klientą kaip dokumentuotą, terminuotą išimtį, o ne neapibrėžtą apeinimą.

Du dalykai daro planą apginamą. Pirma, užrašykite kiekvienos išimties priežastį su modeliu ir paleidimo lygiu, kad auditorius matytų, jog riba yra platformos apsauga, o ne nepaaiškintas pasirinkimas. Antra, traktuokite migraciją kaip planuotą darbą: IKEv1 yra nusenęs pagal standartų kryptį (RFC 9395), o tai reiškia, kad likę įrenginiai mažės, ir išimtys turėtų baigtis kartu su jais.