VPN por aplicación en apps gestionadas del iPhone: qué se enruta y qué no
Un túnel por aplicación sigue a la app gestionada, no al teléfono. Compruebe la asociación del perfil, la copia gestionada, las reglas bajo demanda y los flujos que salen de la app.
La VPN por aplicación en el iPhone no es un interruptor para todo el teléfono. Es una asociación entre una app gestionada y un perfil de VPN, creada cuando se despliega la app, y el tráfico de todo lo demás conserva la ruta que tenía antes. Por eso el mismo teléfono se comporta de forma incoherente: la app de trabajo abre una página privada mientras Safari no llega al mismo host, o el túnel no levanta y la app informa de un tiempo de espera que parece credenciales incorrectas. Las comprobaciones van de la causa más amplia hacia abajo, así que deténgase en la primera que falle.
Compruebe primero el perfil y el registro de la app
La asociación vive en dos objetos, no en uno. El perfil de VPN define el túnel: tipo, servidor, autenticación, DNS y el identificador de paquete del proveedor cuando se usa un cliente personalizado. El registro de la app apunta a ese perfil, y la mayoría de consolas de gestión lo ofrecen como opción por aplicación en la configuración de la app, con un nombre cercano a Per-App VPN. Un perfil al que no apunta ninguna app no enruta nada por aplicación; se comporta como un túnel normal que alguien debe iniciar a mano.
Lea ambos objetos antes de tocar el teléfono. Confirme que la configuración de la app hace referencia al perfil que prueba y no a una copia antigua, porque los perfiles duplicados con nombres casi idénticos son habituales tras una migración y la app apuntará gustosa al retirado. Luego confirme que la configuración llegó al dispositivo: Ajustes, General, VPN y gestión de dispositivos debe mostrarla como perfil instalado. La lista de VPN de allí no es la prueba. Un servicio por aplicación normalmente no tiene interruptor manual, así que una configuración desplegada correctamente puede no aparecer nunca entre las VPN que se pueden iniciar. La ausencia se ve en el registro de la app y en si el túnel se levanta en la primera petición de la app.
Una condición explica muchos tickets: este modelo necesita que la app llegue a través de la gestión. Una copia instalada por otra vía o comprada personalmente no obtiene la asociación, aunque su identificador de paquete coincida. La guía de despliegue de VPN de Apple describe el modelo de perfil que hay detrás (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Confirme que la app instalada es la copia gestionada
La asociación sigue a la app instalada y gestionada. Si alguien la reinstaló desde el App Store con un Apple ID personal, la sustituyó por una compilación empresarial re-firmada o el dispositivo se volvió a inscribir y la app volvió por otro canal, el túnel puede quedarse abajo mientras la app parece completamente normal.
Pruebe por comparación, no con una sola observación. En el inventario de gestión, la app debe figurar como gestionada para ese dispositivo con el mapeo de VPN en su registro. En el teléfono, el túnel debe levantarse cuando se lanza la app y sale su primera petición, no solo cuando alguien inicia una configuración manual aparte en Ajustes. Si lanzar la app no cambia nada y esa configuración manual sí, la app no está vinculada a ningún túnel por aplicación.
Las actualizaciones importan: la que se envía por gestión conserva el mapeo, mientras que una reinstalación iniciada por el usuario puede perderlo. Cuando la queja data de una actualización, mire el registro de la app antes que la red.
Compruebe qué puede tomar el túnel
Un túnel por aplicación se selecciona por la app de origen, así que la ruta predeterminada del teléfono sigue perteneciendo al Wi-Fi o a la red móvil. OverridePrimary es la clave que cambia eso. Cuando un perfil la establece, el túnel se comporta como un túnel completo y todas las apps lo heredan, de modo que todo lo que pasa por la VPN se convierte en una cuestión de perfil y no en un fallo de la app.
Las reglas bajo demanda deciden la persistencia. OnDemandEnabled y su conjunto de reglas hacen que el túnel vuelva cuando la app envía tráfico, sobreviva a un cambio de Wi-Fi a red móvil o caiga cuando la app pasa a segundo plano. Un despliegue que se conecta y luego muere en silencio suele tener una regla que solo coincide con una sonda que nunca se activa mientras la app está inactiva.
Luego lea el lado de las rutas con honestidad. Si un perfil de proveedor o de fabricante aporta una lista de inclusión, un túnel que solo lleva 10.20.0.0/16 no llevará un servicio en 10.30.0.0/16; es la lista haciendo su trabajo, no un fallo por aplicación. El perfil integrado de iOS no tiene lista de inclusión. Sin una, la división sigue los valores predeterminados del proveedor e IncludeAllNetworks, no una lista oculta.
Pruebe la app y luego qué sale de ella
Pruebe con un nombre, no solo con una dirección. Resolver un host interno dentro de la app gestionada demuestra que el DNS también pasó por el túnel, porque el perfil decide qué resolutor responde y qué dominios de búsqueda se aplican. El enrutamiento puede ser perfecto mientras falla la búsqueda de nombres, y los dos síntomas apuntan a ajustes distintos.
Luego pruebe el límite desde ambos lados. Una app personal o Safari debería llegar a una página pública normal e informar de la dirección del operador o de casa, mientras que la app gestionada llega al servicio privado. Si ambas informan de la misma dirección pública, el túnel ya no es por aplicación, diga lo que diga el registro de la app.
Los flujos que salen de la app producen los tickets confusos. Un enlace que se abre en Safari, un documento pasado por la hoja de compartir o un inicio de sesión SSO que pasa a un navegador salen del proceso de la app y del túnel con él. Un inicio de sesión mostrado dentro de la app se atribuye normalmente a la app, así que un inicio incrustado puede funcionar donde la misma URL falla en Safari; verifíquelo en lugar de suponerlo. Cuando el proveedor de identidad solo es accesible por el túnel, o mantiene el inicio dentro de la app o añade el dominio del proveedor a los dominios de Safari del perfil para que se capture el tráfico de Safari coincidente.
Empareje el síntoma con la capa
La forma del fallo le dice qué comprobación repetir.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
Detrás de las filas centrales hay dos detalles: un túnel por aplicación puede estar sano y aun así perder una subred que ninguna lista de proveedor incluye, y un teléfono gestionado puede tener más de una configuración de VPN, así que confirme a cuál está vinculada la app en lugar de suponer que es la que lee.
Corrija en este orden: arregle el registro de la app para que haga referencia al perfil activo, reinstale la app a través de la gestión, confirme que el túnel se levanta en la primera petición de la app y repita las pruebas de nombre y de límite. Si la primera petición no puede iniciar ningún túnel, deténgase y mire el lado del proveedor, porque un cliente personalizado necesita su Network Extension presente y su identificador coincidente con la app instalada.
Devuelva tres hechos en lugar de una captura: a qué perfil hace referencia el registro de la app, si Ajustes lo muestra como perfil instalado y cuál fue la petición que falló, un nombre, una dirección o un traspaso al navegador. Esas tres respuestas separan un error de despliegue de uno de enrutamiento, y la siguiente persona puede actuar sin repetir el diagnóstico.