Como ler o estado de VPN e proxy de uma app de trabalho gerida

Uma app de trabalho falha num telefone gerido, alguém verifica o interruptor de VPN, vê-o ligado e declara o caminho saudável. É aqui que a maioria destes diagnósticos para, e é demasiado cedo: um transporte VPN ativo não diz que os pedidos desta app o usaram, e o proxy que realmente se aplica pode ser por app ou escolhido por um ficheiro PAC em vez de aparecer nas Definições. Comece pela app e pelo perfil específicos que está a depurar e depois leia a visão da própria plataforma sobre o caminho.

Comece pela app e pelo seu perfil

Uma app com crachá de trabalho costuma correr num perfil separado com a sua própria política de rede. Um navegador pessoal no mesmo telefone não é prova disso, e um resultado do dispositivo de um colega com outra gestão também não. Anote a que perfil pertence a app antes de ler o que quer que seja.

Nas Definições, liste as entradas VPN configuradas e anote quem é dono de cada uma. Nas compilações Samsung, as etiquetas do menu mudam entre versões, por isso descreva a entrada e não o caminho até ela. Uma entrada cinzenta ou gerida pertence a quem administra o dispositivo; desativá-la como experiência muda aquilo que está a tentar medir e pode ir contra a política.

Leia o estado que a plataforma relata

Dentro de uma atividade existente nas suas ferramentas de suporte, na API 23 ou posterior, o estado da rede pode ser lido sem enviar um único byte. A chamada precisa da permissão de manifesto normal ACCESS_NETWORK_STATE para a leitura 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 uma pergunta estreita. A rede ativa é a rede predefinida do processo que chama naquele momento. A verificação de capacidades diz-lhe se essa rede predefinida é suportada por VPN. A chamada ao proxy relata o proxy HTTP predefinido efetivo, e o objeto devolvido pode descrever tanto um proxy estático como um script PAC.

Se precisar da vista por rede em vez da predefinida, leia as propriedades de ligação da mesma rede e compare com cm.getLinkProperties(network)?.httpProxy. Um proxy instalado pela gestão do dispositivo aparece na chamada do proxy predefinido e não nas propriedades de ligação, o que é uma forma rápida de distinguir um proxy fornecido pela política de um que a rede atribuiu.

Mantenha a saída no seu canal de suporte em vez de num relatório público. Os nomes de anfitrião do proxy, os URL PAC e os sufixos internos revelam como a sua organização encaminha o tráfego, e nenhum deles é necessário para descrever a falha.

Interprete cada campo de forma estreita

Uma rede nula ou um objeto de capacidades nulo significa que o estado de rede do autor da chamada não estava disponível ou mudou durante a leitura. Não significa que não exista VPN. Trate-o como desconhecido e leia novamente depois de a app ter passado para primeiro plano, e não como um resultado negativo.

Um transporte VPN é o mais fraco dos positivos. Qualquer app que detenha um VpnService produz um, incluindo uma app de filtragem local que nunca envia o seu tráfego para lado nenhum. Portanto, um valor true diz que existe uma rede predefinida suportada por VPN, não que a saída da sua organização tenha sido usada e certamente não que tenha havido inspeção.

Um proxy predefinido nulo significa que esta API não relata qualquer proxy HTTP predefinido para a configuração efetiva. Exclui muito pouco: uma app pode trazer a sua própria definição SOCKS, implementar o seu próprio cliente HTTP ou ser guiada por um proxy no gateway que o dispositivo nunca conhece.

PAC é o caso que derrota uma resposta de valor único. Um script pode encaminhar um destino através de um proxy e enviar outro diretamente, pelo que dois pedidos da mesma app no espaço de um segundo podem seguir caminhos diferentes. E uma app que liga os seus sockets a uma rede escolhida, ou chama bindProcessToNetwork, não é obrigada a seguir a predefinição de todo.

O que esta instantânea não lhe pode dizer

Isto não é um histórico. Nada aqui registe que caminho seguiu o pedido que falhou, e uma leitura bem-sucedida após a falha não é prova sobre a falha. Também não é um inventário: obtém a rede predefinida do processo que chama, não uma lista das ligações privadas de cada app.

Também não diz nada sobre o que acontece acima do socket. Um aperto de mão TLS que falha num dispositivo gerido pode ser um problema do armazenamento de confiança, uma divergência de fixação ou um nome que o proxy recusa, e nenhum deles aparece numa leitura de conetividade.

É por isso que as duas metades contam em conjunto: a instantânea restringe onde olhar, e o próprio diagnóstico da app diz o que falhou realmente.

Comunique-o numa forma que um administrador possa usar

Indique a app afetada, o perfil, a marca temporal e a fase exata que falhou: resolução de nomes, ligação TCP, aperto de mão TLS ou um estado HTTP. Acrescente os valores da instantânea tal como foram lidos, com os nulos escritos como nulos e não como nenhum. Anote se outras apps no mesmo perfil falham da mesma forma, o que separa um problema de app de um problema de caminho em todo o perfil.

Depois pare e deixe o dono do caminho responder. Não trate um certificado empresarial, um endereço de proxy ou uma entrada VPN como autorização para remover a gestão ou contornar a rota aprovada; isso transforma um caso de suporte num incidente de política.

O contrato do proxy predefinido é curto e vale uma leitura, porque define exatamente qual proxy a chamada relata, e toda a leitura excessiva desta instantânea começa por assumir que relata mais.