Nem ment a NEVPNManager? A sorrend: betöltés, engedélyezés, mentés, csatlakozás

A 4-es és 5-ös kód általában azt jelenti, hogy a profilt a betöltés előtt szerkesztették, vagy letiltott állapotban mentették. Javítsa a hívások sorrendjét, majd ellenőrizze a jogosultságot.

Két hibakód magyarázza a legtöbb első próbálkozást a Network Extension VPN-nel iOS-en: NEVPNErrorDomain Code=4 és Code=5. Egyik sem a szerver panasza. Az egyik akkor jelenik meg, amikor az app olyan objektumba ír beállításokat, amelyet soha nem olvastak be a lemezről, a másik pedig akkor, amikor maga az írás hiúsul meg, legtöbbször azért, mert a profilt még letiltott állapotban mentik. Mindkettő négy hívás sorrendjének megváltoztatásával javul, nem az IKEv2 paramétereinek piszkálásával.

Először töltse be, különben a mentésnek nincs mihez hasonlítania

A kezelő a tárolt profil egy példányát tartja, és az objektum, amelyet szerkeszt, nem ez a példány, amíg be nem olvassa. Először hívja meg a loadFromPreferences-t, szerkesszen a befejezési kezelőjén belül, majd mentse. Ha kihagyja az olvasást, a keretrendszer eltérést lát aközött, amije van, és aközött, amit ír. Swiftben a forma minden lépésnél ugyanaz, és minden lépés a saját closure-ébe tartozik:

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

Az alagút elindítása a mentési closure belsejéből ugyanaz a hiba más helyen. A profil újraolvasása előtt fut, ezért az indító hívás az általad felépített állapotot látja, nem a mentett állapotot. A mentési closure egy második loadFromPreferences-szel ér véget, és csak az a befejezési kezelő hívja meg a startVPNTunnel-t.

Az engedélyezési jelző a mentés része

A tárolt profil hatástalan, amíg be nem kapcsolják. Állítsa be a isEnabled = true-t ugyanabban az írásban, különben a profil letiltva kerül a lemezre, és a startVPNTunnel megtagadja, még ha a Beállítások teljesnek tűnő konfigurációt is mutat.

A külső szerkesztések a másik fele. Ha a felhasználó változtat valamit a Beállításokban, vagy az eszköz hálózatok között mozog, olvassa újra, mielőtt megbízik a memóriában még tartott értékekben. Az objektum nem figyeli ezeket a változásokat Ön helyett. Az elavult példány az, ahogyan egy app olyan profilt ír, amely csendben visszaállítja a felhasználói szerkesztést. Két szomszédos mező ugyanabban a pillanatban okoz csendes bajt: az on-demand szabályoknak szabályobjektumok tömbjének kell lenniük, nem üres helyőrzőnek, a disconnectOnSleep pedig a választott viselkedést tükrözze, ne egy másolt alapértéket.

Csak két protokoll érhető el harmadik féltől származó appok számára

A Network Extension IPsec-et és IKEv2-t ad az appoknak. Az L2TP és a PPTP a rendszeren belül marad, így egy app, amelynek szüksége van rájuk, nem kaphatja meg őket, a valószerű válaszok pedig egy IKEv2-képes átjáró vagy egy felügyelt konfigurációs profil.

A hitelesítő adatok ugyanezt a mintát követik. Tegye a jelszót a Keychainbe, és a karakterlánc helyett adjon át tartós hivatkozást. A mentéskori nulla hivatkozás általában azt jelenti, hogy a keresés az elem írása előtt futott, nem azt, hogy a kezelő elromlott.

Mindkettő tervezési döntés, nem kerülő megoldás. Az az app, amely a saját beállításaiban tartja a jelszót, olyan utat választ, amelyet a keretrendszer nem ajánl, és az általa keltett hiba mentési hibaként olvasható.

Zárja ki a jogosultságot, mielőtt átírja a kódot

Amikor a loadFromPreferences egyáltalán nem hív vissza, a valószínű ok egy hiányzó Network Extension képesség vagy egy olyan provisioning profil, amely nem hordozza. Ez a hiba hibaüzenet helyett lefagy, és ezért írnak át működő kódot órákig. Ellenőrizze a jogosultságot azon az aláírt builden, amelyet ki akar adni, mert a szimulátoros és az eszközön futó futtatás eltérhet, és a számító cél az eszköz. Nyissa meg a cél aláírási beállításait, és erősítse meg, hogy a Network Extension képesség pontosan ahhoz a buildhez van jelen.

A jogosultság nélküli provisioning profil hardveren ugyanúgy meghiúsul, míg ugyanaz a build a szimulátorban normálisan betölthető. Tesztelje az aláírt archívumot valódi eszközön, mielőtt átírja a hívások sorrendjét.

Az állapotváltozásokat figyelje, ne a feltevéseket

Figyelje a NEVPNStatusDidChangeNotificationt, és minden lépés után naplózza a manager.connection.status-t. Az az állapot, amely soha nem hagyja el az invalid értéket, azt jelenti, hogy a profil nem lett tárolva, vagy hiányzik a jogosultság. Az a kapcsolat, amely eléri a connecting állapotot és soha nem csatlakozik, a javaslatra vagy a hitelesítő adatokra mutat, ami más bizonyítékokkal járó más vizsgálat.

Erősítse meg, hogy a profil megjelenik a Beállítások, Általános, VPN alatt, és jegyezze fel az egyes closure-ök hibáját. Ez a két tény találgatás nélkül választja el a sorrendhibát az engedélyhibától.

Kapcsolódó cikkek