Unha app de traballo falla nun teléfono xestionado, alguén mira o interruptor de VPN, veo activado e declara a ruta sana. Aquí detéñense a maioría destes diagnósticos, e é demasiado cedo: un transporte VPN activo non di que as solicitudes desta app o usasen, e o proxy que realmente se aplica pode ser por app ou escollido por un ficheiro PAC en lugar de mostrarse en Axustes. Comeza pola app e o perfil concretos que estás depurando e despois le a visión que a plataforma ten da ruta.

Comeza pola app e o seu perfil

Unha app con distintivo de traballo adoita executarse nun perfil separado coa súa propia política de rede. Un navegador persoal no mesmo teléfono non é proba diso, e un resultado do dispositivo dun colega con outra xestión tampouco. Anota a que perfil pertence a app antes de ler calquera cousa.

En Axustes, enumera as entradas VPN configuradas e anota quen posúe cada unha. Nas compilacións de Samsung as etiquetas do menú cambian entre versións, así que describe a entrada en lugar da ruta ata ela. Unha entrada en gris ou xestionada pertence a quen administra o dispositivo; desactivala como experimento cambia o que intentas medir e pode ir contra a política.

Le o estado que informa a plataforma

Dentro dunha actividade existente nas túas ferramentas de soporte, en API 23 ou posterior, o estado da rede pódese ler sen enviar nin un byte. A chamada necesita o permiso de manifesto normal ACCESS_NETWORK_STATE para a 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 unha pregunta estreita. A rede activa é a rede predeterminada do proceso que chama nese momento. A comprobación de capacidades diche se esa rede predeterminada ten respaldo VPN. A chamada ao proxy informa do proxy HTTP predeterminado efectivo, e o obxecto devolto pode describir tanto un proxy estático como un script PAC.

Se necesitas a vista por rede en lugar da predeterminada, le as propiedades de enlace da mesma rede e compáraas con cm.getLinkProperties(network)?.httpProxy. Un proxy instalado pola xestión do dispositivo aparece na chamada do proxy predeterminado e non nas propiedades de enlace, o que é unha forma rápida de distinguir un proxy proporcionado pola política dun que entregou a rede.

Mantén a saída na túa canle de soporte en lugar de nun informe público. Os nomes de host do proxy, as URL de PAC e os sufixos internos revelan como encamiña o tráfico a túa organización, e ningún deles fai falta para describir o fallo.

Interpreta cada campo de forma estreita

Unha rede nula ou un obxecto de capacidades nulo significa que o estado de rede do chamador non estaba dispoñible ou cambiou durante a lectura. Non significa que non haxa VPN. Trátalo como descoñecido e volve ler despois de que a app pasase a primeiro plano, non como un resultado negativo.

Un transporte VPN é o máis feble dos positivos. Calquera app que teña un VpnService produce un, incluída unha app de filtrado local que nunca envía o teu tráfico a ningures. Así que un valor true di que existe unha rede predeterminada con respaldo VPN, non que se usase a saída da túa organización e desde logo non que houbese inspección.

Un proxy predeterminado nulo significa que esta API non informa ningún proxy HTTP predeterminado para a configuración efectiva. Descarta moi pouco: unha app pode levar a súa propia configuración SOCKS, implementar o seu propio cliente HTTP ou ser guiada por un proxy na pasarela que o dispositivo nunca coñece.

PAC é o caso que derrota unha resposta dun só valor. Un script pode encamiñar un destino a través dun proxy e enviar outro directo, así que dúas solicitudes da mesma app nun segundo poden tomar rutas distintas. E unha app que liga os seus sockets a unha rede escollida, ou chama bindProcessToNetwork, non está obrigada a seguir o predeterminado en absoluto.

Que non che pode dicir esta instantánea

Non é un historial. Nada aquí rexistra que ruta tomou a solicitude que falla, e unha lectura correcta despois do fallo non é proba sobre o fallo. Tampouco é un inventario: obtés a rede predeterminada do proceso que chama, non unha lista das conexións privadas de cada app.

Tampouco di nada sobre o que ocorre por riba do socket. Un apretón de mans TLS que falla nun dispositivo xestionado pode ser un problema do almacén de confianza, unha discrepancia de ancoraxe ou un nome que o proxy rexeita, e ningún deles aparece nunha lectura de conectividade.

Por iso as dúas metades importan xuntas: a instantánea acouta onde mirar e os propios diagnósticos da app din que fallou realmente.

Infórmalo nunha forma que un administrador poida usar

Dá a app afectada, o perfil, a marca de tempo e a etapa exacta que fallou: resolución de nomes, conexión TCP, apretón de mans TLS ou un estado HTTP. Engade os valores da instantánea tal como se leron, cos nulos escritos como nulos e non como ningún. Anota se outras apps do mesmo perfil fallan do mesmo xeito, o que separa un problema de app dun problema de ruta en todo o perfil.

Logo detente e deixa que o propietario da ruta responda. Non trates un certificado corporativo, unha dirección de proxy ou unha entrada VPN como permiso para quitar a xestión ou saltar a ruta aprobada; iso converte un caso de soporte nun incidente de política.

O contrato do proxy predeterminado é breve e merece unha lectura, porque define exactamente que proxy informa a chamada, e toda lectura excesiva desta instantánea comeza supoñendo que informa máis.

Artigos relacionados