¿La aplicación del trabajo exige una VPN? Revise primero estas tres capas

El mensaje dice que la aplicación necesita una VPN, pero lo habitual es que esté informando de un síntoma en lugar de nombrar lo que la bloqueó. Tres responsables distintos pueden producir esa frase: el servicio privado con el que habla la aplicación, el código de políticas de la propia aplicación y la capa de gestión del dispositivo que controla el perfil de trabajo. Cuál de ellos pregunta cambia lo que debe hacer, y solo uno de los tres se arregla conectando un túnel. Encontrar primero al responsable le ahorra reinstalar un cliente que nunca fue el problema.

Qué puede comprobar la propia aplicación

Antes de suponer una regla oculta de la plataforma, recuerde que una aplicación normal puede ver si un transporte VPN está activo. ConnectivityManager informa de redes que llevan TRANSPORT_VPN, y la ausencia de NET_CAPABILITY_NOT_VPN dice a cualquier llamante que la ruta actual va por un túnel. Un desarrollador que quiera negarse a funcionar fuera de un túnel puede hacerlo con API públicas y sin ninguna herramienta empresarial.

Lo que la aplicación no puede ver así es de quién es la VPN. Un indicador de transporte dice que existe un túnel, no que termine donde su organización espera.

La ruta del servicio: nombres y direcciones privados

La versión honesta más común del mensaje no es en absoluto una comprobación de políticas. La aplicación resuelve un nombre de host interno, como un wiki o un punto de conexión de API que solo existe dentro de la vista de DNS corporativa, y la búsqueda falla antes de que se ejecute ningún código de políticas. El túnel puede estar activo y dejar pasar tráfico general de internet mientras el DNS dividido envía ese nombre a un resolutor que nunca ha oído hablar de él.

Los síntomas aquí son estrechos. Falla un host, el resto de las llamadas de red de la aplicación funciona y el fallo aparece durante una búsqueda de nombre, no al arrancar. Los certificados internos añaden un segundo modo de fallo, porque una aplicación fijada a la CA de la organización rechaza un certificado público aunque los paquetes fluyan.

Conectar una VPN comercial cualquiera no arregla nada de eso. Cambia su dirección de salida y deja el nombre interno igual de irresoluble.

La capa de políticas de la aplicación

Una aplicación también puede llevar su propia puerta. Las configuraciones gestionadas permiten que la organización envíe pares de clave y valor que la aplicación declara, y la aplicación los lee mediante RestrictionManager. Una clave como un nombre de perfil obligatorio o una lista de redes permitidas es enteramente diseño del desarrollador, aplicado en el código de la aplicación con el texto de error que ese código elija.

Esta capa es donde la redacción suele delatarlo. Si el mensaje aparece inmediatamente al arrancar, antes de cualquier llamada de red, y menciona una política, un perfil o un administrador, probablemente esté viendo lógica de la aplicación en lugar de un paquete descartado.

Leer la misma restricción en un dispositivo personal es un callejón sin salida. Los dispositivos no gestionados no tienen restricciones que leer, así que la aplicación vuelve al valor predeterminado con el que se construyó.

La capa de la plataforma: siempre activo y bloqueo

La gestión del dispositivo añade una imposición que la aplicación no puede anular. Un controlador de políticas de dispositivo puede llamar a setAlwaysOnVpnPackage para el perfil de trabajo, opcionalmente con el bloqueo activado, y una vez activado el bloqueo la plataforma rechaza el tráfico que no pasa por ese paquete. El bloqueo se ve como una condición del sistema y no como un error de la aplicación: las demás aplicaciones del perfil también dejan de llegar a la red.

El alcance importa. La VPN siempre activa se configura por usuario, así que un paquete de perfil de trabajo no cubre su perfil personal, y una VPN personal no satisface el paquete del perfil de trabajo. Dos perfiles, dos políticas de red independientes, un dispositivo.

También es la única capa donde una VPN ajena no puede ayudar, porque la política nombra un paquete concreto.

Distinguir las tres

Recorra las señales en orden y deténgase en la primera que encaje. Que falle un solo nombre de host mientras todo lo demás resuelve apunta a la ruta del servicio. Un rechazo inmediato al arrancar con redacción de políticas apunta a la lógica de la aplicación. Que todo un perfil pierda conectividad cada vez que se desconecta el cliente aprobado apunta al bloqueo. Y una aplicación que acepta cualquier túnel está comprobando el indicador de transporte, no la identidad de su organización.

Pruebas útiles: el texto exacto y su momento, si otras aplicaciones del mismo perfil siguen teniendo conectividad, si el nombre privado resuelve dentro del túnel aprobado y si el dispositivo muestra una insignia de trabajo para la aplicación que abrió.

Qué incluir en la solicitud de soporte

Una solicitud que nombra la capa se enruta correctamente al primer intento. Algo así: la aplicación del perfil de trabajo se abre, la lista de recursos falla después de conectarse la VPN aprobada, la resolución del nombre privado falla en el diagnóstico permitido y las demás aplicaciones del perfil siguen funcionando. Eso se lee como un problema de ruta o de resolutor y evita el bucle de restablecimiento de la cuenta.

Si la VPN aprobada falta por completo, la vía admitida es la inscripción o el reaprovisionamiento a través de su administrador. Quitar el perfil de gestión, instalar un cliente ajeno o falsear el estado de la red cambia la configuración de seguridad en lugar de restaurarla.

Empiece por la capa, no por el cliente. Las tres señales anteriores suelen resolverlo en una sola sesión.