Android: Always-On y bloqueo sin VPN, elija la pareja correcta

Always-On reconecta el túnel y el bloqueo sin VPN rechaza cualquier salida alternativa; activar el primero no activa el segundo. La pareja depende de quién es dueño del dispositivo, qué apps cubre el túnel y qué pasa antes de desbloquear.

Dos interruptores con promesas distintas

Always-On promete persistencia y reinicia el servicio si cae; el bloqueo promete confinamiento: sin túnel, el tráfico cubierto no tiene salida.

El tercer factor es el alcance por app, que pertenece al cliente o a la política de gestión, no a los interruptores del sistema; bloquear sin decidir el alcance da una política más amplia o más estrecha de lo necesario.

Decisión uno: ¿dispositivo gestionado o ajuste del usuario?

En un dispositivo gestionado la política controla Always-On y el bloqueo, y el interruptor local puede faltar; cambie el requisito en la política, no en el equipo.

En un dispositivo personal el usuario decide si acepta quedarse sin red cuando el túnel no está; el bloqueo es un intercambio de disponibilidad y un interruptor ausente no justifica hacer root.

El alcance es por perfil, no por dispositivo: Android permite un VPN activo por perfil de usuario.

Un bloqueo en el perfil de trabajo no dice nada del lado personal y probar un contexto no valida el otro.

Decisión dos: ¿todo bloqueado o algunas apps excluidas?

Las exclusiones por app en modo bloqueo se entienden al revés: según Android las apps excluidas pueden perder la conexión en lugar de usar en silencio la red normal, así que excluir no es permiso para internet.

Elija a conciencia: bloquee todo el tráfico cubierto y acepte que las apps excluidas queden a oscuras, o desactive el bloqueo y acepte el respaldo; si una app debe tener siempre conexión, el bloqueo es la herramienta equivocada.

Decisión tres: ¿qué pasa antes de desbloquear y en un portal?

En la mayoría de clientes el túnel no sube hasta que el usuario desbloquea, así que los primeros momentos tras el arranque son un hueco, no un fallo; confírmelo para el cliente que despliegue.

Los portales cautivos son el otro extremo: una red de hotel o aeropuerto necesita una sesión de navegador sin autenticar y un bloqueo duro puede impedir el acceso; la respuesta admitida es un flujo de recuperación aprobado con el disparador, la duración máxima, quién lo concede y la comprobación de que el control vuelve solo.

La documentación de los clientes VPN de Android cubre Always-On, el bloqueo, las exclusiones por app y la regla de un VPN por perfil; léala antes de diseñar de memoria.

Pruebe el estado sin red y luego escriba la línea de aceptación

Use tráfico inocuo y la prueba de fallo admitida: conexión normal, pérdida del túnel, recuperación y reinicio antes de desbloquear, anotando si la app quedó bloqueada como debía.

Verifique el recurso y el resolutor, no el icono, y pruebe aparte un dispositivo en tethering, porque la política del teléfono no establece reenvío para los clientes del punto de acceso.

La línea de aceptación es concreta y comprobable: la app prevista en el perfil previsto llega al túnel aprobado y sigue bloqueada cuando no puede. Antes de firmarla:

• Always-On y el bloqueo están configurados donde la plataforma los admite y se sabe quién manda en cada ajuste.
• El alcance de las apps es deliberado y ha confirmado qué pasa con las apps excluidas en modo bloqueo.
• El hueco antes de desbloquear y el flujo del portal cautivo están decididos, no descubiertos.
• La prueba de fallo se hizo en la clase de dispositivo que despliega de verdad.