Профілі 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 — це справжнє розділення, а не ярлик. Робочий профіль — окремий користувач зі своїми встановленими пакетами, своїми даними застосунків, своїм keystore і своїми якорями довіри. Той самий продукт, встановлений в обох місцях, — це два екземпляри з різними ідентифікаторами користувача, навіть коли значки в лаунчері та назви продукту однакові.

Підготовка записується на викликаючий пакет у цьому користувачі. Тож застосунок підготовки, що працює в особистому профілі, створює особистий тунель, а робочі застосунки в робочому профілі нічого з нього не бачать. Зворотне також правда, і саме тому тунель робочого профілю невидимий для особистих застосунків без явної політики, яка каже інакше.

Контролер політики пристрою може готувати від імені керованого профілю, і це пояснює запис, який ніхто в офісі не пам'ятає, що створив. Якщо ви проводите аудит телефону, це ймовірний власник посивілого профілю, і видаляти його як експеримент — не ваша справа.

Три брами, перш ніж пакет рушить

Перша брама — повноваження: керування має взагалі дозволяти VPN, а деякі розгортання обмежують і тип, а не лише наявність. Друга — ідентичність: клієнтський сертифікат або облікові дані мають бути доступні в користувачеві, який володіє профілем, бо сертифікат, імпортований в особистий keystore, не видно робочому профілю.

Третя — згода й політика. Користувач зазвичай схвалює з'єднання при першому використанні, а адміністратор може додатково закріпити його як постійно ввімкнене, за бажанням із блокуванням, щоб трафік не міг виходити за межі тунелю. Ці налаштування вирішують, що станеться, коли тунель упаде, і саме цю частину користувачі помічають.

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

Чому особисте з'єднання не покриває робочі застосунки

Трафік робочого застосунку виникає в робочому користувачі, і застосовна мережева політика — та, що в цьому користувачі. Тунель, установлений в особистому профілі, його не переносить, хоч яким би здоровим виглядав індикатор. Цей єдиний факт пояснює більшість звітів, де користувач присягається, що VPN підключено, а один конкретний застосунок усе одно не дістає внутрішній сервіс.

Розв'язання імен підкоряється тій самій межі. Приватні суфікси DNS та якорі довіри задаються для користувача, тому внутрішнє ім'я хоста, яке розв'язується в особистому профілі, може не розв'язатися в робочому навіть із зовні рівноцінним тунелем, бо політика резолвера та сховище CA — різні об'єкти.

Перевіряйте на реальній реєстрації, а не на лабораторному телефоні

На пристрої спершу визначте власника запису: який користувач, який пакет і чи профіль прийшов від засобу підготовки платформи, чи від застосунку, що реалізує власну службу VPN. Потім підтвердьте, що ідентичність, яку очікує профіль, справді присутня в keystore цього користувача.

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

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

Не форсуйте питання, запускаючи приховані дії налаштувань, щоб відкрити меню, і не копіюйте приватні ключі між профілями, щоб з'єднання з'явилося. Довідка VpnManager описує, що викликач має право підготувати; якщо схвалений шлях не охоплює ваш випадок, це рішення адміністратора, а не проблема налаштувань.