NEVPNManager lagrar ikkje? Rekkjefølgja er last, aktiver, lagre, kople til

To feilkodar forklarar dei fleste første forsøka med ein Network Extension VPN på iOS: NEVPNErrorDomain Code=4 og Code=5. Ingen av dei er ei klage frå tenaren. Den eine viser seg når appen skriv innstillingar inn i eit objekt som aldri vart lese frå disken, og den andre når sjølve skrivinga feilar, oftast fordi profilen vert lagra medan han framleis er deaktivert. Begge vert retta ved å endre rekkjefølgja på fire kall, ikkje ved å røre IKEv2-parametrane.

Last først, elles har lagringa ingenting å samanlikne med

Handsamaren held ein kopi av den lagra profilen, og objektet du redigerer er ikkje den kopien før du les han. Kall loadFromPreferences først, rediger inne i fullføringshandsamaren og lagre deretter. Hoppar du over lesinga, ser rammeverket eit avvik mellom det det har og det du skriv. I Swift er forma den same for kvart steg, og kvart steg høyrer til sin eigen 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
    }
}

Å starte tunnelen inne frå lagre-closuren er den same feilen ein annan stad. Det køyrer før profilen er lesen på nytt, så startkallet ser tilstanden du bygde og ikkje tilstanden som vart lagra. Lagre-closuren endar med ein andre loadFromPreferences, og berre den fullføringshandsamaren kallar startVPNTunnel.

Aktiveringsflagget er ein del av lagringa

Ein lagra profil er inaktiv til han vert slått på. Set isEnabled = true i same skrivinga, elles hamnar profilen deaktivert på disken og startVPNTunnel nektar sjølv om Innstillingar viser ein konfigurasjon som ser komplett ut.

Eksterne redigeringar er den andre halvdelen. Viss brukaren endrar noko i Innstillingar, eller eininga flyttar seg mellom nettverk, les på nytt før du stolar på verdiane du framleis held i minnet. Objektet observerer ikkje desse endringane for deg. Ein utdatert kopi er måten ein app skriv ein profil som stille rullar tilbake redigeringa til brukaren. To tilstøytande felt skapar stille problem i same augneblink: on-demand-reglar må vere ein matrise med regelobjekt og ikkje ein tom plasshaldar, og disconnectOnSleep bør spegle åtferda du valde og ikkje ein kopiert standardverdi.

Berre to protokollar er tilgjengelege for tredjepartsappar

Network Extension gir appar IPsec og IKEv2. L2TP og PPTP blir inne i systemet, så ein app som treng dei kan ikkje få dei, og dei realistiske svara er ein IKEv2-kompatibel gateway eller ein administrert konfigurasjonsprofil.

Påloggingsinformasjon følgjer same mønster. Legg passordet i Keychain og send ei varig referanse i staden for strengen. Ei nullreferanse ved lagring tyder vanlegvis at oppslaget køyrde før elementet vart skrive, ikkje at handsamaren er øydelagd.

Begge er designval og ikkje omvegar. Ein app som held passordet i eigne innstillingar vel ein veg rammeverket frårår, og feilen han produserer vert lesen som ein lagringsfeil.

Utelukk retten før du skriv om koden

Når loadFromPreferences aldri kallar tilbake, er den sannsynlege årsaka ein manglande Network Extension-funksjon eller ein provisjoneringsprofil som ikkje ber han. Den feilen heng i staden for å gje ein feil, og difor vert fungerande kode skriven om i timar. Sjekk retten på den signerte bygginga du vil levere, fordi ein simulatorøyring og ei einingøyring kan vere ulike og målet som tel er eininga. Opne signeringsinnstillingane til målet og stadfest at Network Extension-funksjonen finst for akkurat den bygginga.

Ein provisjoneringsprofil utan retten feilar på same måte på maskinvare, medan same bygging kan lastast normalt i simulatoren. Test det signerte arkivet på ei ekte eining før du skriv om rekkjefølgja på kalla.

Følg med på statusendringane, ikkje på antakingar

Observer NEVPNStatusDidChangeNotification og logg manager.connection.status etter kvart steg. Ein status som aldri forlèt invalid tyder at profilen ikkje vart lagra eller at retten manglar. Ei tilkopling som når connecting og aldri koplar til, peikar på forslaget eller påloggingsinformasjonen, og det er ei anna gransking med andre bevis.

Stadfest at profilen viser seg under Innstillingar, Generelt, VPN, og noter feilen frå kvar closure. Dei to fakta skil ein rekkjefølgjefeil frå ein løyvefeil utan gissing.