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 профили

Публичният модел за предоставяне на IKEv2 в Android е друг обект, а не преименуван IKEv1 профил. Платформеният API за IKEv2 профили дойде с API 30 и очаква IKEv2 с метода за удостоверяване, който шлюзът предлага, обикновено базиран на сертификат или EAP. Няма съвместимо по кабел надграждане от IKEv1 XAuth или Hybrid към IKEv2: шлюзът трябва да бъде конфигуриран за новия протокол, а профилът трябва да носи съответната идентичност.

Това е пътят с най-дълъг живот и също този, който разкрива истинската работа. Проверката на идентичност, удостоверяването на потребителя, DNS, маршрутите при разделен тунел и оторизацията на ресурси всички трябва да преживеят миграцията; успешният само ръкостискан ще остави потребителите вързани към тунел, който не достига доникъде.

Внедряването обикновено минава през MDM или управлявана конфигурация, вместо потребителят да въвежда полета. Ако тази инфраструктура още не съществува, планът за миграция трябва да я включи, защото повторното въвеждане на IKEv2 профил на ръка на всяко устройство не е операция, която сервизът за поддръжка може да поеме.

Трети път: клиентско приложение от трета страна

Някои VPN приложения доставят собствена реализация на протокола и изобщо не зависят от нативния стек. Това ги прави законна временна мярка за парк, който не може да мигрира бързо, но въпросът за съвместимост се премества към приложението: дали реализира точно режима IKEv1, на който говори вашият шлюз, с удостоверяването и наборите шифри, които шлюзът изисква.

Приемайте собствената матрица за поддръжка на приложението за авторитет, а не описанието в магазина, и тествайте едно реално устройство срещу реалния шлюз, преди да го препоръчате. Rootването на телефон, за да се върне премахнат платформен път, също не е поддържано решение; то премества проблема в неподдържана конфигурация, която следващото системно обновяване може тихо да счупи.

Избирайте по това, което шлюзът може да предложи

Решението се стеснява, след като знаете две неща: кои устройства са излезли на или след API 31 и дали шлюзът може да предложи IKEv2 услуга със същия модел на записване. Ако може, мигрирайте и спрете да инвестирате в стария профил. Ако още не може, запазете IKEv1 за устройствата, които още го стартират, и дайте на новите устройства клиент от трета страна като документирано, ограничено във времето изключение, а не като неизказано заобикаляне.

Две неща правят плана защитим. Първо, запишете причината за всяко изключение с модела и нивото на пускане, така че одиторът да види, че границата е платформена защита, а не необяснено предпочитание. Второ, третирайте миграцията като планирана работа: IKEv1 е отхвърлен в пътя на стандартите (RFC 9395), което означава, че останалите устройства ще продължат да намаляват и изключенията трябва да изтекат с тях.