API de VPN en iOS: NEVPNManager, proveedor de túnel o perfil?

Tres productos distintos responden al nombre de VPN en iOS y no comparten una API. La VPN personal va sobre los transportes IPsec e IKEv2 integrados en el sistema. Un túnel personalizado ejecuta su propio protocolo dentro de una extensión de red. Y un perfil de configuración configura cualquiera de los dos y puede añadir comportamiento a demanda. Elegir por el transporte con el que debe hablar es más rápido que elegir por el tutorial que compiló primero.

Ejecute las comprobaciones siguientes en orden, porque cada paso supone que el anterior produjo una configuración válida.

Paso 1: elija por transporte

Si el servidor es IKEv2 o IPsec al estilo de Cisco, NEVPNManager basta y los transportes del sistema salen gratis. Si el servidor habla OpenVPN, WireGuard o cualquier otra cosa, NEVPNManager no puede ayudar: no tiene gancho para un protocolo de terceros. Ese caso necesita NETunnelProviderManager con un proveedor de túnel de paquetes que implemente el protocolo. Un perfil solo distribuye configuración y no puede añadir un transporte que el sistema operativo no tiene.

PPTP no es un objetivo en los sistemas actuales. IPsec con secreto compartido sigue esperando el nombre de grupo en remoteIdentifier, un elemento de llavero que guarde el secreto y autenticación extendida cuando el servidor pide un nombre de usuario. Cada pieza que falta aparece como el mismo error genérico de configuración, así que añádalas todas antes de depurar cualquier otra cosa.

Paso 2: respete el orden guardar, cargar, arrancar

NEVPNManager escribe en las preferencias, las vuelve a leer y solo entonces arranca. Rellene los objetos de protocolo y de gestor, llame a saveToPreferences, llame a loadFromPreferences y llame a startVPNTunnel desde el manejador de finalización de la carga. Arrancar antes de que la carga vuelva produce un error de configuración no válida, código 1 de NEVPNErrorDomain, en una configuración que por lo demás es correcta.

La forma es lo bastante corta para tenerla en un solo sitio:

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

startVPNTunnel vuelve cuando se acepta la solicitud, no cuando el túnel está levantado. Observe NEVPNStatusDidChange y lea connection.status para el estado real. Una app que supone éxito en el punto de la llamada informa de una VPN conectada mientras la extensión aún negocia. Un estado de conexión es normal por un momento; un estado que nunca lo abandona es el fallo que merece registrarse.

Paso 3: dé al proceso del proveedor lo que necesita

Un transporte personalizado se ejecuta en un proceso aparte con su propio identificador de paquete y su propia autorización. Tanto la app contenedora como el proveedor necesitan la autorización de extensión de red al firmar, y una compilación con Developer ID fuera del App Store todavía tiene que llevarla en el perfil de aprovisionamiento. Una autorización ausente parece un fallo de protocolo porque la extensión simplemente no arranca.

No hay ningún descriptor de socket público que tomar prestado. NEPacketTunnelProvider le da NEPacketTunnelFlow con read, write y cancel, y el código que busca rutas privadas de claves se rompe entre versiones. El proveedor sigue ejecutándose mientras la app está en segundo plano, así que la app contenedora no necesita ningún modo de fondo para eso.

Paso 4: a demanda es un conjunto de reglas, no un interruptor

isOnDemandEnabled solo arma las reglas; NEOnDemandRuleConnect y sus hermanos deciden cuándo sube el túnel. Una regla de evaluación de conexión con una URL de sonda vale tanto como esa URL. Si la sonda responde sin el túnel, la regla concluye que la red privada ya es alcanzable y nunca conecta, así que apúntela a algo que solo responda desde dentro.

El encendido permanente es una promesa aparte. Necesita un dispositivo supervisado y un perfil gestionado, y un usuario no supervisado puede quitar un perfil cuando quiera. No entregue un diseño que dependa del encendido permanente salvo que el parque esté supervisado.

Paso 5: demuestre el camino, no la etiqueta

Escanear interfaces tun, tap, ppp o ipsec demuestra que una VPN está configurada, no que su solicitud la usara. NWPathMonitor con usesInterfaceType(.other) dice que hay una interfaz virtual disponible, y un manejador de viabilidad puede probar un solo host. Ninguno de los dos demuestra la ruta de salida, así que combínelos con una solicitud a un recurso al que solo el túnel pueda llegar. Los nombres de interfaz son una ayuda de diagnóstico, nunca una puerta sobre la que deba ramificar la lógica de la aplicación.

Para una comprobación de campo, compare la dirección pública con y sin el túnel y descargue una página solo interna. Una llamada de estado puede informar de conectado mientras el proveedor negocia, así que deje que decida el resultado del recurso y trate el estado como prueba de apoyo.