Kvifor ein app ikkje kan slå på ein lagra VPN-profil på Android eller iOS

To svært ulike arbeidsoppgåver hamnar under namnet programmerbar VPN, og berre éin av dei er tilgjengeleg for ein vanleg app på kvar av dei to mobilplattformane. Den første er å slå på ein profil brukaren alt har lagra; den andre er å byggje ein tunnel inne i din eigen prosess. Android gjev deg den andre gjennom VpnService, og iOS gjev deg den andre gjennom retten Network Extension, medan den første blir hjå systemet, ein einings eigar eller ein MDM-tenar. Å finne ut kva for ein du faktisk treng gjer som regel prosjektet mindre.

To arbeidsoppgåver som deler eit namn

Å aktivere ein lagra profil tyder å seie til ein eksisterande tunnel at han skal kome opp: ein vert, eit påloggingsdøme, ein protokoll, alt alt konfigurert ein stad brukaren kan sjå. Å byggje ein tunnel tyder at koden din eig grensesnittet, pakkeløkka og protokollen. Dei ser like ut i ein produktbacklog, og dei deler nesten ingen implementasjon.

Ingen av mobilplattformane eksponerer den første for ein SDK-app. Ei tilkopling som dukkar opp utan at brukaren gjer noko, kan ikkje skiljast frå skadevare, så båe systema set ei samtykkjeport framfor kvar app som ber trafikk.

Android: ei samtykkjeport og ingen profil-API

VpnService har eksistert sidan Android 4.0 og lèt ein app lage eit tun-grensesnitt og deretter lese og skrive pakkar. Tenesta må deklarerast med BIND_VPN_SERVICE, og VpnService.prepare() lagar systemdialogen som ber brukaren tillate det. Plattformprøva ToyVpn er den klåraste fråsegna om den tiltenkte forma: koden din eig grensesnittet og alt som strøymer gjennom det.

Det han ikkje gjer, er å leggje til ei oppføring på VPN-innstilling skjermen til systemet. Det finst ingen offentleg API for det, og Innstillingar-appen held profilane sine i eit lager ein vanleg app ikkje når. Kall til dei skjulte klassane frå ein normal applikasjon gjev profilar systemet aldri listar opp, og difor sluttar kode som såg ut til å verke i éin bygg stille å verke i den neste.

Den styrte vegen er separat. Ein einings- eller profileigar kan peike ut ein alltid påslått VPN-pakke gjennom einingspolicy-API-ane, og eit verksemdsverktøy kan skyve ut ein profil som brukaren deretter godkjenner. Det er einingsadministrasjonsmynde, ikkje ei tillating ein app ber om ved installasjon. Viss kunden din er ein organisasjon, er dette vegen du må planleggje for; viss kunden din er ein person som installerer frå ein butikk, er han ikkje tilgjengeleg i det heile.

iOS: retten er grensa

iOS deler det same arbeidet annleis. Ein VPN-klient implementerer ein pakketunnel-leverandør eller ein app-proxy under Network Extension-rammeverket, og den tilsvarande retten må gjevast til utviklarkontoen. Ein personleg VPN-konfigurasjon gjennom NEVPNManager finst for det enklare tilfellet, og han køyrer framleis innanfor same tillatingsmodell. Apple dokumenterer heile flata i Network Extension-referansen, som er verd å lese før du avgrensar arbeidet.

Det finst ingen støtta måte å opne VPN-innstillingsskjermen, lese dei lagra konfigurasjonane til brukaren eller starte ein av dei. Det ein klient kan gjere, er å sende ein konfigurasjonsprofil som brukaren installerer, og deretter bruke den resulterande tunnelen gjennom vanlege nettverkskall. Tunneling per app blir tildelt av ein MDM-tenar gjennom ein on-demand-regel, ikkje vald av appen ved køyring.

Ein VPN-klient frå ein stor leverandør er ikkje prov på at kontoen din kan sende det same. Desse rettane blir bedne om per utviklarkonto og gjennomgådde, så tidsplanrisikoen ligg hjå Apple, ikkje i sprintplanen din.

Skrivebordet når lenger, men eigarskapet er uendra

Windows er det tillatande tilfellet. Add-VpnConnection opprettar ei telefonbokoppføring frå ein forhøgd PowerShell-økt, og rasdial koplar ho til eller frå i eit skript. Ein app kan òg styre ein leverandørklient gjennom den dokumenterte kommandolinja hans. Å opprette profilen er framleis ei administrativ handling, fordi oppføringa ligg i eit lager for heile maskinen.

macOS oppfører seg likt med andre verktøy. scutil --nc start og stop arbeider på tenester som alt finst, medan det å opprette ei er ei systemadministrasjonsoppgåve. Å eige prosessen på ein berbar PC gjer deg ikkje til eigar av konfigurasjonen.

Kva du bør byggje i staden

Viss det eigentlege kravet er at appen din når ein intern API, er tunnelen brukaren alt køyrer nok. Send vanlege HTTPS-førespurnader, lat systemet velje vegen, og slutt å prøve å kontrollere tunnelen. Viss kravet er at berre trafikken til appen din brukar tunnelen, be om VPN per app gjennom administrasjonskanalen, eller avslutt TLS inne i appen mot ei teneste som er tilgjengeleg utan.

Skjulte API-ar er ikkje ein snarveg som er verd å ta. Dei endrar seg mellom utgivingar, dei feilar i appgjennomgang, og feila dei produserer ser for den som arvar koden ut som vanlege nettverksfeil. Samanlikninga er ikkje Android mot iOS; det er å eige ein tunnel mot å be plattformen rute trafikk, og berre den første er din å byggje.