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), а отже, решти пристроїв буде дедалі менше, і винятки мають завершуватися разом із ними.