Зошто вашата Android апликација не може да додаде системски VPN профил

Клекате на редот VPN во Поставки, гледате профил што го инсталирал некој друг и почнувате да го барате повикот што додава еден. Таков повик не постои. Апликацијата може да отвори свој тунел преку VpnService, но записите во таа листа им припаѓаат на платформата и на оној клиент што ги создал. Точното знаење каде лежи границата ви заштедува една недела бркање скриени класи.

Почнете од она што го покажува екранот Поставки

Листата VPN е регистар на профили што ги инсталирал системот или клиент на производителот: PPTP, L2TP/IPsec, IKEv2 и сите редови што ги турнал OEM апликација или MDM. Секој ред носи адреса на сервер, акредитиви и имплементација на протокол што живее надвор од вашиот процес. Кога корисникот таму ќе допре Поврзи, тунелот го крева клиентот на платформата, а не вашиот код. Затоа редот преживува рестарт и затоа деинсталирањето на вашата апликација никогаш не го отстранува.

Од страната на корисникот листата изгледа како површина на API, место каде додавањето VPN треба да е на една намера растојание. Не е. Единствените јавни влезни точки што ја допираат се навигациски намери, и сето она што пишува во неа и припаѓа на платформата или на привилегирана компонента.

Практична последица: ако текстот за поддршка им кажува на корисниците да го додадат профилот во Поставки, вашата апликација воопшто не е дел од тој тек.

Што всушност ви дава VpnService

VpnService и VpnService.Builder опишуваат еден тунел што вашата апликација го поседува. Додавате адреси, рути, DNS сервери и MTU, го ограничувате сообраќајот со addAllowedApplication() или addDisallowedApplication(), а потоа establish() враќа ParcelFileDescriptor за TUN интерфејс. Од тој момент апликацијата чита IP пакети и пишува одговори, што значи дека протоколот е ваш за имплементација или вградување: OpenVPN, WireGuard, сопствен транспорт.

Ништо во таа низа не зборува PPTP, L2TP/IPsec или IKEv2. Builder нема прекинувач што вели користи системски L2TP клиент, и нема повратен повик што ви дозволува да управувате со профил што платформата веќе го поседува. Тоа е вистинската граница, и таа е граница на дизајнот, а не празнина во дозволите.

Значи апликацијата сосема може да биде VPN клиент на Android. Само не може да биде менаџер за клиентите што доаѓаат со телефонот.

Дијалогот за согласност не е украс

Бидејќи вашиот тунел може да го фати сообраќајот на други апликации, системот бара корисникот експлицитно да го одобри. prepare() враќа Intent што мора да го стартувате, одобрувањето е врзано за вашиот пакет, и додека тунелот е активен статусната лента покажува постојан индикатор. Втор VPN што ќе се крене ја деактивира првата, бидејќи Android работи само еден активен VPN истовремено.

Тоа правило за еден активен ги сопнува луѓето при тестирање. Го кревате својот тунел додека е поврзан корпоративен клиент и заклучувате дека вашиот код е расипан, а платформата едноставно префрлила од другиот клиент. Одобрувањата можат подоцна да се повлечат, и prepare() може да врати null на уреди каде што недостасува активноста за согласност, па establish() сепак мора да се справи со неуспех.

Скриени API и намери за поставки

Поновите одговори покажуваат на класи com.android.internal и AIDL интерфејси што ги користи вградениот клиент. Тие не се во SDK, се менуваат меѓу изданија без известување, и продавниците за апликации го сметаат тој пристап за ризик. Root-увањето на уредот исто така не ги прави стабилни, бидејќи root и пристапот до скриени API се неповрзани проблеми.

Поддржаното навигациско помагало е Settings.ACTION_VPN_SETTINGS, чија вредност е android.net.vpn.SETTINGS. Решете го пред стартување, бидејќи некои OEM градби не ја доставуваат таа активност, и преминете на пишани чекори кога решавањето нема да успее. Тоа го води корисникот до екранот и не конфигурира ништо.

Патеките на сопственик на уред и MDM се исклучокот што луѓето обично го мислат. DevicePolicyManager може да одреди пакет за постојано вклучен VPN, а управуваните конфигурации можат однапред да вчитаат поставки за клиент што ги поддржува, но тоа уште не е јавниот SDK што составува PPTP профил.

Проследете ја одлуката од страната на корисникот

Ако вашиот производ треба да пренесува сообраќај, планирајте VpnService плус вистински протоколен стек, и предвидете време за текот на согласност и правилото за еден VPN. Ако целта е поврзување со постоечки корпоративен профил, вашата работа е насочување: длабока врска до екранот со поставки, документирање на полињата, и оставете го клиентот на платформата да го прави тунелот. Ако апликацијата треба само да стигне до приватна крајна точка, воопшто не ѝ треба сопствен тунел.

Запишете ја таа одлука пред да пишувате код, бидејќи трите патеки по првиот спринт немаат речиси ништо заедничко.

Последна проверка пред да почнете: дали барањето вели дека нашата апликација се поврзува или дека уредот се поврзува? Првото е VpnService, второто е профил што не можете да го создадете. Правилното формулирање на таа реченица е поевтино од секое преработување.