Android 12 и IKEv1 VPN: верзија лансирања, IKEv2, апликације трећих страна

Два телефона оба приказују Android 12 у Подешавањима, а само један од њих још покреће стари IPsec XAuth профил који нуди ваш приступник. Разлика није подешавање до којег корисник може да дође: заштита која блокира уграђену наслеђену IKEv1 путању гледа ниво SDK са којим је уређај испоручен, а не само издање које сада извршава. Тај један детаљ одлучује има ли поређење флоте смисла, а одлучује и која од три миграциона пута вам заправо требају.

Два телефона са Android-ом 12 нису исти тестни случај

Промена у AOSP-у која је зауставила нове уређаје у покретању наслеђених IKEv1 профила пореди DEVICE_INITIAL_SDK_INT са Android-ом S, односно API 31. На уграђеној наслеђеној путањи покретања квалификовани профил изазива грешку неподржане операције пре него што уопште постоји корисна веза. Телефон испоручен са Android-ом 11 и касније ажуриран још пролази ту заштиту; модел лансиран са Android-ом 12 не пролази.

Оба броја можете прочитати на уређају са омогућеним отклањањем грешака:

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

Прва вредност је ниво лансирања до којег је заштити стало, друга је оно што телефон извршава данас. Где својство недостаје, ослоните се на документацију подршке модела уместо нагађања из маркетиншког назива, и не претпостављајте да произвођачка градња чува сваку путању компатибилности коју је имало основно издање.

Још једна разлика штеди сат изгубљеног времена подршке: сачувани профил који је још на списку у VPN подешавањима не доказује ништа о томе хоће ли га платформа покренути. Поновни унос PSK-а или уређивање рута не може уклонити проверу подршке протокола која се изводи раније, а грешка изгледа као проблем са акредитивима кад није.

Пут један: задржите уграђени наслеђени стек где још ради

Наслеђени стек је онај који чита IPsec XAuth PSK, IPsec Hybrid RSA и L2TP/IPsec PSK профиле са системског VPN екрана. На уређају испорученом испод API 31 остаје одржива путања након надоградње, зато пилот на старијем телефону може успети док нови телефон одбија исти профил.

Поређење које је важно иде по класи уређаја, а не по верзији Android-а: попишите моделе у флоти, прочитајте њихове нивое API-ја при лансирању и поделите их на уређаје који још покрећу профил и уређаје који не могу. Све друго даје политику подршке која противречи сама себи у тренутку кад корисник купи нови телефон.

Пут два: платформски IKEv2 профили

Android-ов јавни модел припреме за IKEv2 други је објекат, а не преименовани IKEv1 профил. Платформски API за IKEv2 профиле дошао је са API 30 и очекује IKEv2 са методом аутентикације коју нуди приступник, обично на бази сертификата или EAP. Нема жично компатибилне надоградње са IKEv1 XAuth или Hybrid на IKEv2: приступник се мора конфигурисати за нови протокол, а профил мора носити одговарајући идентитет.

Ово је пут са најдужим животом, и уједно онај који открива стварни рад. Провера идентитета, аутентикација корисника, DNS, руте подељеног тунела и ауторизација ресурса све морају преживети миграцију; ако успе само руковање, корисници остају повезани на тунел који ништа не достиже.

Увођење обично иде преко MDM-а или управљане конфигурације, а не преко корисника који уписује поља. Ако та инфраструктура још не постоји, план миграције мора је укључити, јер поновни ручни унос IKEv2 профила на сваком уређају није операција коју служба подршке може да упије.

Пут три: клијентска апликација треће стране

Неке VPN апликације испоручују сопствену имплементацију протокола и уопште не зависе од уграђеног наслеђеног стека. То их чини легитимним привременим решењем за флоту која не може брзо да мигрира, али питање компатибилности прелази на апликацију: да ли имплементира тачно онај IKEv1 начин којим говори ваш приступник, са аутентикацијом и скуповима шифри које приступник захтева.

Узмите сопствену матрицу подршке апликације као ауторитет, а не опис у продавници, и тестирајте један стварни уређај на стварном приступнику пре него што је препоручите. Root-овање телефона да би се вратила уклоњена платформска путања такође није одржавано решење; премешта проблем у неподржану конфигурацију коју следеће системско ажурирање може тихо сломити.

Бирајте према ономе што приступник може да понуди

Одлука се сужава кад знате две ствари: који су уређаји лансирани на API 31 или после, и може ли приступник да представи IKEv2 услугу са истим моделом уписа. Ако може, мигрирајте и престаните да улажете у наслеђени профил. Ако још не може, задржите IKEv1 за уређаје који га још покрећу, а новим уређајима дајте клијента треће стране као документовану, временски ограничену изнимку уместо неизреченог заобилазног решења.

Две ствари чине план одбрањивим. Прво, забележите разлог сваке изнимке уз модел и ниво лансирања, да ревизор види како је граница заштита платформе, а не необјашњена склоност. Друго, третирајте миграцију као планирани посао: IKEv1 је застарео према стандардној стази (RFC 9395), што значи да ће се преостали уређаји наставити смањивати и изнимке би требало да истекну заједно с њима.