Warum Ihre iPhone-App das System-VPN nicht ein- oder ausschalten kann

Ein Produktmanager bittet um einen Knopf, der das Firmen-VPN einschaltet, und die Anfrage klingt trivial. Auf iOS ist das keine kleine Funktion; sie liegt außerhalb des öffentlichen Vertrags, und jeder Workaround scheitert entweder im Review oder bricht im nächsten Release. Führen Sie die Anfrage durch das, was die Plattform tatsächlich erlaubt, und das Design schreibt sich weitgehend selbst. Eine App kann eine VPN-Konfiguration besitzen und sie starten. Eine App erreicht den Systemschalter nicht, kann den Status eines Profils nicht lesen, das sie nicht selbst erstellt hat, und kann einen Nutzer nicht gegen seinen Willen verbunden halten.

Beginnen Sie bei den drei Dingen, die der Nutzer meint

Trennen Sie die Bedeutungen, bevor Sie die APIs trennen. Manchmal will der Nutzer den Tunnel Ihrer App verbunden, manchmal will er den Schalter in den Einstellungen für ein Profil umlegen, das jemand anderes installiert hat, und manchmal will er, dass das Telefon ohne den Tunnel nicht surfen kann. Das entspricht drei verschiedenen Mechanismen, und nur der erste steht einer gewöhnlichen App offen.

Die zweite Bedeutung erzeugt die Stack-Overflow-Fragen, und sie hat keine unterstützte Antwort. Der Schalter in den Einstellungen gehört dem Nutzer und auf verwalteten Geräten dem Profil. Keine öffentliche API listet VPN-Konfigurationen auf, meldet, ob der Systemtunnel steht, oder schaltet ihn um.

Was eine App tatsächlich anlegen kann

NetworkExtension gibt einer App über NEVPNManager eine eigene Konfiguration. Mit der Personal-VPN-Berechtigung und der Zustimmung des Nutzers speichert die App eine Konfiguration, die in den Einstellungen unter ihrem eigenen Namen erscheint, und sie kann genau diese eine Verbindung starten oder stoppen. Das ist eine echte, prüfbare Fähigkeit, und es ist zugleich der ganze Umfang: Der Manager liest und schreibt nur, was er selbst angelegt hat.

Die Berechtigung ist nicht automatisch. Sie beantragen sie bei Apple und begründen, warum die App überhaupt einen Tunnel braucht, und ein Client, dessen einziges Ziel es ist, ein fremdes Profil einzuschalten, hat darauf keine gute Antwort. Paket-Tunnel-Anbieter folgen derselben Regel mit einer anderen Klasse: NETunnelProviderManager besitzt anbieterbasierte Konfigurationen, die die App selbst installiert hat. Keiner der beiden Wege erreicht ein Profil, das MDM ausgeliefert hat.

Die Zustimmung gilt auch beim Speichern. Das Schreiben einer Konfiguration fragt den Nutzer, und diese Abfrage darf eine App nicht aus Bequemlichkeit unterdrücken.

Das Lesen des Status stößt an dieselbe Wand

Status wirkt freundlicher als Steuerung und ist genauso verschlossen. NEVPNStatus meldet ungültig, getrennt, verbindend, verbunden, erneut bestätigend oder trennend für die eigene Konfiguration der App, und bei jeder Änderung wird eine Mitteilung ausgelöst. Über einen Tunnel, den ein Verwaltungsprofil installiert hat, sagt er nichts, und genau den Zustand will ein Helpdesk sehen.

Netzwerkpfad-Überwachung und Schnittstellenänderungen werden in Design-Reviews als Ersatz angeboten. Sie beschreiben den Pfad, den der Verkehr der App nimmt, und der ändert sich aus Gründen, die nichts mit dem VPN-Status zu tun haben, und sie als VPN-Anzeige zu verwenden liefert eine Oberfläche, die in beide Richtungen lügt.

On Demand und Always On sind die echten Hebel

Die unterstützten Hebel leben im Profil und nicht in der App. On-Demand-Regeln sagen dem System, wann es sich verbinden soll: eine geordnete Liste von Bedingungen mit Aktionen, ausgewertet vom Betriebssystem, nicht von Ihrem Code. Eine Regel, die an jeder Schnittstelle verbindet, erzeugt ein Immer-verbunden-Gefühl, ohne einer App irgendeine Kontrolle zu geben.

Always On VPN ist der Durchsetzungsmechanismus, und er ist an die Überwachung gebunden. Auf einem überwachten Gerät installiert MDM ein Profil, das den Tunnel oben hält; auf einem nicht überwachten persönlichen Telefon erzeugen dieselben Schlüssel nicht dasselbe Verhalten. Diese Asymmetrie ist beabsichtigt, und keine Kombination von Payload-Schlüsseln hebt sie auf. Wenn die Anforderung wirklich ist, dass das VPN an sein muss, ist die Anforderung in Wahrheit, dass das Gerät verwaltet sein muss.

Dazwischen sitzt der schwächere Vetter: eine Regel, die nach dem Trennen des Nutzers erneut verbindet. Sie verbindet bei der nächsten Auswertung der Regel, was nicht dasselbe ist wie sofort, und ein Nutzer, der absichtlich getrennt hat, wird den Unterschied bemerken. Gestalten Sie die Oberfläche um diese Lücke herum, statt ein Schloss zu versprechen.

Liefern Sie den unterstützten Weg

Vier Fragen klären den Mechanismus, bevor es Code gibt: wem das Gerät gehört, ob es überwacht ist, welcher Client den Tunnel beendet und woher das Profil kommt. Ist eines davon unbekannt, ist die Funktionsanfrage nicht schätzbar.

Eine private API, die am System-VPN herumstochert, besteht eine Demo und fällt im Review durch, und wenn sie auf anderem Weg ausgeliefert wird, bricht sie im nächsten iOS-Release. Es gibt keine Version dieses Tauschs, die für einen Schalter lohnt.

Verwaltungstelemetrie ist ein eigener Kanal: Sie meldet, dass ein Profil installiert ist und ob das Gerät konform ist, was Berichterstattung und keine Steuerungsfläche pro App ist. Testen Sie den Ablauf nach jedem Update auf einem echten Gerät, denn das unterstützte Verhalten lebt im Betriebssystem, und das Betriebssystem bewegt sich.