¿A aplicación do traballo esixe unha VPN? Comprobe primeiro estas tres capas

A mensaxe di que a aplicación necesita unha VPN, pero o habitual é que a aplicación estea informando dun síntoma en lugar de nomear o que a bloqueou. Tres responsables distintos poden producir esa frase: o servizo privado co que fala a aplicación, o código de políticas da propia aplicación e a capa de xestión do dispositivo que controla o perfil de traballo. Cal deles pregunta cambia o que debe facer, e só un dos tres se arranxa conectando un túnel. Atopar primeiro o responsable aforra reinstalar un cliente que nunca foi o problema.

Que pode comprobar a propia aplicación

Antes de supoñer unha regra oculta da plataforma, lembre que unha aplicación normal pode ver se un transporte VPN está activo. ConnectivityManager informa de redes que levan TRANSPORT_VPN, e a ausencia de NET_CAPABILITY_NOT_VPN dille a calquera chamante que a ruta actual vai por un túnel. Un desenvolvedor que queira negarse a funcionar fóra dun túnel pode facelo con API públicas e sen ningunha ferramenta empresarial.

O que a aplicación non pode ver así é de quen é a VPN. Un indicador de transporte di que existe un túnel, non que remate onde a súa organización espera.

A ruta do servizo: nomes e enderezos privados

A versión honesta máis común da mensaxe non é en absoluto unha comprobación de políticas. A aplicación resolve un nome de host interno, como un wiki ou un punto de conexión de API que só existe dentro da vista de DNS corporativa, e a busca falla antes de que se execute ningún código de políticas. O túnel pode estar activo e deixar pasar tráfico xeral de internet mentres o DNS dividido envía ese nome a un resolutor que nunca oíu falar del.

Os síntomas aquí son estreitos. Falla un host, o resto das chamadas de rede da aplicación funciona e o fallo aparece durante unha busca de nome, non ao arrincar. Os certificados internos engaden un segundo modo de fallo, porque unha aplicación fixada á CA da organización rexeita un certificado público aínda que os paquetes flúan.

Conectar unha VPN comercial calquera non arranxa nada diso. Cambia o seu enderezo de saída e deixa o nome interno igual de irresoluble.

A capa de políticas da aplicación

Unha aplicación tamén pode levar a súa propia porta. As configuracións xestionadas permiten que a organización envíe pares de clave e valor que a aplicación declara, e a aplicación léos mediante RestrictionManager. Unha clave como un nome de perfil obrigatorio ou unha lista de redes permitidas é enteramente deseño do desenvolvedor, aplicado no código da aplicación co texto de erro que ese código escolla.

Esta capa é onde a redacción adoita delatalo. Se a mensaxe aparece inmediatamente ao arrincar, antes de calquera chamada de rede, e menciona unha política, un perfil ou un administrador, probabelmente estea vendo lóxica da aplicación en lugar dun paquete descartado.

Ler a mesma restrición nun dispositivo persoal é un camiño morto. Os dispositivos non xestionados non teñen restricións que ler, así que a aplicación volve ao valor predeterminado co que se construíu.

A capa da plataforma: sempre activo e bloqueo

A xestión do dispositivo engade unha imposición que a aplicación non pode anular. Un controlador de políticas de dispositivo pode chamar a setAlwaysOnVpnPackage para o perfil de traballo, opcionalmente co bloqueo activado, e unha vez activado o bloqueo a plataforma rexeita o tráfico que non pasa por ese paquete. O bloqueo vese como unha condición do sistema e non como un erro da aplicación: as demais aplicacións do perfil tamén deixan de chegar á rede.

O alcance importa. A VPN sempre activa configúrase por usuario, así que un paquete de perfil de traballo non cobre o seu perfil persoal, e unha VPN persoal non satisfai o paquete do perfil de traballo. Dous perfís, dúas políticas de rede independentes, un dispositivo.

Tamén é a única capa onde unha VPN allea non pode axudar, porque a política nomea un paquete concreto.

Distinguir as tres

Percorra os sinais en orde e detéñase no primeiro que encaixe. Que falle un só nome de host mentres todo o demais resolve apunta á ruta do servizo. Un rexeitamento inmediato ao arrincar con redacción de políticas apunta á lóxica da aplicación. Que todo un perfil perda conectividade cada vez que se desconecta o cliente aprobado apunta ao bloqueo. E unha aplicación que acepta calquera túnel está comprobando o indicador de transporte, non a identidade da súa organización.

Probas útiles: o texto exacto e o seu momento, se outras aplicacións do mesmo perfil seguen tendo conectividade, se o nome privado resolve dentro do túnel aprobado e se o dispositivo mostra unha insignia de traballo para a aplicación que abriu.

Que incluír na solicitude de soporte

Unha solicitude que nomea a capa enrútase correctamente ao primeiro intento. Algo así: a aplicación do perfil de traballo abre, a lista de recursos falla despois de conectarse a VPN aprobada, a resolución do nome privado falla no diagnóstico permitido e as demais aplicacións do perfil seguen funcionando. Iso lese como un problema de ruta ou de resolutor e evita o bucle de restablecemento da conta.

Se a VPN aprobada falta por completo, a vía admitida é a inscrición ou o reaprovisionamento a través do seu administrador. Retirar o perfil de xestión, instalar un cliente alleo ou falsificar o estado da rede cambia a configuración de seguridade en lugar de restaurala.

Empece pola capa, non polo cliente. Os tres sinais anteriores adoitan resolvelo nunha soa sesión.