NEVPNManager gemmer ikke? Rækkefølgen er indlæs, aktiver, gem, forbind

Kode 4 og kode 5 betyder normalt, at profilen blev redigeret, før den blev indlæst, eller gemt mens den var deaktiveret. Ret kaldets rækkefølge, og kontroller derefter rettigheden.

To fejlkoder forklarer de fleste første forsøg på en Network Extension VPN på iOS: NEVPNErrorDomain Code=4 og Code=5. Ingen af dem er en klage fra serveren. Den ene vises, når appen skriver indstillinger ind i et objekt, der aldrig blev læst fra disken, og den anden, når selve skrivningen fejler, oftest fordi profilen gemmes, mens den stadig er deaktiveret. Begge rettes ved at ændre rækkefølgen af fire kald, ikke ved at røre IKEv2-parametrene.

Indlæs først, ellers har gemningen intet at sammenligne med

Manageren holder en kopi af den gemte profil, og det objekt, du redigerer, er ikke den kopi, før du læser den. Kald loadFromPreferences først, rediger inde i dens completion-handler, og gem derefter. Springer du læsningen over, ser frameworket en uoverensstemmelse mellem det, den har, og det, du skriver. I Swift er formen den samme for hvert trin, og hvert trin hører til sit eget 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
    }
}

At starte tunnelen inde fra gemnings-closuret er den samme fejl på et andet sted. Det kører, før profilen er blevet læst igen, så startkaldet ser den tilstand, du byggede, i stedet for den tilstand, der blev gemt. Gemnings-closuret slutter med en anden loadFromPreferences, og kun den completion-handler kalder startVPNTunnel.

Aktiveringsflaget er en del af gemningen

En gemt profil er inaktiv, indtil den slås til. Sæt isEnabled = true i samme skrivning, ellers lander profilen på disken deaktiveret, og startVPNTunnel afviser, selv om Indstillinger viser en konfiguration, der ser komplet ud.

Eksterne redigeringer er den anden halvdel. Hvis brugeren ændrer noget i Indstillinger, eller enheden flytter sig mellem netværk, skal du læse igen, før du stoler på de værdier, du stadig holder i hukommelsen. Objektet observerer ikke de ændringer for dig. En forældet kopi er måden, en app skriver en profil, der stille ruller brugerens redigering tilbage. To tilstødende felter skaber stille problemer i samme øjeblik: on-demand-regler skal være et array af regelobjekter i stedet for en tom pladsholder, og disconnectOnSleep skal afspejle den adfærd, du valgte, i stedet for en kopieret standardværdi.

Kun to protokoller er tilgængelige for tredjepartsapps

Network Extension giver apps IPsec og IKEv2. L2TP og PPTP bliver inde i systemet, så en app, der har brug for dem, kan ikke få dem, og de realistiske svar er en IKEv2-kompatibel gateway eller en administreret konfigurationsprofil.

Legitimationsoplysninger følger samme mønster. Læg adgangskoden i Keychain og send en vedvarende reference i stedet for strengen. En nulreference ved gemning betyder normalt, at opslaget kørte, før elementet blev skrevet, ikke at manageren er i stykker.

Begge er designbeslutninger, ikke omveje. En app, der holder adgangskoden i sine egne præferencer, vælger en vej, frameworket fraråder, og den fejl, den producerer, læses som en gemmefejl.

Afvis rettigheden, før du omskriver kode

Når loadFromPreferences slet ikke kalder tilbage, er den sandsynlige årsag en manglende Network Extension-evne eller en provisioning-profil, der ikke bærer den. Den fejl hænger i stedet for at give en fejl, og derfor omskrives fungerende kode i timer. Kontroller rettigheden på det signerede build, du vil udsende, fordi en simulerkørsel og en enhedskørsel kan være forskellige, og det mål, der betyder noget, er enheden. Åbn målets signeringsindstillinger, og bekræft, at Network Extension-evnen findes for netop det build.

En provisioning-profil uden rettigheden fejler på samme måde på hardware, mens samme build kan indlæses normalt i simulatoren. Test det signerede arkiv på en rigtig enhed, før du omskriver kaldets rækkefølge.

Hold øje med statusændringerne, ikke antagelser

Observer NEVPNStatusDidChangeNotification, og log manager.connection.status efter hvert trin. En status, der aldrig forlader invalid, betyder, at profilen ikke blev gemt, eller at rettigheden mangler. En forbindelse, der når connecting og aldrig forbinder, peger på forslaget eller legitimationsoplysningerne, og det er en anden undersøgelse med andre beviser.

Bekræft, at profilen vises under Indstillinger, Generelt, VPN, og noter fejlen fra hvert closure. De to fakta skiller en rækkefølgefejl fra en tilladelsesfejl uden gætteri.

Relaterede artikler