NEVPNManager ne konservas? La ordo estas ŝargi, ebligi, konservi, konekti

Kodo 4 kaj kodo 5 kutime signifas, ke la profilo estis redaktita antaŭ ol ĝi estis ŝargita, aŭ konservita dum ĝi estis malŝaltita. Riparu la ordon de la alvokoj, poste kontrolu la rajton.

Du erarkodoj klarigas la plej multajn unuajn provojn de Network Extension VPN en iOS: NEVPNErrorDomain Code=4 kaj Code=5. Neniu el ili estas plendo de la servilo. Unu aperas kiam la apo skribas agordojn en objekton, kiu neniam estis legita de la disko, kaj la alia kiam la skribo mem malsukcesas, plej ofte ĉar la profilo konserviĝas dum ĝi ankoraŭ estas malŝaltita. Ambaŭ ripariĝas per ŝanĝo de la ordo de kvar alvokoj, ne per tuŝo de la IKEv2-parametroj.

Unue ŝargu, alie la konservo havas kun kio kompari

La administranto tenas kopion de la konservita profilo, kaj la objekto, kiun vi redaktas, ne estas tiu kopio ĝis vi legas ĝin. Unue alvoku loadFromPreferences, redaktu ene de ĝia finpretiga traktilo, poste konservu. Se vi preterlasas la legadon, la kadro vidas malkongruecon inter tio, kion ĝi havas, kaj tio, kion vi skribas. En Swift la formo samas por ĉiu paŝo, kaj ĉiu paŝo apartenas al sia propra fermaĵo:

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
    }
}

Startigi la tunelon el la interno de la konserva fermaĵo estas la sama eraro aliloke. Ĝi ruliĝas antaŭ ol la profilo relegiĝis, do la starta alvoko vidas la staton, kiun vi konstruis, anstataŭ la staton, kiu konserviĝis. La konserva fermaĵo finiĝas per dua loadFromPreferences, kaj nur tiu finpretiga traktilo alvokas startVPNTunnel.

La ebliga flago estas parto de la konservo

Konservita profilo estas senefika ĝis ĝi ŝaltiĝas. Agordu isEnabled = true en la sama skribo, alie la profilo surteriĝas sur la disko malŝaltita kaj startVPNTunnel rifuzas eĉ kiam Agordoj montras agordon, kiu aspektas kompleta.

Eksteraj redaktoj estas la alia duono. Se la uzanto ŝanĝas ion en Agordoj, aŭ la aparato moviĝas inter retoj, relegu antaŭ ol fidi la valorojn, kiujn vi ankoraŭ tenas en la memoro. La objekto ne observas tiujn ŝanĝojn por vi. Malfreŝa kopio estas la maniero, kiel apo skribas profilon, kiu silente revenigas la uzantan redakton. Du apudaj kampoj kaŭzas silentan problemon en la sama momento: on-demand-reguloj devas esti tabelo de regulobjektoj, ne malplena anstataŭilo, kaj disconnectOnSleep devas speguli la konduton, kiun vi elektis, ne kopiitan defaŭlton.

Nur du protokoloj disponeblas al triapartaj apoj

Network Extension donas al apoj IPsec kaj IKEv2. L2TP kaj PPTP restas ene de la sistemo, do apo, kiu bezonas ilin, ne povas havi ilin, kaj la realismaj respondoj estas pordego kun IKEv2-subteno aŭ administrata agorda profilo.

Akreditaĵoj sekvas la saman ŝablonon. Metu la pasvorton en Keychain kaj transdonu daŭran referencon anstataŭ la ĉenon. Nula referenco dum konservado kutime signifas, ke la serĉo ruliĝis antaŭ ol la ero estis skribita, ne ke la administranto difektiĝis.

Ambaŭ estas dizajnaj decidoj, ne flankvojoj. Apo, kiu tenas la pasvorton en siaj propraj preferoj, elektas vojon, kiun la kadro malinstigas, kaj la fiasko, kiun ĝi produktas, legiĝas kiel konserva eraro.

Eliminu la rajton antaŭ ol reverki kodon

Kiam loadFromPreferences tute ne revokas, la verŝajna kaŭzo estas mankanta Network Extension-kapablo aŭ proviza profilo, kiu ne portas ĝin. Tiu fiasko pendas anstataŭ doni eraron, kaj tial funkcianta kodo reverkiĝas dum horoj. Kontrolu la rajton en la subskribita konstruaĵo, kiun vi intencas liveri, ĉar rulo en simulilo kaj rulo sur aparato povas malsami kaj la celo, kiu gravas, estas la aparato. Malfermu la subskribajn agordojn de la celo kaj konfirmu, ke la Network Extension-kapablo ĉeestas por ĝuste tiu konstruaĵo.

Proviza profilo sen la rajto fiaskas same sur aparataro, dum la sama konstruaĵo povas ŝargiĝi normale en la simulilo. Testu la subskribitan arkivon sur reala aparato antaŭ ol reverki la ordon de la alvokoj.

Observu la statŝanĝojn, ne la supozojn

Observu NEVPNStatusDidChangeNotification kaj registru manager.connection.status post ĉiu paŝo. Stato, kiu neniam forlasas invalid, signifas, ke la profilo ne konserviĝis aŭ ke la rajto mankas. Konekto, kiu atingas connecting kaj neniam konektiĝas, montras al la propono aŭ la akreditaĵoj, kio estas alia esploro kun aliaj pruvoj.

Konfirmu, ke la profilo aperas sub Agordoj, Ĝeneralaj, VPN, kaj registru la eraron el ĉiu fermaĵo. Tiuj du faktoj apartigas ordan cimon de permesa cimo sen divenado.

Rilataj artikoloj