Warum eine App ein gespeichertes VPN-Profil unter Android oder iOS nicht einschalten kann

Zwei sehr verschiedene Aufgaben werden unter dem Begriff programmatisches VPN geführt, und nur eine davon steht einer gewöhnlichen App auf einer der beiden Mobilplattformen zur Verfügung. Die erste ist, ein Profil einzuschalten, das der Nutzer bereits gespeichert hat; die zweite ist, einen Tunnel im eigenen Prozess zu bauen. Android gibt Ihnen die zweite über VpnService, und iOS gibt Ihnen die zweite über die Berechtigung Network Extension, während die erste beim System, einem Geräteeigentümer oder einem MDM-Server bleibt. Herauszufinden, welche Sie wirklich brauchen, macht das Projekt meist kleiner.

Zwei Aufgaben mit einem Namen

Ein gespeichertes Profil zu aktivieren heißt, einem bestehenden Tunnel zu sagen, dass er hochkommen soll: ein Host, ein Zugangsdatum, ein Protokoll, alles bereits an einer Stelle konfiguriert, die der Nutzer sehen kann. Einen Tunnel zu bauen heißt, dass Ihr Code die Schnittstelle, die Paketschleife und das Protokoll besitzt. Im Produkt-Backlog sehen sie ähnlich aus, und sie teilen fast keine Implementierung.

Keine der beiden Mobilplattformen legt die erste einem SDK-App offen. Eine Verbindung, die erscheint, ohne dass der Nutzer etwas tut, ist von Schadsoftware nicht zu unterscheiden, deshalb setzen beide Systeme ein Zustimmungsgate vor jede App, die Datenverkehr führt.

Android: ein Zustimmungsgate und keine Profil-API

VpnService existiert seit Android 4.0 und lässt eine App eine tun-Schnittstelle anlegen und dann Pakete lesen und schreiben. Der Dienst muss mit BIND_VPN_SERVICE deklariert werden, und VpnService.prepare() erzeugt den Systemdialog, der den Nutzer um Erlaubnis bittet. Das Plattformbeispiel ToyVpn ist die klarste Aussage über die beabsichtigte Form: Ihr Code besitzt die Schnittstelle und alles, was durch sie fließt.

Was er nicht tut, ist einen Eintrag auf dem VPN-Einstellungsbildschirm des Systems hinzuzufügen. Dafür gibt es keine öffentliche API, und die Einstellungen-App hält ihre Profile in einem Speicher, den eine gewöhnliche App nicht erreicht. Aufrufe der verborgenen Klassen aus einer normalen Anwendung erzeugen Profile, die das System nie auflistet, weshalb Code, der in einem Build zu funktionieren schien, im nächsten still aufhört zu funktionieren.

Der verwaltete Weg ist getrennt. Ein Geräteeigentümer oder Profileigentümer kann über die Geräterichtlinien-APIs ein immer aktives VPN-Paket bestimmen, und ein Unternehmenswerkzeug kann ein Profil ausrollen, das der Nutzer dann genehmigt. Das ist Geräteverwaltungsbefugnis, keine Berechtigung, die eine App bei der Installation anfragt. Ist Ihr Kunde eine Organisation, ist dies der Weg, für den Sie planen sollten; ist Ihr Kunde eine Person, die aus einem Store installiert, steht er überhaupt nicht zur Verfügung.

iOS: die Berechtigung ist die Grenze

iOS teilt dieselbe Arbeit anders auf. Ein VPN-Client implementiert einen Pakettunnel-Anbieter oder einen App-Proxy im Network Extension Framework, und die passende Berechtigung muss dem Entwicklerkonto gewährt werden. Eine persönliche VPN-Konfiguration über NEVPNManager existiert für den einfacheren Fall, und sie läuft weiterhin im selben Berechtigungsmodell. Apple dokumentiert die ganze Oberfläche in der Network Extension-Referenz, die man lesen sollte, bevor man den Aufwand absteckt.

Es gibt keinen unterstützten Weg, den VPN-Einstellungsbildschirm zu öffnen, die gespeicherten Konfigurationen des Nutzers zu lesen oder eine davon zu starten. Ein Client kann ein Konfigurationsprofil ausliefern, das der Nutzer installiert, und dann den entstandenen Tunnel über gewöhnliche Netzwerkaufrufe nutzen. App-übergreifendes Tunneling wird von einem MDM-Server über eine On-Demand-Regel zugewiesen, nicht von der App zur Laufzeit ausgewählt.

Ein VPN-Client eines großen Anbieters ist kein Beweis dafür, dass Ihr Konto dasselbe ausliefern kann. Diese Berechtigungen werden pro Entwicklerkonto beantragt und geprüft, das Terminrisiko liegt also bei Apple und nicht in Ihrem Sprintplan.

Der Desktop reicht weiter, aber der Besitz bleibt gleich

Windows ist der großzügige Fall. Add-VpnConnection legt einen Telefonbucheintrag aus einer erhöhten PowerShell-Sitzung an, und rasdial verbindet oder trennt ihn aus einem Skript. Eine App kann einen Anbieter-Client auch über dessen dokumentierte Kommandozeile steuern. Das Anlegen des Profils bleibt eine administrative Handlung, weil der Eintrag in einem maschinenweiten Speicher liegt.

macOS verhält sich mit anderen Werkzeugen gleich. scutil --nc start und stop arbeiten auf Diensten, die bereits existieren, während das Anlegen eines Dienstes eine Systemverwaltungsaufgabe ist. Den Prozess auf einem Laptop zu besitzen macht Sie nicht zum Eigentümer der Konfiguration.

Was stattdessen zu bauen ist

Wenn die eigentliche Anforderung ist, dass Ihre App eine interne API erreicht, genügt der Tunnel, den der Nutzer bereits laufen lässt. Stellen Sie normale HTTPS-Anfragen, lassen Sie das System den Weg wählen, und hören Sie auf, den Tunnel steuern zu wollen. Wenn die Anforderung ist, dass nur der Verkehr Ihrer App den Tunnel nutzt, fragen Sie per-App-VPN über den Verwaltungskanal an, oder beenden Sie TLS in der App gegenüber einem Dienst, der ohne erreichbar ist.

Versteckte APIs sind keine Abkürzung, die sich lohnt. Sie ändern sich zwischen Releases, sie scheitern an der App-Prüfung, und die Fehler, die sie erzeugen, sehen für den, der den Code erbt, wie gewöhnliche Netzwerkfehler aus. Der Vergleich ist nicht Android gegen iOS; es ist einen Tunnel zu besitzen gegen die Plattform zu bitten, Verkehr zu leiten, und nur das erste ist Ihre Sache zu bauen.