Профілі Android IKEv2 VPN прывязаныя да карыстальніка, а не да прылады

Выраз убудаваны 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 апісвае, што выклікальніку дазволена ствараць; калі ўхвалены шлях не ахоплівае ваш выпадак, гэта рашэнне адміністратара, а не праблема налад.