Профили IKEv2 VPN в Android привязаны к пользователю, а не к устройству

Выражение «встроенный VPN» на Android охватывает две несвязанные вещи: реализацию протокола, которую платформа запускает от вашего имени, и ту форму настроек, которую производитель решил показать. Это не один и тот же объект, и ни одна из них не гарантирует, что туннель принадлежит пользователю, чьим приложениям он нужен. Подготовка профиля выполняется в определённом пользователе с определённым вызывающим пакетом, и всё дальнейшее наследует этот контекст. Прочитайте цепочку владения, прежде чем читать экран настроек.

Что платформа строит за вас

Начиная с Android 11 платформа предоставляет подготовку VPN через VpnManager. Одобренное приложение описывает профиль IKEv2, а платформа сама выполняет обмен IPsec и IKE, поэтому приложение никогда не касается пакетов. Это существенное отличие от собственного VPN-приложения, которое реализует VpnService и строит туннель в своём процессе.

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

Приведённый вызов — набросок формы, а не блок для копирования: у конструктора есть несколько вариантов аутентификации, они различаются в зависимости от уровня API, и профиль также несёт материал доверия к сертификату сервера. Для вопроса о владении важно нечто более узкое, чем синтаксис.

Из этого устройства следуют два свойства. Профиль является данными, поэтому его может подготовить администратор, а не набирать вручную. И туннель является сетью платформы, поэтому приложения видят его как сеть с транспортом VPN, а не как сокет другого приложения.

Владение — сначала пользователь, затем пакет

Многопользовательский режим Android — это настоящее разделение, а не ярлык. Рабочий профиль — отдельный пользователь со своими установленными пакетами, своими данными приложений, своим хранилищем ключей и своими якорями доверия. Один и тот же продукт, установленный в обоих местах, — это два экземпляра с разными идентификаторами пользователя, даже если значки в лаунчере и названия продукта совпадают.

Подготовка записывается на вызывающий пакет в этом пользователе. Поэтому приложение подготовки, работающее в личном профиле, создаёт личный туннель, и рабочие приложения в рабочем профиле ничего о нём не видят. Обратное тоже верно, и поэтому туннель рабочего профиля невидим для личных приложений без явной политики, которая говорит иное.

Контроллер политики устройства может выполнять подготовку от имени управляемого профиля, и это объясняет запись, которую никто в офисе не помнит созданной. Если вы проводите аудит телефона, это вероятный владелец серого профиля, и удалять его в качестве эксперимента — не ваше дело.

Три шлюза, прежде чем пакет сдвинется

Первый шлюз — полномочия: управление должно вообще разрешать VPN, а некоторые развёртывания ограничивают и тип, а не только само наличие. Второй — идентичность: клиентский сертификат или учётные данные должны быть доступны в том пользователе, которому принадлежит профиль, потому что сертификат, импортированный в личное хранилище ключей, не виден рабочему профилю.

Третий — согласие и политика. Пользователь обычно одобряет подключение при первом использовании, а администратор может дополнительно закрепить его как постоянное, при желании с блокировкой, чтобы трафик не мог выходить за пределы туннеля. Эти настройки решают, что происходит при падении туннеля, и именно эту часть пользователи замечают.

Область действия — это место, где встречаются все три. Профиль определяет шлюз и идентичность, тогда как уровень политики решает, какие приложения могут использовать туннель и принудительно ли через него идёт трафик. Поэтому два телефона с одинаковыми адресами шлюза могут вести себя совершенно по-разному.

Почему личное подключение не покрывает рабочие приложения

Трафик рабочего приложения возникает в рабочем пользователе, и применяемая сетевая политика — та, что в этом пользователе. Туннель, установленный в личном профиле, его не переносит, как бы хорошо ни выглядел индикатор. Этот единственный факт объясняет большинство сообщений, где пользователь клянётся, что VPN подключён, а одно конкретное приложение всё равно не достаёт внутренний сервис.

Разрешение имён подчиняется той же границе. Частные суффиксы DNS и якоря доверия задаются для пользователя, поэтому внутреннее имя хоста, которое разрешается в личном профиле, может не разрешиться в рабочем даже при внешне равноценном туннеле, потому что политика резолвера и хранилище CA — разные объекты.

Проверяйте на реальной регистрации, а не на лабораторном телефоне

На устройстве сначала определите владельца записи: какой пользователь, какой пакет и пришёл ли профиль от средства подготовки платформы или от приложения, реализующего собственную службу VPN. Затем убедитесь, что идентичность, которую ожидает профиль, действительно присутствует в хранилище ключей этого пользователя.

Проверяйте жизненный цикл, а не только подключение. Войдите, разблокируйте хранилище учётных данных, дайте рабочему профилю постоять без дела вечером, затем верните его и убедитесь, что туннель возвращается без ручного нажатия. Рабочий профиль, который отключается после рабочего дня, забирает туннель с собой, и это ожидаемое поведение, а не сбой, при условии что ожидаемое недоступное состояние описано.

Наконец, проверьте само рабочее приложение на известной внутренней конечной точке и сравните с результатом личного профиля. Они могут различаться; различаться не может модель владения. Если туннель принадлежит не тому пользователю, перевыпуск сертификатов ничего не исправит.

Не форсируйте ситуацию, запуская скрытые действия настроек, чтобы открыть меню, и не копируйте закрытые ключи между профилями, чтобы подключение появилось. Справочник VpnManager описывает, что вызывающему разрешено подготавливать; если одобренный путь не включает ваш случай, это решение администратора, а не проблема настроек.