Por qué una app no puede activar un perfil de VPN guardado en Android o iOS

Dos trabajos muy distintos se archivan bajo el nombre de VPN programática, y solo uno de ellos está disponible para una app corriente en cualquiera de las dos plataformas móviles. El primero es activar un perfil que el usuario ya guardó; el segundo es construir un túnel dentro de tu propio proceso. Android te da el segundo mediante VpnService e iOS te da el segundo mediante el derecho de Network Extension, mientras que el primero se queda con el sistema, un propietario del dispositivo o un servidor MDM. Averiguar cuál necesitas de verdad suele hacer el proyecto más pequeño.

Dos trabajos que comparten nombre

Activar un perfil guardado significa decirle a un túnel existente que suba: un host, una credencial, un protocolo, todo ya configurado en algún sitio que el usuario puede ver. Construir un túnel significa que tu código posee la interfaz, el bucle de paquetes y el protocolo. Se parecen en un backlog de producto y casi no comparten implementación.

Ninguna de las dos plataformas móviles expone el primero a una app SDK. Una conexión que aparece sin que el usuario haga nada es indistinguible del malware, así que ambos sistemas ponen una puerta de consentimiento delante de cualquier app que transporte tráfico.

Android: una puerta de consentimiento y ninguna API de perfiles

VpnService existe desde Android 4.0 y permite que una app cree una interfaz tun y luego lea y escriba paquetes. El servicio debe declararse con BIND_VPN_SERVICE, y VpnService.prepare() produce el diálogo del sistema que pide al usuario que lo permita. El ejemplo de la plataforma, ToyVpn, es la declaración más clara de la forma prevista: tu código posee la interfaz y todo lo que fluye por ella.

Lo que no hace es añadir una entrada a la pantalla de ajustes de VPN del sistema. No hay API pública para eso, y la app Ajustes guarda sus perfiles en un almacén al que una app corriente no llega. Las llamadas a las clases ocultas desde una aplicación normal producen perfiles que el sistema nunca lista, por eso el código que parecía funcionar en una compilación deja de funcionar en silencio en la siguiente.

La vía gestionada es aparte. Un propietario del dispositivo o del perfil puede designar un paquete de VPN siempre activo mediante las API de política del dispositivo, y una herramienta empresarial puede enviar un perfil que el usuario luego aprueba. Eso es autoridad de gestión del dispositivo, no un permiso que una app solicite al instalarse. Si tu cliente es una organización, esta es la vía para la que hay que planificar; si tu cliente es una persona que instala desde una tienda, no está disponible en absoluto.

iOS: el derecho es la frontera

iOS divide el mismo trabajo de otra manera. Un cliente VPN implementa un proveedor de túnel de paquetes o un proxy de app dentro del marco Network Extension, y el derecho correspondiente debe concederse a la cuenta de desarrollador. Una configuración de VPN personal mediante NEVPNManager existe para el caso más simple, y sigue ejecutándose dentro del mismo modelo de permisos. Apple documenta toda la superficie en la referencia de Network Extension, que conviene leer antes de delimitar el trabajo.

No hay forma soportada de abrir la pantalla de ajustes de VPN, leer las configuraciones guardadas del usuario o iniciar una de ellas. Lo que un cliente puede hacer es enviar un perfil de configuración para que el usuario lo instale, y luego usar el túnel resultante mediante llamadas de red corrientes. El túnel por app lo asigna un servidor MDM mediante una regla a demanda, no lo selecciona la app en tiempo de ejecución.

Un cliente VPN de un proveedor grande no es prueba de que tu cuenta pueda enviar lo mismo. Esos derechos se solicitan por cuenta de desarrollador y se revisan, así que el riesgo de calendario recae en Apple, no en tu plan de sprint.

El escritorio llega más lejos, pero la propiedad no cambia

Windows es el caso permisivo. Add-VpnConnection crea una entrada de libreta telefónica desde una sesión de PowerShell elevada, y rasdial la conecta o la desconecta desde un script. Una app también puede dirigir un cliente de proveedor mediante su línea de comandos documentada. Crear el perfil sigue siendo una acción administrativa, porque la entrada vive en un almacén de toda la máquina.

macOS se comporta igual con otras herramientas. scutil --nc start y stop operan sobre servicios que ya existen, mientras que crear uno es una tarea de administración del sistema. Poseer el proceso en un portátil no te convierte en propietario de la configuración.

Qué construir en su lugar

Si el requisito real es que tu app llegue a una API interna, el túnel que el usuario ya ejecuta basta. Haz peticiones HTTPS normales, deja que el sistema elija el camino, y deja de intentar controlar el túnel. Si el requisito es que solo el tráfico de tu app use el túnel, pide VPN por app por el canal de gestión, o termina TLS dentro de la app contra un servicio accesible sin él.

Las API ocultas no son un atajo que merezca la pena. Cambian entre versiones, fallan la revisión de apps, y los fallos que producen le parecen a quien hereda el código fallos de red corrientes. La comparación no es Android contra iOS; es poseer un túnel contra pedir a la plataforma que encamine el tráfico, y solo la primera es tuya para construir.