Cómo leer el estado de VPN y proxy de una app de trabajo gestionada

Una app de trabajo falla en un teléfono gestionado, alguien mira el interruptor de VPN, lo ve activado y declara que la ruta está sana. Ahí se detienen la mayoría de estos diagnósticos, y es demasiado pronto: un transporte VPN activo no dice que las solicitudes de esta app lo hayan usado, y el proxy que realmente se aplica puede ser por app o elegido por un archivo PAC en lugar de mostrarse en Ajustes. Empieza por la app y el perfil concretos que estás depurando y luego lee la visión que la plataforma tiene de la ruta.

Empieza por la app y su perfil

Una app con distintivo de trabajo suele ejecutarse en un perfil separado con su propia política de red. Un navegador personal en el mismo teléfono no es prueba de ello, y un resultado del dispositivo de un colega con otra gestión tampoco. Anota a qué perfil pertenece la app antes de leer nada.

En Ajustes, enumera las entradas VPN configuradas y anota quién posee cada una. En las compilaciones de Samsung las etiquetas del menú cambian entre versiones, así que describe la entrada en lugar de la ruta hasta ella. Una entrada en gris o gestionada pertenece a quien administra el dispositivo; desactivarla como experimento cambia lo que intentas medir y puede ir contra la política.

Lee el estado que informa la plataforma

Dentro de una actividad existente en tus herramientas de soporte, en API 23 o posterior, el estado de la red se puede leer sin enviar ni un byte. La llamada necesita el permiso de manifiesto normal ACCESS_NETWORK_STATE para la lectura de capacidades.

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

Cada valor responde a una pregunta estrecha. La red activa es la red predeterminada del proceso que llama en ese momento. La comprobación de capacidades te dice si esa red predeterminada tiene respaldo VPN. La llamada al proxy informa del proxy HTTP predeterminado efectivo, y el objeto devuelto puede describir tanto un proxy estático como un script PAC.

Si necesitas la vista por red en lugar de la predeterminada, lee las propiedades de enlace de la misma red y compáralas con cm.getLinkProperties(network)?.httpProxy. Un proxy instalado por la gestión del dispositivo aparece en la llamada del proxy predeterminado y no en las propiedades de enlace, lo que es una forma rápida de distinguir un proxy proporcionado por la política de uno que entregó la red.

Mantén la salida en tu canal de soporte en lugar de en un informe público. Los nombres de host del proxy, las URL de PAC y los sufijos internos revelan cómo enruta el tráfico tu organización, y ninguno de ellos hace falta para describir el fallo.

Interpreta cada campo de forma estrecha

Una red nula o un objeto de capacidades nulo significa que el estado de red del llamador no estaba disponible o cambió durante la lectura. No significa que no haya VPN. Trátalo como desconocido y vuelve a leer después de que la app haya pasado a primer plano, no como un resultado negativo.

Un transporte VPN es lo más débil de los positivos. Cualquier app que tenga un VpnService produce uno, incluida una app de filtrado local que nunca envía tu tráfico a ninguna parte. Así que un valor true dice que existe una red predeterminada con respaldo VPN, no que se haya usado la salida de tu organización y desde luego no que haya habido inspección.

Un proxy predeterminado nulo significa que esta API no informa ningún proxy HTTP predeterminado para la configuración efectiva. Descarta muy poco: una app puede llevar su propia configuración SOCKS, implementar su propio cliente HTTP o ser guiada por un proxy en la puerta de enlace que el dispositivo nunca conoce.

PAC es el caso que derrota una respuesta de un solo valor. Un script puede enrutar un destino a través de un proxy y enviar otro directo, así que dos solicitudes de la misma app en un segundo pueden tomar rutas distintas. Y una app que vincula sus sockets a una red elegida, o llama a bindProcessToNetwork, no está obligada a seguir el valor predeterminado en absoluto.

Qué no puede decirte esta instantánea

No es un historial. Nada aquí registra qué ruta tomó la solicitud que falla, y una lectura correcta después del fallo no es prueba sobre el fallo. Tampoco es un inventario: obtienes la red predeterminada del proceso que llama, no una lista de las conexiones privadas de cada app.

Tampoco dice nada sobre lo que ocurre por encima del socket. Un apretón de manos TLS que falla en un dispositivo gestionado puede ser un problema del almacén de confianza, una discrepancia de anclaje o un nombre que el proxy rechaza, y ninguno de ellos aparece en una lectura de conectividad.

Por eso las dos mitades importan juntas: la instantánea acota dónde mirar y los propios diagnósticos de la app dicen qué falló realmente.

Informa de ello en una forma que un administrador pueda usar

Da la app afectada, el perfil, la marca de tiempo y la etapa exacta que falló: resolución de nombres, conexión TCP, apretón de manos TLS o un estado HTTP. Añade los valores de la instantánea tal como se leyeron, con los nulos escritos como nulos y no como ninguno. Anota si otras apps del mismo perfil fallan de la misma manera, lo que separa un problema de app de un problema de ruta en todo el perfil.

Luego detente y deja que el propietario de la ruta responda. No trates un certificado corporativo, una dirección de proxy o una entrada VPN como permiso para quitar la gestión o saltarte la ruta aprobada; eso convierte un caso de soporte en un incidente de política.

El contrato del proxy predeterminado es breve y merece una lectura, porque define exactamente qué proxy informa la llamada, y toda lectura excesiva de esta instantánea empieza suponiendo que informa más.