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

To meget forskellige opgaver havner under betegnelsen programmatisk VPN, og kun den ene er tilgængelig for en almindelig app på nogen af de to mobile platforme. Den første er at slå en profil til, som brugeren allerede har gemt; den anden er at bygge en tunnel inde i din egen proces. Android giver dig den anden gennem VpnService, og iOS giver dig den anden gennem rettigheden Network Extension, mens den første bliver hos systemet, en enhedsejer eller en MDM-server. At finde ud af, hvilken du faktisk har brug for, gør som regel projektet mindre.

To opgaver, der deler et navn

At aktivere en gemt profil betyder at bede en eksisterende tunnel om at komme op: en vært, en adgangsoplysning, en protokol, alt allerede konfigureret et sted, brugeren kan se. At bygge en tunnel betyder, at din kode ejer grænsefladen, pakkeløkken og protokollen. De ser ens ud i en produktbacklog, og de deler næsten ingen implementering.

Ingen af de mobile platforme udstiller den første til en SDK-app. En forbindelse, der dukker op, uden at brugeren gør noget, kan ikke skelnes fra malware, så begge systemer sætter en samtykkeport foran enhver app, der bærer trafik.

Android: en samtykkeport og ingen profil-API

VpnService har eksisteret siden Android 4.0 og lader en app oprette en tun-grænseflade og derefter læse og skrive pakker. Tjenesten skal deklareres med BIND_VPN_SERVICE, og VpnService.prepare() frembringer systemdialogen, der beder brugeren om at tillade det. Platformsprøven ToyVpn er den klareste erklæring af den tilsigtede form: din kode ejer grænsefladen og alt, hvad der strømmer gennem den.

Det, den ikke gør, er at tilføje en post på systemets VPN-indstillingsskærm. Der findes ingen offentlig API til det, og appen Indstillinger holder sine profiler i et lager, som en almindelig app ikke kan nå. Kald til de skjulte klasser fra en normal applikation giver profiler, som systemet aldrig viser, og derfor holder kode, der så ud til at virke i et build, stille op med at virke i det næste.

Den administrerede vej er separat. En enhedsejer eller profilejer kan udpege en altid-tændt VPN-pakke gennem enhedspolitik-API'erne, og et virksomhedsværktøj kan skubbe en profil ud, som brugeren derefter godkender. Det er enhedsadministrationsbeføjelse, ikke en tilladelse, en app anmoder om ved installation. Hvis din kunde er en organisation, er det den vej, du skal planlægge efter; hvis din kunde er en person, der installerer fra en butik, er den slet ikke tilgængelig.

iOS: rettigheden er grænsen

iOS deler det samme arbejde anderledes. En VPN-klient implementerer en pakketunneludbyder eller en app-proxy under Network Extension-rammen, og den tilsvarende rettighed skal tildeles udviklerkontoen. En personlig VPN-konfiguration gennem NEVPNManager findes til det enklere tilfælde, og den kører stadig inden for den samme tilladelsesmodel. Apple dokumenterer hele overfladen i Network Extension-referencen, som er værd at læse, før du afgrænser arbejdet.

Der er ingen understøttet måde at åbne VPN-indstillingsskærmen, læse brugerens gemte konfigurationer eller starte en af dem. Det, en klient kan gøre, er at sende en konfigurationsprofil, som brugeren installerer, og derefter bruge den resulterende tunnel gennem almindelige netværkskald. Tunneling per app tildeles af en MDM-server gennem en on-demand-regel, ikke valgt af appen ved kørsel.

En VPN-klient fra en stor leverandør er ikke bevis for, at din konto kan sende det samme. De rettigheder anmodes om per udviklerkonto og gennemgås, så tidsplanrisikoen ligger hos Apple, ikke i din sprintplan.

Skrivebordet når længere, men ejerskabet er uændret

Windows er det tilladende tilfælde. Add-VpnConnection opretter en telefonbogspost fra en forhøjet PowerShell-session, og rasdial forbinder eller afbryder den fra et script. En app kan også styre en leverandørklient gennem dens dokumenterede kommandolinje. At oprette profilen er stadig en administrativ handling, fordi posten ligger i et lager for hele maskinen.

macOS opfører sig på samme måde med andre værktøjer. scutil --nc start og stop arbejder på tjenester, der allerede findes, mens det at oprette en er en systemadministrationopgave. At eje processen på en bærbar gør dig ikke til ejer af konfigurationen.

Hvad du bør bygge i stedet

Hvis det egentlige krav er, at din app når en intern API, er den tunnel, brugeren allerede kører, nok. Send almindelige HTTPS-anmodninger, lad systemet vælge vejen, og hold op med at prøve at styre tunnelen. Hvis kravet er, at kun din apps trafik bruger tunnelen, bed om VPN per app gennem administrationskanalen, eller afslut TLS inde i appen mod en tjeneste, der kan nås uden.

Skjulte API'er er ikke en genvej, der er værd at tage. De ændrer sig mellem udgivelser, de fejler app-gennemgang, og de fejl, de frembringer, ser for den, der arver koden, ud som almindelige netværksfejl. Sammenligningen er ikke Android mod iOS; det er at eje en tunnel mod at bede platformen om at rute trafik, og kun den første er din at bygge.