NEVPNManager lagrer ikke? Rekkefølgen er last, aktiver, lagre, koble til

To feilkoder forklarer de fleste første forsøk med en Network Extension VPN på iOS: NEVPNErrorDomain Code=4 og Code=5. Ingen av dem er en klage fra serveren. Den ene vises når appen skriver innstillinger inn i et objekt som aldri ble lest fra disken, og den andre når selve skrivingen feiler, oftest fordi profilen lagres mens den fortsatt er deaktivert. Begge rettes ved å endre rekkefølgen på fire kall, ikke ved å røre IKEv2-parametrene.

Last først, ellers har lagringen ingenting å sammenligne med

Behandleren holder en kopi av den lagrede profilen, og objektet du redigerer er ikke den kopien før du leser den. Kall loadFromPreferences først, rediger inne i fullføringsbehandleren og lagre deretter. Hopper du over lesingen, ser rammeverket et avvik mellom det det har og det du skriver. I Swift er formen den samme for hvert steg, og hvert steg hører til sin egen 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 fra lagre-closuren er den samme feilen et annet sted. Det kjører før profilen er lest på nytt, så startkallet ser tilstanden du bygde og ikke tilstanden som ble lagret. Lagre-closuren avsluttes med en andre loadFromPreferences, og bare den fullføringsbehandleren kaller startVPNTunnel.

Aktiveringsflagget er en del av lagringen

En lagret profil er inaktiv til den slås på. Sett isEnabled = true i samme skriving, ellers havner profilen deaktivert på disken og startVPNTunnel nekter selv om Innstillinger viser en konfigurasjon som ser komplett ut.

Eksterne redigeringer er den andre halvdelen. Hvis brukeren endrer noe i Innstillinger, eller enheten flytter seg mellom nettverk, les på nytt før du stoler på verdiene du fortsatt holder i minnet. Objektet observerer ikke disse endringene for deg. En utdatert kopi er måten en app skriver en profil som stille ruller tilbake brukerens redigering. To tilstøtende felt skaper stille problemer i samme øyeblikk: on-demand-regler må være en matrise med regelobjekter og ikke en tom plassholder, og disconnectOnSleep bør gjenspeile oppførselen du valgte og ikke en kopiert standardverdi.

Bare to protokoller er tilgjengelige for tredjepartsapper

Network Extension gir apper IPsec og IKEv2. L2TP og PPTP blir inne i systemet, så en app som trenger dem kan ikke få dem, og de realistiske svarene er en IKEv2-kompatibel gateway eller en administrert konfigurasjonsprofil.

Påloggingsinformasjon følger samme mønster. Legg passordet i Keychain og send en vedvarende referanse i stedet for strengen. En nullreferanse ved lagring betyr vanligvis at oppslaget kjørte før elementet ble skrevet, ikke at behandleren er ødelagt.

Begge er designvalg og ikke omveier. En app som holder passordet i egne innstillinger velger en vei rammeverket fraråder, og feilen den produserer leses som en lagringsfeil.

Utelukk rettigheten før du skriver om koden

Når loadFromPreferences aldri kaller tilbake, er den sannsynlige årsaken en manglende Network Extension-funksjon eller en provisjoneringsprofil som ikke bærer den. Den feilen henger i stedet for å gi en feil, og derfor skrives fungerende kode om i timer. Sjekk rettigheten på den signerte byggingen du vil levere, fordi en simulatorkjøring og en enhetskjøring kan være forskjellige og målet som betyr noe er enheten. Åpne signeringsinnstillingene til målet og bekreft at Network Extension-funksjonen finnes for akkurat den byggingen.

En provisjoneringsprofil uten rettigheten feiler på samme måte på maskinvare, mens samme bygging kan lastes normalt i simulatoren. Test det signerte arkivet på en ekte enhet før du skriver om rekkefølgen på kallene.

Følg med på statusendringene, ikke antakelser

Observer NEVPNStatusDidChangeNotification og logg manager.connection.status etter hvert steg. En status som aldri forlater invalid betyr at profilen ikke ble lagret eller at rettigheten mangler. En tilkobling som når connecting og aldri kobler til, peker på forslaget eller påloggingsinformasjonen, og det er en annen undersøkelse med andre bevis.

Bekreft at profilen vises under Innstillinger, Generelt, VPN, og noter feilen fra hver closure. De to fakta skiller en rekkefølgefeil fra en tillatelsesfeil uten gjetting.