Bloquear la configuración de VPN en Android: lista de comprobación del despliegue
Decida la política, confirme la autoridad de la que dispone, compruebe el comportamiento por versión y mantenga vivo el camino aprobado de conexión permanente antes de aplicarlo.
Alguien le pide que impida que la gente configure su propia VPN en dispositivos Android gestionados. La respuesta tentadora es una regla de cortafuegos que bloquee unos cuantos puertos conocidos. Esa respuesta pasa por alto cómo funciona la plataforma y cómo se conectan realmente las aplicaciones.
El control admitido es una restricción de gestión sobre el dispositivo o el perfil que usted posee, y tiene un alcance explícito, un comportamiento que depende de la versión y una excepción que debe configurar a propósito.
Recorra las cinco comprobaciones siguientes en orden. Cada una puede invalidar el plan, así que deténgase en la primera que no se cumpla.
Comprobación 1: decida qué significa ninguna VPN
Tras la misma frase se esconden dos requisitos. Uno es que ningún usuario pueda crear su propia VPN. El otro es que solo pueda ejecutarse la VPN aprobada de la organización. Ambos son legítimos y producen configuraciones distintas, historias de soporte distintas y modos de fallo distintos.
Anote cuál de los dos está comprando antes de tocar ninguna consola de gestión. Si la intención es un único túnel aprobado para todos, está implementando un camino aprobado con una prohibición alrededor; si la intención es no tener ningún túnel, también debe aceptar que cambien los caminos de acceso remoto y de diagnóstico.
Equivoque esto y el despliegue parecerá funcionar mientras corta en silencio la VPN de la que depende la operación, algo que suele descubrir la persona de guardia a una hora inoportuna.
Comprobación 2: confirme la autoridad que tiene realmente
Android expone la restricción mediante UserManager.DISALLOW_CONFIG_VPN, documentada en la referencia de UserManager. Impide la configuración y el arranque de VPN, y no es un ajuste que una aplicación corriente pueda aplicarse a sí misma ni a otras aplicaciones.
La aplica un administrador autorizado: un propietario del dispositivo para todo el dispositivo, o un propietario del perfil para el perfil gestionado, con la misma autoridad disponible para un propietario del perfil dentro del perfil gestionado. Si su EMM no puede actuar como uno de esos, no tiene este control, y ninguna cantidad de configuración de políticas en la consola lo creará.
El alcance importa tanto como la autoridad. Una restricción aplicada a un perfil de trabajo gobierna ese perfil, no la parte personal del mismo teléfono. Describirlo como control sobre todo lo que hace el usuario es inexacto, y lo pondrá a prueba la primera persona que instale una VPN en el perfil personal y compruebe que funciona.
Comprobación 3: conozca el comportamiento por versión
La restricción ha cambiado entre versiones, y las diferencias deciden qué hará realmente su despliegue en los dispositivos sobre el terreno.
| Límite de la plataforma | Comportamiento documentado |
|---|---|
| Propietario del dispositivo o del perfil | La restricción puede aplicarse bajo la autoridad de ese propietario |
| API 24 y posteriores | El sistema sigue iniciando una VPN de conexión permanente configurada por el propietario del dispositivo o del perfil |
| API 31 y posteriores | Activar la restricción desconecta una VPN que el usuario ya tenía en marcha |
La fila de API 31 es la que sorprende a la gente a mitad del despliegue: en esos dispositivos la aplicación no es cosmética, desconecta un túnel que ya estaba funcionando. Planifíquelo como un evento visible y no como un cambio silencioso de ajustes.
La fila de API 24 es la que le salva: una VPN de conexión permanente configurada por el propietario sobrevive a la restricción, y así es como el camino aprobado sigue disponible.
Comprobación 4: mantenga vivo el camino aprobado
Configure y pruebe la VPN de conexión permanente de la organización antes de aplicar la restricción, no después. Si aplica primero, los dispositivos pierden el túnel y las herramientas con las que los diagnosticaría al mismo tiempo.
Verifique tres cosas de forma explícita: que la VPN de conexión permanente la crea el propietario y no el usuario, que arranca en esos dispositivos después de la aplicación y que sobrevive a un reinicio. Un túnel que solo sube a mano no es un camino aprobado; es una cola de tickets de soporte.
Mantenga una vía de recuperación que no dependa de que el túnel esté activo. Una consola de gestión, un camino de administrador local o un canal fuera de banda sirven. Lo que no sirve es suponer que puede arreglar una política rota a través de la conexión que la política acaba de desactivar.
Comprobación 5: verifique y luego describa el límite con honestidad
Pruebe con un dispositivo real y una cuenta real. Confirme que un usuario no puede añadir ni iniciar una VPN, confirme que el túnel aprobado conecta y transporta tráfico, y confirme que el perfil personal sigue comportándose como se documenta. Esos tres resultados son los criterios de aceptación.
Después tenga cuidado con lo que afirma. La restricción gobierna la capacidad de VPN de Android. No convierte toda conexión permitida en un protocolo inspeccionado ni impide que una aplicación enrute sus propias peticiones a través de un proxy explícito. Bloquear UDP 500, UDP 4500 y un OpenVPN puerto no es el mismo control, porque el tráfico puede viajar por muchos transportes, incluido un HTTPS de aspecto corriente.
Si el requisito es más amplio que la capacidad de VPN, combine esto con la política de distribución de aplicaciones, los controles de cuenta y las restricciones de red adecuadas al entorno. Y anote qué queda fuera del alcance, para que nadie repita una restricción parcial como completa en la próxima auditoría.