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