NEVPNManager speichert nicht? Die Reihenfolge ist laden, aktivieren, sichern, verbinden

Zwei Fehlercodes erklären die meisten ersten Versuche mit einem Network Extension VPN unter iOS: NEVPNErrorDomain Code=4 und Code=5. Keiner davon ist eine Beschwerde des Servers. Der eine erscheint, wenn die App Einstellungen in ein Objekt schreibt, das nie von der Platte gelesen wurde, der andere, wenn der Schreibvorgang selbst scheitert, meist weil das Profil gesichert wird, während es noch deaktiviert ist. Beide lassen sich durch eine geänderte Reihenfolge von vier Aufrufen beheben, nicht durch Eingriffe in die IKEv2-Parameter.

Zuerst laden, sonst hat das Sichern nichts zum Vergleichen

Der Manager hält eine Kopie des gesicherten Profils, und das Objekt, das Sie bearbeiten, ist diese Kopie erst, wenn Sie sie gelesen haben. Rufen Sie zuerst loadFromPreferences auf, bearbeiten Sie im Completion-Handler und sichern Sie dann. Überspringen Sie das Lesen, sieht das Framework eine Diskrepanz zwischen dem, was es hat, und dem, was Sie schreiben. In Swift ist die Form für jeden Schritt gleich, und jeder Schritt gehört in seinen eigenen Closure:

let mgr = NEVPNManager.shared()
mgr.loadFromPreferences { loadErr in
    guard loadErr == nil else { return }
    let proto = NEVPNProtocolIKEv2()
    proto.serverAddress = "vpn.example.net"
    proto.username = "alice"
    proto.useExtendedAuthentication = true
    mgr.protocolConfiguration = proto
    mgr.isEnabled = true
    mgr.saveToPreferences { saveErr in
        // do not start here; reload, then connect
    }
}

Den Tunnel aus dem Sicherungs-Closure heraus zu starten ist derselbe Fehler an anderer Stelle. Er läuft, bevor das Profil erneut gelesen wurde, sodass der Startaufruf den Zustand sieht, den Sie gebaut haben, und nicht den gesicherten Zustand. Der Sicherungs-Closure endet mit einem zweiten loadFromPreferences, und nur dieser Completion-Handler ruft startVPNTunnel auf.

Das Aktivierungsflag gehört zum Sichern

Ein gesichertes Profil ist wirkungslos, bis es eingeschaltet wird. Setzen Sie isEnabled = true im selben Schreibvorgang, sonst landet das Profil deaktiviert auf der Platte und startVPNTunnel verweigert, obwohl die Einstellungen eine vollständig wirkende Konfiguration zeigen.

Externe Änderungen sind die andere Hälfte. Wenn der Nutzer etwas in den Einstellungen ändert oder das Gerät zwischen Netzen wechselt, lesen Sie erneut, bevor Sie den Werten trauen, die Sie noch im Speicher halten. Das Objekt beobachtet diese Änderungen nicht für Sie. Eine veraltete Kopie ist der Weg, auf dem eine App ein Profil schreibt, das die Nutzeränderung still zurücksetzt. Zwei benachbarte Felder verursachen im selben Moment stille Probleme: On-Demand-Regeln müssen ein Array von Regelobjekten sein und kein leerer Platzhalter, und disconnectOnSleep sollte das von Ihnen gewählte Verhalten widerspiegeln und keinen kopierten Standardwert.

Nur zwei Protokolle stehen Drittanbieter-Apps zur Verfügung

Network Extension gibt Apps IPsec und IKEv2. L2TP und PPTP bleiben im System, eine App, die sie braucht, kann sie also nicht bekommen, und die realistischen Antworten sind ein IKEv2-fähiges Gateway oder ein verwaltetes Konfigurationsprofil.

Zugangsdaten folgen demselben Muster. Legen Sie das Passwort in den Keychain und übergeben Sie eine persistente Referenz statt der Zeichenkette. Eine Null-Referenz beim Sichern bedeutet meist, dass die Suche lief, bevor der Eintrag geschrieben wurde, und nicht, dass der Manager defekt ist.

Beides sind Designentscheidungen und keine Behelfe. Eine App, die das Passwort in ihren eigenen Voreinstellungen hält, wählt einen Weg, den das Framework missbilligt, und der Fehler, den sie erzeugt, liest sich wie ein Sicherungsfehler.

Schließen Sie die Entitlement-Berechtigung aus, bevor Sie Code umschreiben

Wenn loadFromPreferences überhaupt nicht zurückruft, ist die wahrscheinliche Ursache eine fehlende Network Extension-Fähigkeit oder ein Provisioning-Profil, das sie nicht trägt. Dieser Fehler hängt, statt einen Fehler zu melden, und deshalb wird funktionierender Code stundenlang umgeschrieben. Prüfen Sie die Berechtigung am signierten Build, das Sie ausliefern wollen, denn ein Simulatorlauf und ein Gerätelauf können sich unterscheiden, und das Ziel, auf das es ankommt, ist das Gerät. Öffnen Sie die Signierungseinstellungen des Ziels und bestätigen Sie, dass die Network Extension-Fähigkeit für genau dieses Build vorhanden ist.

Ein Provisioning-Profil ohne die Berechtigung scheitert auf Hardware genauso, während dasselbe Build im Simulator normal laden kann. Testen Sie das signierte Archiv auf einem echten Gerät, bevor Sie die Aufrufreihenfolge umschreiben.

Beobachten Sie die Statusänderungen, nicht Annahmen

Beobachten Sie NEVPNStatusDidChangeNotification und protokollieren Sie manager.connection.status nach jedem Schritt. Ein Status, der invalid nie verlässt, bedeutet, dass das Profil nicht gesichert wurde oder die Berechtigung fehlt. Eine Verbindung, die connecting erreicht und nie verbindet, deutet auf den Vorschlag oder die Zugangsdaten hin, und das ist eine andere Untersuchung mit anderen Belegen.

Bestätigen Sie, dass das Profil unter Einstellungen, Allgemein, VPN erscheint, und notieren Sie den Fehler aus jedem Closure. Diese zwei Tatsachen trennen einen Reihenfolgefehler von einem Berechtigungsfehler ohne Raten.