iOS VPN API-k: NEVPNManager, alagút-szolgáltató vagy profil?

Három különböző termék viseli az iOS VPN nevet, és nem osztoznak API-n. A Personal VPN a rendszer beépített IPsec és IKEv2 átvitelét használja. A Custom tunnel a saját protokollját futtatja egy network extension belsejében. A Configuration profile bármelyiket beállítja, és hozzáadhat on-demand viselkedést. Gyorsabb az átvitel alapján választani, amellyel beszélnie kell, mint aszerint, melyik oktatóanyag fordult le előbb.

Futtassa az alábbi ellenőrzéseket sorrendben, mert minden lépés feltételezi, hogy az előző érvényes konfigurációt eredményezett.

1. lépés: válasszon átvitel alapján

Ha a kiszolgáló IKEv2 vagy Cisco stílusú IPsec, a NEVPNManager elég, és a rendszerátvitelek ingyen jönnek. Ha a kiszolgáló OpenVPN-t, WireGuardot vagy bármi mást beszél, a NEVPNManager nem segíthet: nincs horga harmadik féltől származó protokollhoz. Ez az eset NETunnelProviderManagert kér egy packet tunnel providerrel, amely megvalósítja a protokollt. A profile csak konfigurációt oszt ki, és nem adhat hozzá olyan átvitelt, amivel az operációs rendszer nem rendelkezik.

A PPTP nem cél a jelenlegi rendszereken. A megosztott titkosítású IPsec továbbra is elvárja a csoportnevet a remoteIdentifierben, a titkot tartó keychain elemet, és a kiterjesztett hitelesítést, amikor a kiszolgáló felhasználónevet kér. Minden hiányzó darab ugyanakkor az általános konfigurációs hibaként jelenik meg, ezért adja hozzá mindet, mielőtt bármi mást hibakeresne.

2. lépés: tartsa be a mentés, betöltés, indítás sorrendjét

A NEVPNManager a preferencesbe ír, visszaolvassa, és csak utána indul. Töltse ki a protokoll- és manager-objektumokat, hívja meg a saveToPreferences-t, a loadFromPreferences-t, és a startVPNTunnel-t a load completion handlerből. A betöltés visszatérése előtti indítás configuration-invalid hibát, NEVPNErrorDomain code 1-et ad egy egyébként helyes konfiguráción.

A forma elég rövid ahhoz, hogy egy helyen tartsa:

manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }

A startVPNTunnel akkor tér vissza, amikor a kérés elfogadásra kerül, nem amikor az alagút feláll. Figyelje a NEVPNStatusDidChange-et, és olvassa a connection.status-t a valódi állapothoz. Az az alkalmazás, amely a hívás helyén sikert feltételez, csatlakozott VPN-t jelent, miközben az extension még egyeztet. A connecting állapot egy pillanatra normális; az az állapot, amelyből soha nem lép ki, az a naplózásra érdemes hiba.

3. lépés: adjon a provider folyamatnak, amire szüksége van

A Custom transport külön folyamatban fut saját bundle identifierrel és saját entitlementtel. Mind a container alkalmazásnak, mind a providernek szüksége van a network-extension entitlementre aláíráskor, és az App Store-on kívüli Developer ID buildnek is hordoznia kell a provisioning profile-ban. A hiányzó entitlement protokollhibának látszik, mert az extension egyszerűen nem indul el.

Nincs nyilvános socket descriptor, amit kölcsön lehetne venni. A NEPacketTunnelProvider NEPacketTunnelFlow-t ad read, write és cancel műveletekkel, és a privát kulcsútvonalakra nyúló kód kiadások között eltörik. A provider fut tovább, miközben az alkalmazás a háttérben van, ezért a container alkalmazásnak ehhez nem kell háttérmód.

4. lépés: az on-demand szabálykészlet, nem kapcsoló

Az isOnDemandEnabled csak feléleszti a szabályokat; a NEOnDemandRuleConnect és testvérei döntik el, mikor áll fel az alagút. A probe URL-lel rendelkező evaluate-connection szabály csak annyit ér, mint az az URL. Ha a probe az alagút nélkül válaszol, a szabály arra jut, hogy a privát hálózat már elérhető, és soha nem csatlakozik, ezért olyan célra irányítsa, amely csak belülről válaszol.

Az Always-on külön ígéret. Felügyelt eszköz és kezelt profil kell hozzá, a nem felügyelt felhasználó pedig bármikor eltávolíthatja a profilt. Ne szállítson olyan tervet, amely az always-on-tól függ, hacsak a flotta nincs felügyelve.

5. lépés: az útvonalat bizonyítsa, ne a címkét

A tun, tap, ppp vagy ipsec interfészek keresése azt bizonyítja, hogy a VPN be van állítva, nem azt, hogy a kérés használta. A NWPathMonitor usesInterfaceType(.other) beállítással azt mondja, hogy virtuális interfész elérhető, és egy viability handler egy gazdagépet tesztelhet. Egyik sem bizonyítja a kimeneti útvonalat, ezért kombinálja őket egy olyan erőforrás kérésével, amelyet csak az alagút érhet el. Az interfésznevek diagnosztikai segédeszközök, soha nem kapuk, amelyekre az alkalmazáslogikának elágaznia kellene.

Terepi ellenőrzéshez hasonlítsa össze a nyilvános címet az alagúttal és anélkül, és töltsön le egy csak belső oldalt. A status hívás csatlakozott állapotot jelenthet, miközben a provider egyeztet, ezért az erőforrás eredménye döntsön, és a statust kiegészítő bizonyítékként kezelje.