Miks rakendus ei saa Androidis või iOS-is salvestatud VPN-profiili sisse lülitada

Kaks väga erinevat tööd paigutatakse programmeeritava VPN nimetuse alla, ja ainult üks neist on tavalisele rakendusele kättesaadav kummalgi mobiiliplatvormil. Esimene on sisse lülitada profiil, mille kasutaja on juba salvestanud; teine on ehitada tunnel teie enda protsessi sees. Android annab teise läbi VpnService ja iOS annab teise läbi Network Extensioni õiguse, samal ajal kui esimene jääb süsteemi, seadme omaniku või MDM-serveri juurde. See, kui selgitate välja, millist te tegelikult vajate, teeb projekti tavaliselt väiksemaks.

Kaks tööd ühe nime all

Salvestatud profiili aktiveerimine tähendab olemasolevale tunnelile ütlemist, et see üles tuleks: host, mandaat, protokoll, kõik juba seadistatud kohas, mida kasutaja näeb. Tunnelit ehitada tähendab, et teie kood omab liidest, paketitsüklit ja protokolli. Toote backlogis näevad need sarnased välja ja peaaegu ei jaga implementatsiooni.

Kumbki mobiiliplatvorm ei ava esimest SDK-rakendusele. Ühendus, mis ilmub ilma, et kasutaja midagi teeks, on pahavarast eristamatu, seetõttu panevad mõlemad süsteemid nõusolekuvärava iga rakenduse ette, mis liiklust kannab.

Android: nõusolekuvärav ja profiili-API puudub

VpnService on olemas alates Androidist 4.0 ja laseb rakendusel luua tun-liidese ning seejärel pakette lugeda ja kirjutada. Teenus tuleb deklareerida BIND_VPN_SERVICE abil ning VpnService.prepare() toodab süsteemidialoogi, mis palub kasutajal seda lubada. Platvormi näidis ToyVpn on kavandatud kuju kõige selgem väljendus: teie kood omab liidest ja kõike, mis sellest läbi voolab.

Mida see ei tee, on kirje lisamine süsteemi VPN-i seadete ekraanile. Selleks puudub avalik API ja rakendus Seaded hoiab oma profiile hoidlas, kuhu tavaline rakendus ei ulatu. Varjatud klasside kutsumine tavalisest rakendusest tekitab profiile, mida süsteem kunagi ei loetle, mistõttu kood, mis ühes buildis töötavat näis, lakkab järgmises vaikselt töötamast.

Hallatav tee on eraldi. Seadme omanik või profiili omanik saab seadme poliitika API-de kaudu määrata alati sisse lülitatud VPN-paketi, ja ettevõtte tööriist saab saata profiili, mille kasutaja seejärel kinnitab. See on seadmehalduse volitus, mitte luba, mida rakendus installimisel palub. Kui teie klient on organisatsioon, on see tee, mille jaoks planeerida; kui teie klient on inimene, kes installib poest, ei ole see üldse saadaval.

iOS: õigus on piir

iOS jagab sama tööd teisiti. VPN-klient rakendab paketitunneli pakkuja või rakenduse puhverserveri Network Extensioni raamistikus ning vastav õigus tuleb arendajakontole anda. Isiklik VPN-konfiguratsioon NEVPNManager kaudu on olemas lihtsama juhtumi jaoks ja see töötab endiselt samas lubade mudelis. Apple dokumenteerib kogu pinna Network Extensioni viites, mida tasub lugeda enne, kui töö ulatuse paika panete.

Pole ühtegi toetatud viisi, kuidas avada VPN-i seadete ekraani, lugeda kasutaja salvestatud konfiguratsioone või üht neist käivitada. Klient saab saata konfiguratsiooniprofiili, mille kasutaja installib, ja seejärel kasutada tekkinud tunnelit tavaliste võrgukutsetega. Rakendusepõhist tunnelit määrab MDM-server nõudmisel reegli kaudu, mitte ei vali rakendus seda käitusajal.

Suure tarnija VPN-klient ei ole tõestus, et teie konto saab sama asja saata. Neid õigusi küsitakse iga arendajakonto kohta ja neid vaadatakse üle, seega ajakava risk lasub Apple'il, mitte teie sprindi plaanil.

Töölaud ulatub kaugemale, aga omand jääb samaks

Windows on lubav juhtum. Add-VpnConnection loob kõrgendatud PowerShelli seansist telefoniraamatu kirje ja rasdial ühendab või katkestab selle skriptist. Rakendus saab ka tarnija klienti juhtida selle dokumenteeritud käsurea kaudu. Profiili loomine on endiselt haldustoiming, sest kirje elab masinat läbivas hoidlas.

macOS käitub samamoodi teiste tööriistadega. scutil --nc start ja stop töötavad teenustel, mis on juba olemas, samal ajal kui ühe loomine on süsteemiadministreerimise ülesanne. Protsessi omamine sülearvutis ei tee teid konfiguratsiooni omanikuks.

Mida selle asemel ehitada

Kui tegelik nõue on, et teie rakendus jõuaks sisemise API-ni, piisab tunnelist, mille kasutaja juba tööle paneb. Tehke tavalisi HTTPS-päringuid, laske süsteemil tee valida, ja lõpetage tunneli juhtimise proovimine. Kui nõue on, et ainult teie rakenduse liiklus kasutab tunnelit, küsige halduskanali kaudu rakendusepõhist VPN-i või lõpetage TLS rakenduse sees teenuse vastu, mis on kättesaadav ka ilma selleta.

Varjatud API-d ei ole lühike tee, mida tasub võtta. Need muutuvad väljaannete vahel, need kukuvad rakenduse ülevaatusel läbi ja vead, mida need tekitavad, näivad koodi pärijale tavaliste võrguvigadena. Võrdlus ei ole Android versus iOS; see on tunneli omamine versus platvormi palumine liiklust suunata, ja ainult esimene on teie ehitada.