VPN-APIs unter iOS: NEVPNManager, Tunnelanbieter oder Profil?

Drei verschiedene Produkte hören auf den Namen VPN unter iOS, und sie teilen sich keine API. Persönliches VPN fährt auf den eingebauten Transportern IPsec und IKEv2 des Systems. Ein eigener Tunnel führt Ihr Protokoll in einer Netzwerkerweiterung aus. Und ein Konfigurationsprofil konfiguriert beide und kann Verhalten bei Bedarf ergänzen. Die Wahl nach dem Transport, den Sie sprechen müssen, ist schneller als die Wahl nach dem Tutorium, das zuerst kompiliert wurde.

Führen Sie die folgenden Prüfungen der Reihe nach aus, denn jeder Schritt setzt voraus, dass der vorige eine gültige Konfiguration ergeben hat.

Schritt 1: nach Transport wählen

Ist der Server IKEv2 oder IPsec im Cisco-Stil, genügt NEVPNManager, und die Systemtransporter gibt es gratis. Spricht der Server OpenVPN, WireGuard oder etwas anderes, kann NEVPNManager nicht helfen: es hat keinen Haken für ein Protokoll von Drittanbietern. Dieser Fall braucht NETunnelProviderManager mit einem Pakettunnel-Anbieter, der das Protokoll umsetzt. Ein Profil verteilt nur Konfiguration und kann keinen Transport hinzufügen, den das Betriebssystem nicht hat.

PPTP ist auf aktuellen Systemen kein Ziel. IPsec mit gemeinsamem Geheimnis erwartet weiterhin den Gruppennamen in remoteIdentifier, einen Schlüsselbund-Eintrag mit dem Geheimnis und erweiterte Authentifizierung, wenn der Server einen Benutzernamen verlangt. Jedes fehlende Teil erscheint als derselbe allgemeine Konfigurationsfehler, also fügen Sie alle hinzu, bevor Sie irgendetwas anderes debuggen.

Schritt 2: die Reihenfolge Speichern, Laden, Starten einhalten

NEVPNManager schreibt in die Einstellungen, liest sie zurück und startet erst dann. Füllen Sie die Protokoll- und Manager-Objekte, rufen Sie saveToPreferences, rufen Sie loadFromPreferences und rufen Sie startVPNTunnel aus dem Abschlusshandler des Ladens. Ein Start, bevor das Laden zurückkehrt, erzeugt einen Fehler wegen ungültiger Konfiguration, Code 1 in NEVPNErrorDomain, bei einer sonst korrekten Konfiguration.

Die Form ist kurz genug, um sie an einer Stelle zu halten:

manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }

startVPNTunnel kehrt zurück, wenn die Anfrage angenommen ist, nicht wenn der Tunnel steht. Beobachten Sie NEVPNStatusDidChange und lesen Sie connection.status für den echten Zustand. Eine App, die an der Aufrufstelle Erfolg annimmt, meldet ein verbundenes VPN, während die Erweiterung noch verhandelt. Ein Status Verbinden ist für einen Moment normal; ein Status, der ihn nie verlässt, ist der Fehler, der es wert ist, protokolliert zu werden.

Schritt 3: dem Anbieterprozess geben, was er braucht

Ein eigener Transport läuft in einem separaten Prozess mit eigener Bundle-ID und eigener Berechtigung. Sowohl die Container-App als auch der Anbieter brauchen die Netzwerkerweiterungs-Berechtigung beim Signieren, und ein Developer-ID-Build außerhalb des App Store muss sie weiterhin im Provisioning-Profil tragen. Eine fehlende Berechtigung sieht wie ein Protokollfehler aus, weil die Erweiterung schlicht nicht startet.

Es gibt keinen öffentlichen Socket-Deskriptor zum Ausleihen. NEPacketTunnelProvider gibt Ihnen NEPacketTunnelFlow mit read, write und cancel, und Code, der nach privaten Schlüsselpfaden greift, bricht zwischen Releases. Der Anbieter läuft weiter, während die App im Hintergrund ist, also braucht der Container dafür keinen Hintergrundmodus.

Schritt 4: bei Bedarf ist eine Regelmenge, kein Schalter

isOnDemandEnabled scharfschaltet nur die Regeln; NEOnDemandRuleConnect und seine Geschwister entscheiden, wann der Tunnel hochkommt. Eine Regel zur Verbindungsbewertung mit einer Probe-URL ist nur so gut wie diese URL. Antwortet die Probe ohne den Tunnel, schließt die Regel, dass das private Netz bereits erreichbar ist, und verbindet nie, also richten Sie sie auf etwas, das nur von innen antwortet.

Immer-an ist ein separates Versprechen. Es braucht ein überwachtes Gerät und ein verwaltetes Profil, und ein nicht überwachter Benutzer kann ein Profil jederzeit entfernen. Liefern Sie kein Design, das von Immer-an abhängt, es sei denn, der Gerätebestand ist überwacht.

Schritt 5: den Weg belegen, nicht das Etikett

Nach tun-, tap-, ppp- oder ipsec-Schnittstellen zu scannen belegt, dass ein VPN konfiguriert ist, nicht dass Ihre Anfrage es benutzt hat. NWPathMonitor mit usesInterfaceType(.other) sagt, dass eine virtuelle Schnittstelle verfügbar ist, und ein Viabilitätshandler kann einen Host testen. Keines von beiden belegt den Ausgangspfad, also kombinieren Sie sie mit einer Anfrage an eine Ressource, die nur der Tunnel erreicht. Schnittstellennamen sind eine Diagnosehilfe, nie ein Tor, auf das Anwendungslogik verzweigen sollte.

Für eine Feldprüfung vergleichen Sie die öffentliche Adresse mit und ohne Tunnel und laden Sie eine nur intern erreichbare Seite. Ein Statusaufruf kann verbunden melden, während der Anbieter verhandelt, also lassen Sie das Ergebnis der Ressource entscheiden und behandeln Sie den Status als stützenden Beleg.