Hvorfor en app ikke kan slå på en lagret VPN-profil på Android eller iOS

To svært forskjellige jobber havner under navnet programmerbar VPN, og bare én av dem er tilgjengelig for en vanlig app på hver av de to mobilplattformene. Den første er å slå på en profil brukeren allerede har lagret; den andre er å bygge en tunnel inne i din egen prosess. Android gir deg den andre gjennom VpnService, og iOS gir deg den andre gjennom rettigheten Network Extension, mens den første blir hos systemet, en enhetseier eller en MDM-server. Å finne ut hvilken du faktisk trenger gjør som regel prosjektet mindre.

To jobber som deler et navn

Å aktivere en lagret profil betyr å si til en eksisterende tunnel at den skal komme opp: en vert, en påloggingsdetalj, en protokoll, alt allerede konfigurert et sted brukeren kan se. Å bygge en tunnel betyr at koden din eier grensesnittet, pakkeløkken og protokollen. De ser like ut i en produktbacklog, og de deler nesten ingen implementasjon.

Ingen av mobilplattformene eksponerer den første for en SDK-app. En tilkobling som dukker opp uten at brukeren gjør noe, kan ikke skilles fra skadevare, så begge systemene setter en samtykkeport foran enhver app som bærer trafikk.

Android: en samtykkeport og ingen profil-API

VpnService har eksistert siden Android 4.0 og lar en app lage et tun-grensesnitt og deretter lese og skrive pakker. Tjenesten må deklareres med BIND_VPN_SERVICE, og VpnService.prepare() lager systemdialogen som ber brukeren tillate det. Plattformprøven ToyVpn er den klareste erklæringen av den tiltenkte formen: koden din eier grensesnittet og alt som strømmer gjennom det.

Det den ikke gjør, er å legge til en oppføring på systemets VPN-innstillingsskjerm. Det finnes ingen offentlig API for det, og Innstillinger-appen holder profilene sine i et lager en vanlig app ikke når. Kall til de skjulte klassene fra en normal applikasjon gir profiler systemet aldri lister opp, og derfor slutter kode som så ut til å virke i én bygging stille å virke i den neste.

Den administrerte veien er separat. En enhetseier eller profileier kan peke ut en alltid påslått VPN-pakke gjennom enhetspolicy-API-ene, og et bedriftsverktøy kan skyve ut en profil som brukeren deretter godkjenner. Det er enhetsadministrasjonsmyndighet, ikke en tillatelse en app ber om ved installasjon. Hvis kunden din er en organisasjon, er dette veien du må planlegge for; hvis kunden din er en person som installerer fra en butikk, er den ikke tilgjengelig i det hele tatt.

iOS: rettigheten er grensen

iOS deler den samme jobben annerledes. En VPN-klient implementerer en pakketunnel-leverandør eller en app-proxy under Network Extension-rammeverket, og den tilsvarende rettigheten må gis til utviklerkontoen. En personlig VPN-konfigurasjon gjennom NEVPNManager finnes for det enklere tilfellet, og den kjører fortsatt innenfor samme tillatelsesmodell. Apple dokumenterer hele overflaten i Network Extension-referansen, som er verdt å lese før du avgrenser arbeidet.

Det finnes ingen støttet måte å åpne VPN-innstillingsskjermen, lese brukerens lagrede konfigurasjoner eller starte en av dem. Det en klient kan gjøre, er å sende en konfigurasjonsprofil som brukeren installerer, og deretter bruke den resulterende tunnelen gjennom vanlige nettverkskall. Tunneling per app tildeles av en MDM-server gjennom en on-demand-regel, ikke valgt av appen ved kjøring.

En VPN-klient fra en stor leverandør er ikke bevis for at kontoen din kan sende det samme. Disse rettighetene bes om per utviklerkonto og gjennomgås, så tidsplanrisikoen ligger hos Apple, ikke i sprintplanen din.

Skrivebordet når lenger, men eierskapet er uendret

Windows er det tillatende tilfellet. Add-VpnConnection oppretter en telefonbokoppføring fra en forhøyet PowerShell-økt, og rasdial kobler den til eller fra i et skript. En app kan også styre en leverandørklient gjennom dens dokumenterte kommandolinje. Å opprette profilen er fortsatt en administrativ handling, fordi oppføringen ligger i et lager for hele maskinen.

macOS oppfører seg likt med andre verktøy. scutil --nc start og stop arbeider på tjenester som allerede finnes, mens det å opprette en er en systemadministrasjonsoppgave. Å eie prosessen på en bærbar PC gjør deg ikke til eier av konfigurasjonen.

Hva du bør bygge i stedet

Hvis det egentlige kravet er at appen din når en intern API, er tunnelen brukeren allerede kjører nok. Send vanlige HTTPS-forespørsler, la systemet velge veien, og slutt å prøve å kontrollere tunnelen. Hvis kravet er at bare appens trafikk bruker tunnelen, be om VPN per app gjennom administrasjonskanalen, eller avslutt TLS inne i appen mot en tjeneste som er tilgjengelig uten.

Skjulte API-er er ikke en snarvei som er verdt å ta. De endrer seg mellom utgivelser, de feiler i appgjennomgang, og feilene de produserer ser for den som arver koden ut som vanlige nettverksfeil. Sammenligningen er ikke Android mot iOS; det er å eie en tunnel mot å be plattformen rute trafikk, og bare den første er din å bygge.