API VPN pre iOS: NEVPNManager, poskytovateľ tunela alebo profil?

Vyberte API podľa transportu, s ktorým musíte hovoriť, potom dokážte, že tunel prenáša prevádzku: poradie save-load-start, entitlementy providera a pravidlá on-demand.

Na názov iOS VPN odpovedajú tri rôzne produkty a nezdieľajú jedno API. Personal VPN využíva vstavané transporty IPsec a IKEv2 v systéme. Custom tunnel spúšťa váš vlastný protokol vnútri network extension. Configuration profile konfiguruje ktorýkoľvek z nich a môže pridať on-demand správanie. Výber podľa transportu, s ktorým musíte hovoriť, je rýchlejší než výber podľa toho tutoriálu, ktorý sa skompiloval prvý.

Spustite kontroly nižšie v poradí, pretože každý krok predpokladá, že predchádzajúci vytvoril platnú konfiguráciu.

Krok 1: vyberte podľa transportu

Ak je server IKEv2 alebo IPsec v štýle Cisco, NEVPNManager stačí a systémové transporty prichádzajú zadarmo. Ak server hovorí OpenVPN, WireGuard alebo čokoľvek iné, NEVPNManager nepomôže: nemá hák na protokol tretej strany. Ten prípad vyžaduje NETunnelProviderManager s packet tunnel provider, ktorý protokol implementuje. Profil iba distribuuje konfiguráciu a nemôže pridať transport, ktorý operačný systém nemá.

PPTP nie je cieľom na súčasných systémoch. IPsec so zdieľaným tajomstvom stále očakáva názov skupiny v remoteIdentifier, položku keychain s tajomstvom a rozšírené overenie, keď server žiada používateľské meno. Každý chýbajúci diel sa prejaví ako tá istá všeobecná chyba konfigurácie, preto ich pridajte všetky, skôr než začnete ladiť čokoľvek iné.

Krok 2: dodržte poradie uloženie, načítanie, spustenie

NEVPNManager zapisuje do preferences, číta ich späť a až potom spustí. Vyplňte objekty protokolu a manager, zavolajte saveToPreferences, zavolajte loadFromPreferences a zavolajte startVPNTunnel z load completion handler. Spustenie pred návratom načítania vyprodukuje chybu configuration-invalid, NEVPNErrorDomain code 1, na konfigurácii, ktorá je inak správna.

Tvar je dosť krátky na to, aby sa udržal na jednom mieste:

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

startVPNTunnel sa vráti, keď je požiadavka prijatá, nie keď je tunel hore. Sledujte NEVPNStatusDidChange a čítajte connection.status pre skutočný stav. Aplikácia, ktorá predpokladá úspech v mieste volania, hlási pripojenú VPN, kým extension ešte vyjednáva. Stav connecting je chvíľu normálny; stav, z ktorého nikdy nevyjde, je zlyhanie, ktoré stojí za zalogovanie.

Krok 3: dajte procesu provider to, čo potrebuje

Custom transport beží v samostatnom procese s vlastným bundle identifier a vlastným entitlement. Container aplikácia aj provider potrebujú pri podpise entitlement network-extension a build Developer ID mimo App Store ho stále musí niesť v provisioning profile. Chýbajúci entitlement vyzerá ako chyba protokolu, pretože extension jednoducho nenaštartuje.

Neexistuje verejný socket descriptor na požičanie. NEPacketTunnelProvider vám dáva NEPacketTunnelFlow s read, write a cancel a kód, ktorý siaha po cestách privátnych kľúčov, sa medzi vydaniami láme. Provider beží ďalej, kým je aplikácia na pozadí, takže container aplikácia na to nepotrebuje režim na pozadí.

Krok 4: on-demand je sada pravidiel, nie prepínač

isOnDemandEnabled iba ozbrojí pravidlá; NEOnDemandRuleConnect a jeho súrodenci rozhodujú, kedy sa tunel zdvihne. Pravidlo evaluate-connection s probe URL je len také dobré, aké je tá URL. Ak probe odpovie bez tunela, pravidlo usúdi, že privátna sieť je už dostupná, a nikdy sa nepripojí, preto ho nasmerujte na niečo, čo odpovedá iba zvnútra.

Always-on je samostatný sľub. Potrebuje sledované zariadenie a spravovaný profil a nesledovaný používateľ môže profil kedykoľvek odstrániť. Nedodávajte dizajn, ktorý závisí od always-on, pokiaľ flotila nie je sledovaná.

Krok 5: dokážte cestu, nie štítok

Skenovanie rozhraní tun, tap, ppp alebo ipsec dokazuje, že VPN je nakonfigurovaná, nie že ju vaša požiadavka použila. NWPathMonitor s usesInterfaceType(.other) hovorí, že virtuálne rozhranie je dostupné, a viability handler môže otestovať jedného hosta. Ani jedno nedokazuje výstupnú cestu, preto ich skombinujte s požiadavkou na zdroj, ku ktorému sa dostane iba tunel. Názvy rozhraní sú diagnostická pomôcka, nikdy brána, na ktorej by sa mala aplikácia vetviť.

Na terénnu kontrolu porovnajte verejnú adresu s tunelom a bez neho a stiahnite iba internú stránku. Volanie status môže hlásiť pripojenie, kým provider vyjednáva, preto nechajte rozhodnúť výsledok zdroja a status berte ako podporný dôkaz.

Súvisiace články