API de VPN a iOS: NEVPNManager, proveïdor de túnel o perfil?

Tres productes diferents responen al nom de VPN a iOS i no comparteixen una API. La VPN personal funciona amb els transports IPsec i IKEv2 integrats al sistema. Un túnel personalitzat executa el vostre propi protocol dins d'una extensió de xarxa. I un perfil de configuració configura qualsevol dels dos i pot afegir comportament a demanda. Triar pel transport amb què heu de parlar és més ràpid que triar pel tutorial que es va compilar primer.

Feu les comprovacions següents en ordre, perquè cada pas pressuposa que l'anterior ha produït una configuració vàlida.

Pas 1: trieu pel transport

Si el servidor és IKEv2 o IPsec a l'estil de Cisco, NEVPNManager n'hi ha prou i els transports del sistema surten de franc. Si el servidor parla OpenVPN, WireGuard o qualsevol altra cosa, NEVPNManager no pot ajudar: no té cap ganxo per a un protocol de tercers. Aquest cas necessita NETunnelProviderManager amb un proveïdor de túnel de paquets que implementi el protocol. Un perfil només distribueix configuració i no pot afegir un transport que el sistema operatiu no té.

PPTP no és un objectiu en els sistemes actuals. L'IPsec amb secret compartit encara espera el nom del grup a remoteIdentifier, un element de clauer que guardi el secret i autenticació estesa quan el servidor demana un nom d'usuari. Cada peça que falta es manifesta com el mateix error genèric de configuració, així que afegiu-les totes abans de depurar qualsevol altra cosa.

Pas 2: respecteu l'ordre de desar, carregar i iniciar

NEVPNManager escriu a les preferències, les torna a llegir i només llavors inicia. Ompliu els objectes de protocol i de gestor, crideu saveToPreferences, crideu loadFromPreferences i crideu startVPNTunnel des del gestor de compleció de la càrrega. Iniciar abans que la càrrega torni produeix un error de configuració no vàlida, codi 1 de NEVPNErrorDomain, en una configuració que d'altra manera és correcta.

La forma és prou curta per tenir-la en un sol lloc:

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

startVPNTunnel torna quan la sol·licitud s'accepta, no quan el túnel és aixecat. Observeu NEVPNStatusDidChange i llegiu connection.status per a l'estat real. Una app que pressuposa èxit al punt de la crida informa d'una VPN connectada mentre l'extensió encara negocia. Un estat de connexió és normal durant un moment; un estat que no en surt mai és la fallada que val la pena registrar.

Pas 3: doneu al procés del proveïdor el que necessita

Un transport personalitzat s'executa en un procés a part amb el seu propi identificador de paquet i la seva pròpia autorització. Tant l'app contenidora com el proveïdor necessiten l'autorització d'extensió de xarxa en el moment de signar, i una compilació amb Developer ID fora de l'App Store encara l'ha de portar al perfil d'aprovisionament. Una autorització que falta sembla un error de protocol perquè l'extensió simplement no s'inicia.

No hi ha cap descriptor de sòcol públic per manllevar. NEPacketTunnelProvider us dona NEPacketTunnelFlow amb read, write i cancel, i el codi que busca camins privats de claus es trenca entre versions. El proveïdor continua executant-se mentre l'app és en segon pla, així que l'app contenidora no necessita cap mode de fons per això.

Pas 4: a demanda és un conjunt de regles, no un interruptor

isOnDemandEnabled només arma les regles; NEOnDemandRuleConnect i els seus germans decideixen quan s'aixeca el túnel. Una regla d'avaluació de connexió amb una URL de sonda val tant com aquesta URL. Si la sonda respon sense el túnel, la regla conclou que la xarxa privada ja és abastable i no es connecta mai, així que apunteu-la a una cosa que només respongui des de dins.

L'encesa permanent és una promesa a part. Necessita un dispositiu supervisat i un perfil gestionat, i un usuari no supervisat pot treure un perfil quan vulgui. No entregueu un disseny que depengui de l'encesa permanent tret que la flota estigui supervisada.

Pas 5: demostreu el camí, no l'etiqueta

Escanejar interfícies tun, tap, ppp o ipsec demostra que una VPN està configurada, no que la vostra sol·licitud l'hagi feta servir. NWPathMonitor amb usesInterfaceType(.other) diu que hi ha una interfície virtual disponible, i un gestor de viabilitat pot provar un sol amfitrió. Cap dels dos no demostra el camí de sortida, així que combineu-los amb una sol·licitud a un recurs que només el túnel pugui assolir. Els noms d'interfície són una ajuda de diagnòstic, mai una porta on la lògica de l'aplicació hagi de bifurcar-se.

Per a una comprovació de camp, compareu l'adreça pública amb i sense el túnel i baixeu una pàgina només interna. Una crida d'estat pot informar de connectat mentre el proveïdor negocia, així que deixeu que decideixi el resultat del recurs i tracteu l'estat com a prova de suport.