NEVPNManager nuk ruan? Radha është ngarko, aktivizo, ruaj, lidhu

Dy kode gabimi shpjegojnë shumicën e përpjekjeve të para me një VPN Network Extension në iOS: NEVPNErrorDomain Code=4 dhe Code=5. Asnjëri nuk është ankesë e serverit. Njëri shfaqet kur aplikacioni shkruan cilësime në një objekt që nuk u lexua kurrë nga disku, dhe tjetri kur dështon vetë shkrimi, më shpesh sepse profili ruhet ndërsa është ende i çaktivizuar. Të dyja rregullohen duke ndryshuar radhën e katër thirrjeve, jo duke prekur parametrat e IKEv2.

Ngarkoni fillimisht, përndryshe ruajtja nuk ka me çfarë të krahasohet

Menaxheri mban një kopje të profilit të ruajtur, dhe objekti që redaktoni nuk është ajo kopje derisa ta lexoni. Thirrni fillimisht loadFromPreferences, redaktoni brenda mbajtësit të përfundimit të tij, pastaj ruani. Nëse e kaloni leximin, korniza sheh një mospërputhje midis asaj që ka dhe asaj që shkruani. Në Swift forma është e njëjtë në çdo hap, dhe çdo hap i përket closure-it të vet:

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

Nisja e tunelit nga brenda closure-it të ruajtjes është i njëjti gabim në një vend tjetër. Ai ekzekutohet para se profili të rilexohet, kështu që thirrja e nisjes sheh gjendjen që ndërtuat dhe jo gjendjen që u ruajt. Closure-i i ruajtjes përfundon me një loadFromPreferences të dytë, dhe vetëm ai mbajtës i përfundimit thërret startVPNTunnel.

Flamuri i aktivizimit është pjesë e ruajtjes

Një profil i ruajtur është inert derisa të ndizet. Vendosni isEnabled = true në të njëjtin shkrim, përndryshe profili zbret në disk i çaktivizuar dhe startVPNTunnel refuzon edhe kur Cilësimet tregojnë një konfigurim që duket i plotë.

Redaktimet e jashtme janë gjysma tjetër. Nëse përdoruesi ndryshon diçka në Cilësimet, ose pajisja lëviz midis rrjeteve, rilexoni përpara se t’u besoni vlerave që mbani ende në memorie. Objekti nuk i vëzhgon ato ndryshime për ju. Një kopje e vjetruar është mënyra se si një aplikacion shkruan një profil që kthen në heshtje redaktimin e përdoruesit. Dy fusha ngjitur shkaktojnë problem të heshtur në të njëjtin moment: rregullat on-demand duhet të jenë një grup objektesh rregulli dhe jo një vendmbajtës bosh, dhe disconnectOnSleep duhet të pasqyrojë sjelljen që zgjodhët dhe jo një parazgjedhje të kopjuar.

Vetëm dy protokolle janë në dispozicion për aplikacionet e palëve të treta

Network Extension u jep aplikacioneve IPsec dhe IKEv2. L2TP dhe PPTP mbeten brenda sistemit, kështu që një aplikacion që i nevojiten nuk mund t’i ketë, dhe përgjigjet realiste janë një portë që mbështet IKEv2 ose një profil konfigurimi i menaxhuar.

Kredencialet ndjekin të njëjtin model. Vendosni fjalëkalimin në Keychain dhe kaloni një referencë të përhershme në vend të vargut. Një referencë zero gjatë ruajtjes zakonisht do të thotë që kërkimi u ekzekutua përpara se artikulli të shkruhej, jo që menaxheri është prishur.

Të dyja janë vendime dizajni dhe jo zgjidhje anashkaluese. Një aplikacion që e mban fjalëkalimin në preferencat e veta zgjedh një rrugë që korniza nuk e këshillon, dhe dështimi që prodhon lexohet si gabim ruajtjeje.

Përjashtoni të drejtën përpara se të rishkruani kodin

Kur loadFromPreferences nuk kthen fare thirrje, shkaku i mundshëm është një aftësi Network Extension që mungon ose një profil furnizimi që nuk e mbart atë. Ai dështim varet në vend që të japë gabim, dhe për këtë arsye kodi që funksionon rishkruhet me orë të tëra. Kontrolloni të drejtën në build-in e nënshkruar që synoni të dërgoni, sepse ekzekutimi në simulator dhe ai në pajisje mund të ndryshojnë dhe objektivi që ka rëndësi është pajisja. Hapni cilësimet e nënshkrimit të objektivit dhe konfirmoni që aftësia Network Extension është e pranishme për pikërisht atë build.

Një profil furnizimi pa të drejtën dështon në të njëjtën mënyrë në harduer, ndërsa i njëjti build mund të ngarkohet normalisht në simulator. Testoni arkivin e nënshkruar në një pajisje reale përpara se të rishkruani radhën e thirrjeve.

Vëzhgoni ndryshimet e statusit, jo supozimet

Vëzhgoni NEVPNStatusDidChangeNotification dhe regjistroni manager.connection.status pas çdo hapi. Një status që nuk largohet kurrë nga invalid do të thotë që profili nuk u ruajt ose që mungon e drejta. Një lidhje që arrin connecting dhe nuk lidhet kurrë tregon propozimin ose kredencialet, që është një hetim tjetër me prova të tjera.

Konfirmoni që profili shfaqet nën Cilësimet, Të përgjithshme, VPN, dhe shënoni gabimin nga çdo closure. Këto dy fakte ndajnë një bug radhe nga një bug leje pa hamendësim.