NEVPNManager-stoor misluk? Die volgorde is laai, aktiveer, stoor, koppel

Twee foutkodes verantwoord vir die meeste eerste pogings tot ’n Network Extension VPN op iOS: NEVPNErrorDomain Code=4 en Code=5. Nie een daarvan is ’n bedienerklag nie. Die een verskyn wanneer die app instellings in ’n objek skryf wat nooit van skyf gelees is nie, en die ander wanneer die skryf self misluk, meestal omdat die profiel gestoor word terwyl dit nog gedeaktiveer is. Albei word reggemaak deur die volgorde van vier oproepe te verander, nie deur aan die IKEv2-parameters te raak nie.

Laai eers, anders het die stoor niks om teen te vergelyk

Die bestuurder hou ’n kopie van die gestoorde profiel, en die objek wat jy redigeer is nie daardie kopie voordat jy dit lees nie. Roep loadFromPreferences eerste, redigeer binne sy voltooiingshandler en stoor dan. Slaan die lees oor en die raamwerk sien ’n wanverhouding tussen wat dit het en wat jy skryf. In Swift is die vorm vir elke stap dieselfde, en elke stap hoort in sy eie 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
    }
}

Om die tonnel van binne die stoor-closure te begin is dieselfde fout op ’n ander plek. Dit loop voordat die profiel weer gelees is, so die begin-oproep sien die toestand wat jy gebou het eerder as die toestand wat gestoor is. Die stoor-closure eindig met ’n tweede loadFromPreferences, en net daardie voltooiingshandler roep startVPNTunnel.

Die aktiveringsvlag is deel van die stoor

’n Gestoorde profiel is onaktief totdat dit aangeskakel word. Stel isEnabled = true in dieselfde skryf, of die profiel beland gedeaktiveer op skyf en startVPNTunnel weier selfs al wys Instellings ’n konfigurasie wat volledig lyk.

Eksterne redigerings is die ander helfte hiervan. As die gebruiker iets in Instellings verander, of die toestel tussen netwerke beweeg, lees weer voordat jy die waardes vertrou wat jy nog in geheue hou. Die objek neem nie daardie veranderinge vir jou waar nie. ’n Verouderde kopie is hoe ’n app ’n profiel skryf wat die gebruiker se redigering stilweg terugdraai. Twee aangrensende velde veroorsaak op dieselfde oomblik stil moeilikheid: on-demand-reëls moet ’n skikking van reëlobjekte wees eerder as ’n leë plekhouer, en disconnectOnSleep moet die gedrag weerspieël wat jy gekies het eerder as ’n gekopieerde verstekwaarde.

Net twee protokolle is vir derdeparty-apps beskikbaar

Network Extension gee apps IPsec en IKEv2. L2TP en PPTP bly binne die stelsel, so ’n app wat hulle nodig het kan hulle nie kry nie, en die realistiese antwoorde is ’n IKEv2-geskikte poort of ’n bestuurde konfigurasieprofiel.

Geloofsbriewe volg dieselfde patroon. Sit die wagwoord in die Keychain en gee ’n blywende verwysing deur eerder as die string. ’n Nul-verwysing tydens stoor beteken gewoonlik dat die opsoek geloop het voordat die item geskryf is, nie dat die bestuurder stukkend is nie.

Albei is ontwerpbesluite eerder as noodoplossings. ’n App wat die wagwoord in sy eie voorkeure hou, kies ’n pad wat die raamwerk afraai, en die mislukking wat dit lewer lees soos ’n stoorfout.

Skakel die entitlement uit voordat jy kode herskryf

Wanneer loadFromPreferences glad nie terugroep nie, is die waarskynlike oorsaak ’n ontbrekende Network Extension-vermoë of ’n voorsieningsprofiel wat dit nie dra nie. Daardie mislukking hang eerder as om ’n fout te gee, en daarom word werkende kode vir ure herskryf. Kyk na die entitlement op die ondertekende bou wat jy van plan is om te lewer, want ’n simuleerderloop en ’n toestelloop kan verskil en die teiken wat saak maak is die toestel. Maak die teiken se ondertekeningsinstellings oop en bevestig dat die Network Extension-vermoë vir daardie presiese bou teenwoordig is.

’n Voorsieningsprofiel sonder die entitlement misluk op hardeware op dieselfde manier, terwyl dieselfde bou normaal in die simuleerder kan laai. Toets die ondertekende argief op ’n werklike toestel voordat jy die oproepvolgorde herskryf.

Kyk na die statusveranderinge, nie na aannames nie

Let op NEVPNStatusDidChangeNotification en teken manager.connection.status na elke stap aan. ’n Status wat nooit invalid verlaat nie beteken die profiel is nie gestoor nie of die entitlement ontbreek. ’n Verbinding wat connecting bereik en nooit koppel nie, wys op die voorstel of die geloofsbriewe, wat ’n ander ondersoek met ander bewyse is.

Bevestig die profiel verskyn onder Instellings, Algemeen, VPN, en teken die fout uit elke closure aan. Daardie twee feite skei ’n volgordefout van ’n magtigingsfout sonder raaiwerk.