Android 12 un IKEv1 VPN: izlaišanas versija, IKEv2, trešo pušu lietotnes

Divi tālruņi iestatījumos abi rāda Android 12, un tikai viens no tiem joprojām startē veco IPsec XAuth profilu, ko piedāvā jūsu vārteja. Atšķirība nav iestatījums, ko lietotājs var sasniegt: aizsargs, kas kontrolē vietējo mantoto IKEv1 ceļu, skatās uz SDK līmeni, ar kuru ierīce tika izlaista, ne tikai uz laidienu, kas tajā darbojas tagad. Šī viena detaļa izšķir, vai parka salīdzinājums ir jēgpilns, un tā arī izšķir, kurš no trim migrācijas ceļiem jums patiešām ir vajadzīgs.

Divi Android 12 tālruņi nav viens un tas pats testa gadījums

AOSP izmaiņas, kas pārtrauca jaunu ierīču mantoto IKEv1 profilu startēšanu, salīdzina DEVICE_INITIAL_SDK_INT ar Android S, kas ir API 31. Vietējā mantotajā startēšanas ceļā atbilstošs profils izraisa neatbalstītas darbības kļūdu, pirms vēl pastāv kāds noderīgs savienojums. Tālrunis, kas tika izlaists ar Android 11 un vēlāk atjaunināts, joprojām iztur šo aizsargu; modelis, kas tika laists klajā ar Android 12, neiztur.

Abus skaitļus var nolasīt ierīcē ar iespējotu atkļūdošanu:

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

Pirmā vērtība ir izlaišanas līmenis, kas aizsargam rūp, otrā ir tas, ko tālrunis izmanto šodien. Ja īpašība nav pieejama, balstieties uz modeļa atbalsta dokumentāciju, nevis miniet pēc mārketinga nosaukuma, un nepieņemiet, ka ražotāja būvējums saglabā visus saderības ceļus, kas bija bāzes laidienam.

Vēl viena atšķirība ietaupa stundu izšķērdēta atbalsta laika: saglabāts profils, kas joprojām redzams VPN iestatījumos, neko nepierāda par to, vai platforma to startēs. PSK atkārtota ievadīšana vai maršrutu rediģēšana nevar noņemt protokola atbalsta pārbaudi, kas darbojas agrāk, un kļūda izskatās kā akreditācijas datu problēma, lai gan tā nav.

Pirmais ceļš: saglabāt vietējo mantoto steku tur, kur tas vēl darbojas

Mantotais steks ir tas, kas nolasa IPsec XAuth PSK, IPsec Hybrid RSA un L2TP/IPsec PSK profilus no sistēmas VPN ekrāna. Ierīcē, kas izlaista zem API 31, tas pēc atjaunināšanas joprojām ir dzīvotspējīgs ceļš, tāpēc izmēģinājums vecākā tālrunī var izdoties, kamēr jauns tālrunis to pašu profilu noraida.

Svarīgais salīdzinājums ir pēc ierīču klases, nevis pēc Android versijas: uzskaitiet parka modeļus, nolasiet to izlaišanas API līmeņus un sadaliet tos ierīcēs, kas profilu vēl startē, un ierīcēs, kas to nevar. Viss cits rada atbalsta politiku, kas sev pretrunā, tiklīdz lietotājs nopērk jaunu tālruni.

Otrais ceļš: platformas IKEv2 profili

Android publiskais IKEv2 nodrošināšanas modelis ir cits objekts, nevis pārdēvēts IKEv1 profils. Platformas API IKEv2 profiliem parādījās ar API 30 un sagaida IKEv2 ar autentifikācijas metodi, ko piedāvā vārteja, parasti uz sertifikātu balstītu vai EAP. Nav savienojumā saderīga jauninājuma no IKEv1 XAuth vai Hybrid uz IKEv2: vārteja ir jākonfigurē jaunajam protokolam, un profilam ir jānes atbilstošā identitāte.

Šis ir ceļš ar visilgāko mūžu, un arī tas, kas atklāj reālo darbu. Identitātes validācija, lietotāju autentifikācija, DNS, split-tunnel maršruti un resursu autorizācija visiem jāiztur migrācija; ja izdodas tikai rokas sasveicināšanās, lietotāji paliek tunelī, kas neko nesasniedz.

Izvietošana parasti notiek ar MDM vai pārvaldītu konfigurāciju, nevis ar lietotāju, kas ieraksta laukus. Ja šādas infrastruktūras vēl nav, migrācijas plānā tā jāiekļauj, jo IKEv2 profila ievadīšana ar roku katrā ierīcē nav operācija, ko atbalsta dienests var uzņemties.

Trešais ceļš: trešās puses klienta lietotne

Dažas VPN lietotnes piegādā savu protokola implementāciju un nemaz nav atkarīgas no vietējā mantotā steka. Tas padara tās par leģitīmu pagaidu risinājumu parkam, kas nevar ātri migrēt, taču saderības jautājums pārvietojas uz lietotni: vai tā ievieš tieši to IKEv1 režīmu, kādā runā jūsu vārteja, ar autentifikāciju un šifrēšanas komplektiem, ko vārteja prasa.

Uzskatiet lietotnes atbalsta matricu par autoritāti, nevis veikala aprakstu, un pirms ieteikšanas pārbaudiet vienu reālu ierīci pret reālu vārteju. Tālruņa rootošana, lai atjaunotu noņemtu platformas ceļu, arī nav uzturēts risinājums; tā pārvieto problēmu neatalgotā konfigurācijā, ko nākamais sistēmas atjauninājums var klusi salauzt.

Izvēlieties pēc tā, ko vārteja var piedāvāt

Lēmums sašaurinās, kad zināt divas lietas: kuras ierīces izlaistas ar API 31 vai vēlāk, un vai vārteja var nodrošināt IKEv2 pakalpojumu ar to pašu reģistrācijas modeli. Ja var, migrējiet un pārtrauciet ieguldīt mantotajā profilā. Ja vēl nevar, saglabājiet IKEv1 ierīcēm, kas to vēl startē, un jaunām ierīcēm dodiet trešās puses klientu kā dokumentētu, termiņu ierobežotu izņēmumu, nevis neizteiktu apkārtceļu.

Divi punkti padara plānu aizstāvamu. Pirmkārt, pierakstiet katra izņēmuma iemeslu kopā ar modeli un izlaišanas līmeni, lai auditors redzētu, ka robeža ir platformas aizsargs, nevis neizskaidrota izvēle. Otrkārt, uzskatiet migrāciju par plānotu darbu: IKEv1 ir novecojis standartu virzienā (RFC 9395), kas nozīmē, ka atlikušās ierīces turpinās sarukt, un izņēmumiem būtu jābeidzas kopā ar tām.