Mit hozhat létre a NEVPNManager iOS-en (és mit nem)

Amikor VPN-képernyőt építesz egy iOS-alkalmazásba, az első meglepetés, hogy a Beállítások alkalmazás protokollistája nem az API listája. A Network Extension keretrendszer engedi, hogy az alkalmazásod egyetlen személyes VPN-konfigurációt hozzon létre, amely az adott alkalmazás tulajdona, és csak néhány protokollobjektumot fogad el. Minden más, amire az emberek számítanak, az L2TP-től a letöltött profilig, ezen a felületen kívül esik, vagy az Apple számára privát. A következő hibák általában nem bugok, hanem az API megtagad egy munkát, amelyet soha nem kapott meg.

A mítosz: az API egy Beállítások-szerkesztő

Azt hiszik, hogy mivel az iOS képes IKEv1, IKEv2, L2TP és IPsec profilokat konfigurálni, egy alkalmazás bármelyiket létrehozhatja programozottan. Nem képes. A keretrendszer pontosan egy konfigurációs helyet tár fel a hívó alkalmazásnak, és az a hely csak nyilvános protokollosztályok kis halmazát fogadja el. Minden más, amire az emberek számítanak, az L2TP-től a letöltött profilig, ezen a felületen kívül esik, vagy az Apple számára privát.

A következő hibák általában nem bugok. Az API megtagad egy munkát, amelyet soha nem kapott meg, és a megoldás az, hogy a képernyőt ahhoz igazítsuk, ami az API tulajdona.

Három protokollobjektum és azok, amelyek nem léteznek

A lehetőségeid az IKEv1 a NEVPNProtocolIPSec révén, az IKEv2 a NEVPNProtocolIKEv2 révén, és a NETunnelProviderProtocol, ha saját csomagalagút-kiterjesztést szállítasz. A NEVPNManager-referencia felsorolja az elfogadott protokollobjektumokat. Az L2TP és a PPTP soha nem jelenik meg abban a listában, mert az Apple nem publikált osztályokat számukra. Bármelyik kipróbálása mentéskor hibával végződik, vagy ami rosszabb, egy olyan konfigurációval, amelyet a rendszer csendben nem hajlandó használni.

Az asztali kód más szabályokat követ. A macOS-en a SCNetworkInterfaceCreateWithInterface egymásra rak egy L2TP-hez hasonló interfésztípust IPv4 felett, és hozzákapcsolja egy hálózati szolgáltatáshoz, a networksetup -connectpppoeservice pedig elindítja az eredményt. Rendszergazdai jogok és segédeszköz szükséges, mert a megosztott titok és a jelszó a rendszer kulcstartójába kerül. Másold ezt a tervet iOS-re, és semmi nem fordul le.

Kulcstartó-hivatkozást adj át, ne a jelszót

Egyik IKE-osztály sem fogadja el a jelszót szövegként. A két tulajdonság, a passwordReference és a sharedSecretReference, állandó kulcstartó-hivatkozást kér, amelyet a SecItemCopyMatching függvényből kapsz meg a kSecReturnPersistentRef kérésével. Az elem adatainak átadása vagy egy karakterlánc beírása a mezőbe mentési hibát vagy üres hitelesítő adatokkal rendelkező kapcsolatot eredményez. A hivatkozás csak annyira tartós, mint a mögötte lévő kulcstartó-elem, ezért az elemnek léteznie kell a konfiguráció összeállítása előtt. Hozd létre ugyanabban a tranzakcióban, mint a mentést, és ezzel a sorrendezési hibák egész osztályát szünteted meg.

A tanúsítványos hitelesítés más útvonalat követ: identityData plusz identityDataPassword egy PKCS#12 blobhoz. A blob alkalmazáscsomagban való szállítása a mintakódból átvett szokás, nem szállítási döntés, mert a jelszó vele utazik, és az alkalmazás minden példánya ugyanazt az identitást hordozza.

A jogosultság és az elérhetőség mindent meghatároz

Előfordulhat, hogy a kezelő egyáltalán nem létezik, és ennek oka a kiépítés. Az alkalmazásazonosítónak szüksége van a Network Extension képességre és a személyes VPN jogosultságra, a buildet aláíró profilnak pedig mindkettőt hordoznia kell.

Ha ezt kihagyod, a megosztott példány nil-t ad vissza, vagy a mentés olyan hibával hiúsul meg, amely soha nem említi a jogosultságot. Az elérhetőség a másik kapu. Ha az iOS 8-nál régebbit céloz, a szimbólum hiányzik futásidőben, így a hiba összeomlás vagy nil kezelő, nem pedig konfiguráció nélküli kezelő. Ellenőrizd a futásidejű környezetet és a jogosultságot, mielőtt az objektumgráfodat hibakeresed.

Töltsd be, módosítsd, mentsd, majd figyeld az igény szerinti sorrendet

Az életciklust betöltésként, módosításaként és mentésként kezeld, és soha ne hagyd ki a betöltést. Amíg a loadFromPreferences nem fejeződik be, a kezelő semmit nem tart, és a protokollobjektum nem olvasható és nem cserélhető.

A második mentés lecseréli a konfigurációt ahelyett, hogy hozzáadna egy másikat, így egy félkész mentés károsíthat egy működő profilt. Az igény szerinti szabályok rendezett tömböt alkotnak, és ez a sorrend a házirend. Tegyél egy bárhonnan csatlakozás szabályt a leválasztási szabály elé, és a kézi leválasztást azonnali újracsatlakozás követi, ami hibának tűnik, de a dokumentált kiértékelést követi.

Mozgasd a leválasztási szabályt előre, amikor a felhasználói műveletnek győznie kell. Ami az alkalmazás ellenőrzésén kívül marad, az ugyanolyan fontos. Az útvonalak az alagútból vagy a kiszolgáló házirendjéből jönnek, nem az általad beállított preferenciából, és a csomagalagút-szolgáltató jelentést ad róluk induláskor. Az alkalmazás nem tudja listázni vagy szerkeszteni a más alkalmazások vagy konfigurációs profilok által telepített profilokat, ezért ne ígérj olyan képernyőt, amely az eszköz minden VPN-jét mutatja.