Bloquear a configuración de VPN en Android: lista de comprobación do despregamento
Decida a política, confirme a autoridade da que dispón, comprobe o comportamento por versión e manteña vivo o camiño aprobado de conexión permanente antes de aplicalo.
Alguén lle pide que impida que a xente configure a súa propia VPN en dispositivos Android xestionados. A resposta tentadora é unha regra de cortalumes que bloquee uns cantos portos coñecidos. Esa resposta pasa por alto como funciona a plataforma e como se conectan realmente as aplicacións.
O control admitido é unha restrición de xestión sobre o dispositivo ou o perfil que vostede posúe, e ten un alcance explícito, un comportamento que depende da versión e unha excepción que debe configurar a propósito.
Percorra as cinco comprobacións seguintes en orde. Cada unha pode invalidar o plan, así que detéñase na primeira que non se cumpra.
Comprobación 1: decida que significa ningunha VPN
Tras a mesma frase escóndense dous requisitos. Un é que ningún usuario poida crear a súa propia VPN. O outro é que só poida executarse a VPN aprobada da organización. Ambos son lexítimos e producen configuracións distintas, historias de soporte distintas e modos de fallo distintos.
Anote cal dos dous está a mercar antes de tocar ningunha consola de xestión. Se a intención é un único túnel aprobado para todos, está a implementar un camiño aprobado cunha prohibición ao redor; se a intención é non ter ningún túnel, tamén debe aceptar que cambien os camiños de acceso remoto e de diagnóstico.
Equivoque isto e o despregamento parecerá funcionar mentres corta en silencio a VPN da que depende a operación, algo que adoita descubrir a persoa de garda nunha hora inoportuna.
Comprobación 2: confirme a autoridade que ten realmente
Android expón a restrición mediante UserManager.DISALLOW_CONFIG_VPN, documentada na referencia de UserManager. Impide a configuración e o arranque de VPN, e non é un axuste que unha aplicación corrente poida aplicarse a si mesma nin a outras aplicacións.
Aplícaa un administrador autorizado: un propietario do dispositivo para todo o dispositivo, ou un propietario do perfil para o perfil xestionado, coa mesma autoridade dispoñible para un propietario do perfil dentro do perfil xestionado. Se o seu EMM non pode actuar como un destes, non ten este control, e ningunha cantidade de configuración de políticas na consola o creará.
O alcance importa tanto como a autoridade. Unha restrición aplicada a un perfil de traballo goberna ese perfil, non a parte persoal do mesmo teléfono. Describilo como control sobre todo o que fai o usuario é inexacto, e porao a proba a primeira persoa que instale unha VPN no perfil persoal e comprobe que funciona.
Comprobación 3: coñeza o comportamento por versión
A restrición cambiou entre versións, e as diferenzas deciden que fará realmente o seu despregamento nos dispositivos sobre o terreo.
| Límite da plataforma | Comportamento documentado |
|---|---|
| Propietario do dispositivo ou do perfil | A restrición pode aplicarse baixo a autoridade dese propietario |
| API 24 e posteriores | O sistema segue iniciando unha VPN de conexión permanente configurada polo propietario do dispositivo ou do perfil |
| API 31 e posteriores | Activar a restrición desconecta unha VPN que o usuario xa tiña en marcha |
A fila de API 31 é a que sorprende a xente a metade do despregamento: neses dispositivos a aplicación non é cosmética, desconecta un túnel que xa estaba funcionando. Planifíqueo como un evento visible e non como un cambio silencioso de axustes.
A fila de API 24 é a que o salva: unha VPN de conexión permanente configurada polo propietario sobrevive á restrición, e así é como o camiño aprobado segue dispoñible.
Comprobación 4: manteña vivo o camiño aprobado
Configure e probe a VPN de conexión permanente da organización antes de aplicar a restrición, non despois. Se aplica primeiro, os dispositivos perden o túnel e as ferramentas coas que os diagnosticaría ao mesmo tempo.
Verifique tres cousas de forma explícita: que a VPN de conexión permanente a crea o propietario e non o usuario, que arrinca neses dispositivos despois da aplicación e que sobrevive a un reinicio. Un túnel que só sobe a man non é un camiño aprobado; é unha cola de tickets de soporte.
Manteña unha vía de recuperación que non dependa de que o túnel estea activo. Unha consola de xestión, un camiño de administrador local ou unha canle fóra de banda serven. O que non serve é supoñer que pode arranxar unha política rota a través da conexión que a política acaba de desactivar.
Comprobación 5: verifique e logo describa o límite con honestidade
Probe cun dispositivo real e unha conta real. Confirme que un usuario non pode engadir nin iniciar unha VPN, confirme que o túnel aprobado conecta e transporta tráfico, e confirme que o perfil persoal segue comportándose como se documenta. Eses tres resultados son os criterios de aceptación.
Despois teña coidado co que afirma. A restrición goberna a capacidade de VPN de Android. Non converte toda conexión permitida nun protocolo inspeccionado nin impide que unha aplicación encamiñe as súas propias peticións a través dun proxy explícito. Bloquear UDP 500, UDP 4500 e un OpenVPN porto non é o mesmo control, porque o tráfico pode viaxar por moitos transportes, incluído un HTTPS de aspecto corrente.
Se o requisito é máis amplo que a capacidade de VPN, combine isto coa política de distribución de aplicacións, os controis de conta e as restricións de rede axeitadas á contorna. E anote o que queda fóra do alcance, para que ninguén repita unha restrición parcial como completa na próxima auditoría.