A aplicação de trabalho exige uma VPN? Verifique primeiro estas três camadas

A mensagem diz que a aplicação precisa de uma VPN, mas normalmente a aplicação está a reportar um sintoma em vez de nomear aquilo que a bloqueou. Três responsáveis distintos podem produzir essa frase: o serviço privado com quem a aplicação fala, o código de políticas da própria aplicação e a camada de gestão do dispositivo que controla o perfil de trabalho. Qual deles está a perguntar muda o que deve fazer, e apenas um dos três se resolve ligando um túnel. Encontrar primeiro o responsável poupa-o de reinstalar um cliente que nunca foi o problema.

O que a própria aplicação pode verificar

Antes de assumir uma regra oculta da plataforma, lembre-se de que uma aplicação normal consegue ver se um transporte VPN está ativo. O ConnectivityManager reporta redes que transportam TRANSPORT_VPN, e a ausência de NET_CAPABILITY_NOT_VPN diz a qualquer chamador que o caminho atual passa por um túnel. Um programador que queira recusar funcionar fora de um túnel pode fazê-lo com APIs públicas e sem qualquer ferramenta empresarial.

O que a aplicação não consegue ver assim é de quem é a VPN. Um indicador de transporte diz que existe um túnel, não que termina onde a sua organização espera.

O caminho do serviço: nomes e endereços privados

A versão honesta mais comum da mensagem não é de todo uma verificação de políticas. A aplicação resolve um nome de anfitrião interno, como um wiki ou um ponto final de API que só existe na vista de DNS da empresa, e a pesquisa falha antes de correr qualquer código de políticas. O túnel pode estar ativo e a deixar passar tráfego geral da internet enquanto o DNS dividido envia esse nome a um resolvedor que nunca ouviu falar dele.

Os sintomas aqui são estreitos. Um anfitrião falha, as restantes chamadas de rede da aplicação funcionam, e a falha aparece durante uma pesquisa de nome e não no arranque. Os certificados internos acrescentam um segundo modo de falha, porque uma aplicação fixada à CA da organização rejeita um certificado público mesmo quando os pacotes fluem.

Ligar uma VPN comercial qualquer não corrige nada disso. Muda o seu endereço de saída e deixa o nome interno igualmente por resolver.

A camada de políticas da aplicação

Uma aplicação também pode trazer a sua própria porta. As configurações geridas permitem que a organização envie pares de chave e valor que a aplicação declara, e a aplicação lê-os através do RestrictionManager. Uma chave como um nome de perfil obrigatório ou uma lista de redes permitidas é inteiramente conceção do programador, aplicada no código da aplicação com o texto de erro que esse código escolher.

É nesta camada que a formulação costuma denunciar. Se a mensagem aparece imediatamente no arranque, antes de qualquer chamada de rede, e menciona uma política, um perfil ou um administrador, está provavelmente a ver lógica da aplicação e não um pacote perdido.

Ler a mesma restrição num dispositivo pessoal é um beco sem saída. Os dispositivos não geridos não têm restrições para ler, por isso a aplicação volta ao valor predefinido com que foi construída.

A camada da plataforma: sempre ativo e bloqueio

A gestão do dispositivo acrescenta uma imposição que a aplicação não pode anular. Um controlador de políticas de dispositivo pode chamar setAlwaysOnVpnPackage para o perfil de trabalho, opcionalmente com o bloqueio ativado, e uma vez ativo o bloqueio a plataforma recusa tráfego que não passe por esse pacote. O bloqueio é visível como uma condição de sistema e não como um erro da aplicação: as outras aplicações do perfil também deixam de chegar à rede.

O âmbito importa. A VPN sempre ativa é configurada por utilizador, por isso um pacote do perfil de trabalho não cobre o seu perfil pessoal, e uma VPN pessoal não satisfaz o pacote do perfil de trabalho. Dois perfis, duas políticas de rede independentes, um dispositivo.

É também a única camada em que uma VPN alheia não pode ajudar, porque a política nomeia um pacote específico.

Distinguir as três

Percorra os sinais por ordem e pare no primeiro que encaixe. Um nome de anfitrião a falhar enquanto tudo o resto resolve aponta para o caminho do serviço. Uma recusa imediata no arranque com formulação de política aponta para a lógica da aplicação. Um perfil inteiro a perder conectividade sempre que o cliente aprovado se desliga aponta para o bloqueio. E uma aplicação que aceita qualquer túnel está a verificar o indicador de transporte, não a identidade da sua organização.

Provas úteis: o texto exato e o seu momento, se outras aplicações do mesmo perfil ainda têm conectividade, se o nome privado resolve dentro do túnel aprovado e se o dispositivo mostra um distintivo de trabalho para a aplicação que abriu.

O que incluir no pedido de suporte

Um pedido que nomeia a camada é encaminhado corretamente à primeira tentativa. Algo como: a aplicação do perfil de trabalho abre, a lista de recursos falha depois de a VPN aprovada ligar, a resolução do nome privado falha no diagnóstico permitido, e as outras aplicações do perfil continuam a funcionar. Isso lê-se como um problema de rota ou de resolvedor e evita o ciclo de reposição da conta.

Se a VPN aprovada faltar por completo, a via suportada é a inscrição ou o reprovisionamento através do seu administrador. Remover o perfil de gestão, instalar um cliente alheio ou falsificar o estado da rede muda a disposição de segurança em vez de a restaurar.

Comece pela camada, não pelo cliente. Os três sinais acima costumam resolvê-lo numa única sessão.