API de VPN en iOS: NEVPNManager, provedor de túnel ou perfil?

Tres produtos distintos responden ao nome de VPN en iOS e non comparten unha API. A VPN persoal vai sobre os transportes IPsec e IKEv2 integrados no sistema. Un túnel personalizado executa o seu propio protocolo dentro dunha extensión de rede. E un perfil de configuración configura calquera dos dous e pode engadir comportamento a demanda. Escoller polo transporte co que debe falar é máis rápido que escoller polo titorial que compilou primeiro.

Execute as comprobacións seguintes en orde, porque cada paso supón que o anterior produciu unha configuración válida.

Paso 1: escolla por transporte

Se o servidor é IKEv2 ou IPsec ao estilo de Cisco, NEVPNManager abonda e os transportes do sistema saen de balde. Se o servidor fala OpenVPN, WireGuard ou calquera outra cousa, NEVPNManager non pode axudar: non ten gancho para un protocolo de terceiros. Ese caso necesita NETunnelProviderManager cun provedor de túnel de paquetes que implemente o protocolo. Un perfil só distribúe configuración e non pode engadir un transporte que o sistema operativo non ten.

PPTP non é un obxectivo nos sistemas actuais. IPsec con segredo compartido segue esperando o nome do grupo en remoteIdentifier, un elemento de chaveiro que garde o segredo e autenticación estendida cando o servidor pide un nome de usuario. Cada peza que falta aparece como o mesmo erro xenérico de configuración, así que engádaas todas antes de depurar calquera outra cousa.

Paso 2: respecte a orde gardar, cargar, arrincar

NEVPNManager escribe nas preferencias, volve lelas e só entón arrinca. Encha os obxectos de protocolo e de xestor, chame saveToPreferences, chame loadFromPreferences e chame startVPNTunnel desde o xestor de finalización da carga. Arrancar antes de que a carga volva produce un erro de configuración non válida, código 1 de NEVPNErrorDomain, nunha configuración que por outra parte é correcta.

A forma é abondo curta para tela nun só sitio:

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

startVPNTunnel volve cando se acepta a solicitude, non cando o túnel está levantado. Observe NEVPNStatusDidChange e lea connection.status para o estado real. Unha app que supón éxito no punto da chamada informa dunha VPN conectada mentres a extensión aínda negocia. Un estado de conexión é normal por un momento; un estado que nunca o abandona é o fallo que merece rexistrarse.

Paso 3: déalle ao proceso do provedor o que necesita

Un transporte personalizado execútase nun proceso aparte co seu propio identificador de paquete e a súa propia autorización. Tanto a app contedora como o provedor necesitan a autorización de extensión de rede ao asinar, e unha compilación con Developer ID fóra do App Store aínda ten que levala no perfil de aprovisionamento. Unha autorización ausente parece un fallo de protocolo porque a extensión simplemente non arrinca.

Non hai ningún descriptor de socket público que tomar prestado. NEPacketTunnelProvider dálle NEPacketTunnelFlow con read, write e cancel, e o código que busca rutas privadas de claves rompe entre versións. O provedor segue executándose mentres a app está en segundo plano, así que a app contedora non necesita ningún modo de fondo para iso.

Paso 4: a demanda é un conxunto de regras, non un interruptor

isOnDemandEnabled só arma as regras; NEOnDemandRuleConnect e os seus irmáns deciden cando sobe o túnel. Unha regra de avaliación de conexión cun URL de sonda vale tanto como ese URL. Se a sonda responde sen o túnel, a regra conclúe que a rede privada xa é alcanzable e nunca conecta, así que apúnte a algo que só responda desde dentro.

O acendido permanente é unha promesa aparte. Necesita un dispositivo supervisado e un perfil xestionado, e un usuario non supervisado pode quitar un perfil cando queira. Non entregue un deseño que dependa do acendido permanente agás que o parque estea supervisado.

Paso 5: demostre o camiño, non a etiqueta

Escane xar interfaces tun, tap, ppp ou ipsec demostra que unha VPN está configurada, non que a súa solicitude a usase. NWPathMonitor con usesInterfaceType(.other) di que hai unha interface virtual dispoñible, e un xestor de viabilidade pode probar un só host. Ningún dos dous demostra a ruta de saída, así que combíneos cunha solicitude a un recurso ao que só o túnel poida chegar. Os nomes de interface son unha axuda de diagnóstico, nunca unha porta sobre a que deba ramificar a lóxica da aplicación.

Para unha comprobación de campo, compare o enderezo público con e sen o túnel e descargue unha páxina só interna. Unha chamada de estado pode informar de conectado mentres o provedor negocia, así que deixe que decida o resultado do recurso e trate o estado como proba de apoio.