API pro VPN v iOS: NEVPNManager, poskytovatel tunelu, nebo profil?

Na jméno VPN v iOS odpovídají tři různé produkty a nesdílejí jedno API. Osobní VPN jezdí na systémových transportech IPsec a IKEv2. Vlastní tunel spouští váš protokol uvnitř síťového rozšíření. A konfigurační profil nakonfiguruje kterýkoli z nich a může přidat chování na vyžádání. Výběr podle transportu, kterým musíte mluvit, je rychlejší než výběr podle toho návodu, který se zkompiloval první.

Proveďte níže uvedené kontroly v pořadí, protože každý krok předpokládá, že předchozí vytvořil platnou konfiguraci.

Krok 1: vybírejte podle transportu

Pokud server běží na IKEv2 nebo na IPsec ve stylu Cisco, NEVPNManager stačí a systémové transporty dostanete zdarma. Pokud server mluví OpenVPN, WireGuard nebo čímkoli jiným, NEVPNManager nepomůže: nemá háček pro protokol třetí strany. Ten případ potřebuje NETunnelProviderManager s poskytovatelem paketového tunelu, který protokol implementuje. Profil jen distribuuje konfiguraci a nemůže přidat transport, který operační systém nemá.

PPTP není na současných systémech cíl. IPsec se sdíleným tajemstvím stále očekává název skupiny v remoteIdentifier, položku klíčenky s tajemstvím a rozšířené ověřování, když server žádá uživatelské jméno. Každá chybějící část se projeví jako stejná obecná chyba konfigurace, takže je přidejte všechny, než začnete ladit cokoli jiného.

Krok 2: dodržte pořadí uložit, načíst, spustit

NEVPNManager zapisuje do předvoleb, čte je zpět a teprve potom spouští. Vyplňte objekty protokolu a správce, zavolejte saveToPreferences, zavolejte loadFromPreferences a zavolejte startVPNTunnel z obsluhy dokončení načtení. Spuštění před návratem načtení vyvolá chybu neplatné konfigurace, kód 1 v NEVPNErrorDomain, u konfigurace, která je jinak správná.

Tvar je dost krátký na to, aby se udržel na jednom místě:

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

startVPNTunnel se vrací, když je požadavek přijat, ne když je tunel nahoře. Sledujte NEVPNStatusDidChange a čtěte connection.status pro skutečný stav. Aplikace, která předpokládá úspěch už v místě volání, hlásí připojenou VPN, zatímco rozšíření ještě vyjednává. Stav připojování je na okamžik normální; stav, který z něj nikdy nevyjde, je porucha, kterou stojí za to zalogovat.

Krok 3: dejte procesu poskytovatele, co potřebuje

Vlastní transport běží v samostatném procesu s vlastním identifikátorem balíčku a vlastním oprávněním. Oprávnění síťového rozšíření při podpisu potřebuje aplikace-kontejner i poskytovatel a sestavení s Developer ID mimo App Store je stále musí nést v provisioning profilu. Chybějící oprávnění vypadá jako chyba protokolu, protože rozšíření prostě nenastartuje.

Neexistuje veřejný deskriptor socketu, který by se dal vypůjčit. NEPacketTunnelProvider vám dává NEPacketTunnelFlow s read, write a cancel a kód, který sahá po privátních cestách klíčů, se mezi vydáními rozbije. Poskytovatel běží dál, i když je aplikace na pozadí, takže kontejner pro to nepotřebuje režim na pozadí.

Krok 4: chování na vyžádání je sada pravidel, ne vypínač

isOnDemandEnabled jen napíná pravidla; NEOnDemandRuleConnect a jeho sourozenci rozhodují, kdy tunel vstane. Pravidlo vyhodnocení spojení se sondovací URL platí jen tak, jak platí ta URL. Pokud sonda odpoví bez tunelu, pravidlo usoudí, že privátní síť je už dostupná, a nikdy se nepřipojí, takže ho namiřte na něco, co odpovídá jen zevnitř.

Trvalý provoz je samostatný slib. Potřebuje zařízení pod dohledem a spravovaný profil a uživatel bez dohledu může profil kdykoli odebrat. Nedodávejte návrh, který závisí na trvalém provozu, pokud flotila není pod dohledem.

Krok 5: dokažte cestu, ne štítek

Skenování rozhraní tun, tap, ppp nebo ipsec dokazuje, že VPN je nakonfigurovaná, ne že ji váš požadavek použil. NWPathMonitor s usesInterfaceType(.other) říká, že je dostupné virtuální rozhraní, a obsluha životaschopnosti může otestovat jeden hostitel. Ani jedno nedokazuje výstupní cestu, takže je zkombinujte s požadavkem na zdroj, který dokáže dosáhnout jen tunel. Názvy rozhraní jsou diagnostická pomůcka, nikdy brána, na kterou by měla logika aplikace větvit.

Pro terénní kontrolu porovnejte veřejnou adresu s tunelem a bez něj a stáhněte stránku dostupnou jen zevnitř. Volání stavu může hlásit připojeno, zatímco poskytovatel vyjednává, takže nechte rozhodnout výsledek zdroje a stav berte jako podpůrný důkaz.