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 документира што смее да создаде повикувачот; ако одобрениот пат не го вклучува вашиот случај, тоа е одлука за администраторот, а не проблем со поставките.