Профилите 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 документира какво може да създава извикващият; ако одобреният път не включва вашия случай, това е решение на администратора, а не проблем с настройките.