Bakit hindi maaaring i-on ng app ang naka-save na VPN profile sa Android o iOS

Dalawang lubos na magkaibang gawain ang inilalagay sa ilalim ng pangalang programmatic VPN, at isa lamang sa kanila ang available sa ordinaryong app sa alinman sa dalawang mobile platform. Ang una ay ang i-on ang profile na nai-save na ng user; ang pangalawa ay ang paggawa ng tunnel sa loob ng sarili mong proseso. Binibigyan ka ng Android ng pangalawa sa pamamagitan ng VpnService at binibigyan ka ng iOS ng pangalawa sa pamamagitan ng karapatang Network Extension, habang ang una ay nananatili sa system, sa may-ari ng device o sa isang MDM server. Ang pag-alam kung alin ang talagang kailangan mo ay kadalasang nagpapaliit sa proyekto.

Dalawang gawain na may isang pangalan

Ang pag-activate ng naka-save na profile ay nangangahulugang sabihin sa umiiral na tunnel na bumangon: isang host, isang kredensyal, isang protocol, lahat ay naka-configure na sa isang lugar na nakikita ng user. Ang paggawa ng tunnel ay nangangahulugang pagmamay-ari ng iyong code ang interface, ang packet loop at ang protocol. Magkamukha sila sa isang product backlog at halos walang ibinabahaging implementasyon.

Wala sa dalawang mobile platform ang naglalantad ng una sa isang SDK app. Ang koneksyong lumilitaw nang walang ginagawa ang user ay hindi makikilala mula sa malware, kaya parehong naglalagay ng gate ng pahintulot ang dalawang system sa harap ng anumang app na nagdadala ng trapiko.

Android: isang gate ng pahintulot, at walang API ng profile

VpnService ay umiiral mula noong Android 4.0 at nagpapahintulot sa app na gumawa ng tun interface, pagkatapos ay basahin at isulat ang mga packet. Dapat ideklara ang serbisyo gamit ang BIND_VPN_SERVICE, at ang VpnService.prepare() ay gumagawa ng system dialog na humihingi ng pahintulot sa user. Ang sample ng platform, ToyVpn, ang pinakamalinaw na pahayag ng nilalayong hugis: pagmamay-ari ng iyong code ang interface at lahat ng dumadaloy dito.

Ang hindi nito ginagawa ay ang magdagdag ng entry sa screen ng mga setting ng VPN ng system. Walang pampublikong API para doon, at ang app na Mga Setting ay nagtatago ng mga profile nito sa isang imbakan na hindi maabot ng ordinaryong app. Ang mga tawag sa mga nakatagong klase mula sa normal na aplikasyon ay gumagawa ng mga profile na hindi kailanman inililista ng system, kaya ang code na mukhang gumagana sa isang build ay tahimik na humihinto sa paggana sa susunod.

Ang pinamamahalaang landas ay hiwalay. Ang may-ari ng device o profile ay maaaring magtalaga ng laging naka-on na VPN package sa pamamagitan ng mga API ng patakaran ng device, at ang tool ng enterprise ay maaaring magpadala ng profile na inaprubahan ng user sa kalaunan. Iyon ay awtoridad sa pamamahala ng device, hindi pahintulot na hinihingi ng app sa pag-install. Kung ang kliyente mo ay isang organisasyon, ito ang landas na dapat planuhin; kung ang kliyente mo ay isang taong nag-install mula sa tindahan, hindi ito available sa lahat.

iOS: ang karapatan ang hangganan

Hinahati ng iOS ang parehong gawain sa ibang paraan. Ang VPN client ay nagpapatupad ng packet tunnel provider o app proxy sa ilalim ng framework na Network Extension, at ang katumbas na karapatan ay dapat ibigay sa developer account. Ang personal na VPN configuration sa pamamagitan ng NEVPNManager ay umiiral para sa mas simpleng kaso, at tumatakbo pa rin ito sa loob ng parehong modelo ng pahintulot. Dinodokumento ng Apple ang buong surface sa reference ng Network Extension, na sulit basahin bago mo tukuyin ang saklaw ng gawain.

Walang sinusuportahang paraan upang buksan ang screen ng mga setting ng VPN, basahin ang mga naka-save na configuration ng user o simulan ang isa sa mga ito. Ang magagawa ng client ay magpadala ng configuration profile para i-install ng user, at pagkatapos ay gamitin ang resultang tunnel sa pamamagitan ng ordinaryong network call. Ang tunneling bawat app ay itinatalaga ng MDM server sa pamamagitan ng panuntunang on-demand, hindi pinipili ng app sa runtime.

Ang VPN client mula sa malaking vendor ay hindi patunay na ang account mo ay makapagpadala ng parehong bagay. Ang mga karapatang iyon ay hinihingi bawat developer account at sinusuri, kaya ang panganib sa iskedyul ay nasa Apple, hindi sa plano ng sprint mo.

Mas malayo ang nararating ng desktop, pero hindi nagbabago ang pagmamay-ari

Ang Windows ay ang mapagbigay na kaso. Ang Add-VpnConnection ay gumagawa ng entry sa phonebook mula sa elevated PowerShell session, at ang rasdial ay nagkokonekta o naghihiwalay nito mula sa script. Maaari ring i-drive ng app ang client ng vendor sa pamamagitan ng dokumentadong command line nito. Ang paggawa ng profile ay administratibong aksyon pa rin, dahil ang entry ay naninirahan sa imbakan ng buong machine.

Ganoon din ang kilos ng macOS sa ibang mga tool. Ang scutil --nc start at stop ay gumagana sa mga serbisyong umiiral na, habang ang paggawa ng isa ay gawain ng system administration. Ang pagmamay-ari ng proseso sa laptop ay hindi ginagawa kang may-ari ng configuration.

Ano ang dapat gawin sa halip

Kung ang tunay na pangangailangan ay maabot ng app mo ang isang internal na API, sapat na ang tunnel na pinapatakbo na ng user. Magpadala ng ordinaryong HTTPS request, hayaang piliin ng system ang landas, at itigil ang pagtatangkang kontrolin ang tunnel. Kung ang pangangailangan ay ang trapiko lamang ng app mo ang gumamit ng tunnel, humingi ng VPN bawat app sa pamamagitan ng channel ng pamamahala, o tapusin ang TLS sa loob ng app laban sa isang serbisyong maabot nang wala ito.

Ang mga nakatagong API ay hindi maikling daan na sulit tahakin. Nagbabago sila sa pagitan ng mga release, nabigo sila sa review ng app, at ang mga pagpalya na ginagawa nila ay mukhang ordinaryong network fault sa sinumang magmamana ng code. Ang paghahambing ay hindi Android laban sa iOS; ito ay pagmamay-ari ng tunnel laban sa paghingi sa platform na rutahe ang trapiko, at ang una lamang ang sa iyo na itayo.