L’aplicació de feina exigeix una VPN? Reviseu primer aquestes tres capes

El missatge diu que l’aplicació necessita una VPN, però el més habitual és que l’aplicació estigui informant d’un símptoma en lloc d’anomenar què l’ha bloquejada. Tres responsables diferents poden produir aquesta frase: el servei privat amb qui parla l’aplicació, el codi de polítiques de la mateixa aplicació i la capa de gestió del dispositiu que controla el perfil de feina. Quin dels tres pregunta canvia què heu de fer, i només un dels tres es resol connectant un túnel. Trobar primer el responsable us estalvia reinstal·lar un client que mai no va ser el problema.

Què pot comprovar la mateixa aplicació

Abans de suposar una regla oculta de la plataforma, recordeu que una aplicació normal pot veure si un transport VPN és actiu. ConnectivityManager informa de xarxes que porten TRANSPORT_VPN, i l’absència de NET_CAPABILITY_NOT_VPN diu a qualsevol cridador que la ruta actual passa per un túnel. Un desenvolupador que vulgui negar-se a funcionar fora d’un túnel pot fer-ho amb API públiques i sense cap eina empresarial.

El que l’aplicació no pot veure així és de qui és la VPN. Un indicador de transport diu que existeix un túnel, no que acabi on la vostra organització espera.

La ruta del servei: noms i adreces privats

La versió honesta més comuna del missatge no és gens una comprovació de polítiques. L’aplicació resol un nom d’amfitrió intern, com ara un wiki o un punt de connexió d’API que només existeix dins de la vista de DNS corporativa, i la cerca falla abans que s’executi cap codi de polítiques. El túnel pot estar actiu i deixar passar trànsit general d’internet mentre el DNS dividit envia aquest nom a un resolutor que no n’ha sentit parlar mai.

Els símptomes aquí són estrets. Falla un amfitrió, la resta de crides de xarxa de l’aplicació funcionen i la fallada apareix durant una cerca de nom, no en arrencar. Els certificats interns afegeixen un segon mode de fallada, perquè una aplicació fixada a la CA de l’organització rebutja un certificat públic encara que els paquets flueixin.

Connectar una VPN comercial qualsevol no arregla res d’això. Canvia la vostra adreça de sortida i deixa el nom intern igual d’irresoluble.

La capa de polítiques de l’aplicació

Una aplicació també pot portar la seva pròpia porta. Les configuracions gestionades permeten que l’organització enviï parells de clau i valor que l’aplicació declara, i l’aplicació els llegeix mitjançant RestrictionManager. Una clau com un nom de perfil obligatori o una llista de xarxes permeses és enterament disseny del desenvolupador, aplicat en el codi de l’aplicació amb el text d’error que triï aquest codi.

Aquesta capa és on la redacció normalment ho delata. Si el missatge apareix immediatament en arrencar, abans de qualsevol crida de xarxa, i esmenta una política, un perfil o un administrador, probablement esteu veient lògica de l’aplicació i no un paquet descartat.

Llegir la mateixa restricció en un dispositiu personal és un carreró sense sortida. Els dispositius no gestionats no tenen restriccions per llegir, així que l’aplicació torna al valor predeterminat amb què es va construir.

La capa de la plataforma: sempre actiu i bloqueig

La gestió del dispositiu afegeix una imposició que l’aplicació no pot anul·lar. Un controlador de polítiques de dispositiu pot cridar setAlwaysOnVpnPackage per al perfil de feina, opcionalment amb el bloqueig activat, i un cop activat el bloqueig la plataforma rebutja el trànsit que no passa per aquest paquet. El bloc es veu com una condició del sistema i no com un error de l’aplicació: les altres aplicacions del perfil també deixen d’arribar a la xarxa.

L’abast importa. La VPN sempre activa es configura per usuari, així que un paquet de perfil de feina no cobreix el vostre perfil personal, i una VPN personal no satisfà el paquet del perfil de feina. Dos perfils, dues polítiques de xarxa independents, un dispositiu.

També és l’única capa on una VPN aliena no pot ajudar, perquè la política anomena un paquet concret.

Distingir les tres

Recorreu els senyals en ordre i atureu-vos en el primer que encaixi. Que falli un sol nom d’amfitrió mentre tota la resta resol apunta a la ruta del servei. Un rebuig immediat en arrencar amb redacció de polítiques apunta a la lògica de l’aplicació. Que tot un perfil perdi connectivitat cada cop que es desconnecta el client aprovat apunta al bloqueig. I una aplicació que accepta qualsevol túnel està comprovant l’indicador de transport, no la identitat de la vostra organització.

Proves útils: el text exacte i el seu moment, si altres aplicacions del mateix perfil encara tenen connectivitat, si el nom privat resol dins del túnel aprovat i si el dispositiu mostra una insígnia de feina per a l’aplicació que heu obert.

Què cal posar a la sol·licitud de suport

Una sol·licitud que anomena la capa s’encamina correctament al primer intent. Una cosa així: l’aplicació del perfil de feina s’obre, la llista de recursos falla després de connectar-se la VPN aprovada, la resolució del nom privat falla al diagnòstic permès i les altres aplicacions del perfil continuen funcionant. Això es llegeix com un problema de ruta o de resolutor i evita el bucle de restabliment del compte.

Si la VPN aprovada falta del tot, la via admesa és la inscripció o el reaprovisionament a través del vostre administrador. Treure el perfil de gestió, instal·lar un client aliè o falsificar l’estat de la xarxa canvia la disposició de seguretat en lloc de restaurar-la.

Comenceu per la capa, no pel client. Els tres senyals anteriors solen resoldre-ho en una sola sessió.