Por qué tu app de iPhone no puede activar ni desactivar la VPN del sistema

Un jefe de producto pide un botón que encienda la VPN de la empresa, y la petición suena trivial. En iOS no es una función pequeña; queda fuera del contrato público, y cualquier solución alternativa falla en la revisión o se rompe en la siguiente versión. Pasa la petición por lo que la plataforma permite de verdad y el diseño casi se escribe solo. Una app puede poseer una configuración de VPN y arrancarla. Una app no puede llegar al interruptor del sistema, no puede leer el estado de un perfil que no ha creado y no puede mantener a un usuario conectado en contra de su voluntad.

Empieza por las tres cosas que quiere decir el usuario

Separa los significados antes de separar las API. A veces el usuario quiere el túnel de tu app conectado, a veces quiere que el interruptor de Ajustes se active para un perfil que instaló otra persona, y a veces quiere que el teléfono no pueda navegar sin el túnel. Eso corresponde a tres mecanismos distintos, y solo el primero está abierto a una app corriente.

El segundo significado es el que genera las preguntas de Stack Overflow, y no tiene respuesta admitida. El interruptor de Ajustes pertenece al usuario y, en dispositivos gestionados, al perfil. Ninguna API pública enumera configuraciones de VPN, informa de si el túnel del sistema está levantado ni lo conmuta.

Qué puede crear de verdad una app

NetworkExtension da a una app una configuración propia mediante NEVPNManager. Con el derecho Personal VPN y el consentimiento del usuario, la app guarda una configuración que aparece en Ajustes con su propio nombre, y puede arrancar o detener esa única conexión. Es una capacidad real y revisable, y también es todo el alcance: el gestor solo lee y escribe lo que ha creado.

El derecho no es automático. Lo pides a Apple y justificas por qué la app necesita un túnel, y un cliente cuyo único objetivo es encender el perfil de otra persona no tiene buena respuesta. Los proveedores de túneles de paquetes siguen la misma regla con otra clase: NETunnelProviderManager posee configuraciones basadas en proveedor que la propia app instaló. Ninguno de los dos caminos llega a un perfil entregado por MDM.

El consentimiento también se aplica al guardar. Escribir una configuración pide confirmación al usuario, y esa petición no es algo que una app pueda suprimir por comodidad.

Leer el estado choca con la misma pared

El estado parece más amable que el control y está igual de cerrado. NEVPNStatus informa de inválido, desconectado, conectando, conectado, reafirmando o desconectando para la configuración propia de la app, y se dispara una notificación en cada cambio. No dice nada de un túnel instalado por un perfil de gestión, que es justo el estado que un servicio de soporte quiere ver.

La monitorización de la ruta de red y los cambios de interfaz se ofrecen como sustitutos en las revisiones de diseño. Describen la ruta que sigue el tráfico de la app, que cambia por motivos ajenos al estado de la VPN, y usarlos como indicador de VPN da una interfaz que miente en las dos direcciones.

On Demand y Always On son las palancas reales

Las palancas admitidas viven en el perfil y no en la app. Las reglas On Demand dicen al sistema cuándo conectarse: una lista ordenada de condiciones con acciones, evaluada por el sistema operativo, no por tu código. Una regla que conecta en cualquier interfaz crea una sensación de conexión permanente sin dar ningún control a la app.

Always On VPN es el mecanismo de imposición, y va atado a la supervisión. En un dispositivo supervisado, MDM instala un perfil que mantiene el túnel levantado; en un teléfono personal no supervisado las mismas claves no producen el mismo comportamiento. Esa asimetría es deliberada, y ninguna combinación de claves de carga útil la elimina. Cuando el requisito es de verdad que la VPN debe estar encendida, el requisito es en realidad que el dispositivo debe estar gestionado.

Entre las dos se sienta el primo más débil: una regla que reconecta después de que el usuario se desconecte. Reconecta cuando la regla se evalúe la próxima vez, lo que no es lo mismo que de inmediato, y un usuario que se desconectó a propósito notará la diferencia. Diseña la interfaz alrededor de ese hueco en lugar de prometer un candado.

Publica el camino admitido

Cuatro preguntas fijan el mecanismo antes de que exista código: quién es el dueño del dispositivo, si está supervisado, qué cliente termina el túnel y de dónde viene el perfil. Si algo de eso es desconocido, la petición de funcionalidad no está lista para estimarse.

Una API privada que husmee en la VPN del sistema pasará una demo y suspenderá la revisión, y si se publica por otra vía se rompe en la siguiente versión de iOS. No hay versión de ese intercambio que merezca la pena por un interruptor.

La telemetría de gestión es un canal aparte: informa de que un perfil está instalado y de si el dispositivo cumple, lo que es informar y no una superficie de control por app. Prueba el flujo en un dispositivo real después de cada actualización, porque el comportamiento admitido vive en el sistema operativo y el sistema operativo se mueve.