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, рутите за split-tunnel и авторизацијата на ресурсите сите мора да ја преживеат миграцијата; ако успее само ракувањето, корисниците остануваат поврзани на тунел што не допира ништо.

Распоредувањето обично оди преку MDM или управувана конфигурација, а не преку корисник што внесува полиња. Ако таа инфраструктура сè уште не постои, миграцискиот план мора да ја вклучи, бидејќи повторното внесување на IKEv2 профил рачно на секој уред не е операција што може да ја апсорбира службата за поддршка.

Пат три: апликација од трета страна

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

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

Изберете според тоа што портата може да го понуди

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

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