El bloqueo de VPN de tu iPhone es una política, no el protocolo

El icono de VPN muestra conectado, el túnel cae un momento durante un cambio de red y el tráfico que debería haberse bloqueado sale por la red móvil. Nada en la interfaz anunció un hueco. La función en la que confiabas es una política del cliente y de la plataforma, y un nombre de protocolo en los ajustes no describe qué ocurre durante ese segundo.

Describe el bloqueo como un contrato sobre estados, no como una propiedad de IKEv2 ni de On Demand.

El síntoma: el icono dice conectado

Un icono refleja la visión que el cliente tiene de su propio estado, y esa visión puede quedarse atrás respecto de la realidad durante el tiempo de una reconexión. Una página en caché, una reconexión rápida o una actualización de estado ocultan el intervalo. La pregunta que merece la pena no es si el icono estaba verde, sino qué permitió el dispositivo mientras el túnel estaba ausente. El mismo retraso explica por qué una captura de pantalla de la app es una prueba tan débil: registra un estado, no una transición.

Esa pregunta solo tiene respuesta si la política la define.

Qué mantiene realmente el protocolo

IKEv2 mantiene y renueva una relación IPsec autenticada, y las funciones de movilidad ayudan a restablecerla tras un cambio de dirección. Eso es una afirmación sobre el ciclo de vida del túnel. No dice nada sobre el permiso del iPhone para enviar otro tráfico en el hueco, porque ese permiso pertenece a la plataforma y al cliente, no al intercambio de claves. Un dispositivo que se reconecta en menos de un segundo tuvo igualmente una ventana, y es en esa ventana donde vive el comportamiento interesante.

On Demand es igualmente una descripción del comportamiento de activación, no una garantía universal de bloqueo.

Qué ofrece la plataforma a un desarrollador

Network Extension de Apple expone controles de alcance del tráfico, y su guía de enrutamiento distingue el comportamiento de incluir todas las redes de las rutas incluidas ordinarias y enumera las excepciones del sistema. También existe un modelo de despliegue Always On supervisado, separado del ajuste de conexión automática de una app personal. Que una app concreta use algo de eso es una propiedad de la app, no del protocolo que habla.

El nombre de un interruptor no es prueba de qué API llama la app.

Lee la función como un contrato

Pide al proveedor que especifique cinco estados: activación inicial, pérdida inesperada del túnel, desconexión deliberada, salida de la app y reinicio del dispositivo. Pon las excepciones del sistema y cualquier acceso intencionado a la LAN junto a esa lista. Luego pregunta si la función es opcional, impuesta por la gestión o condicionada a un modo de cliente, porque una pausa elegida por el usuario y un bloqueo impuesto por una organización son productos distintos. Escribe esas cinco respuestas en el registro de despliegue, porque el siguiente revisor hará exactamente esas preguntas.

Una función que bloquea ante una pérdida inesperada pero no ante una desconexión deliberada es un diseño coherente. Simplemente no es el que describía la página de marketing.

Cómo probar los huecos

Prueba una transición cada vez con tráfico inofensivo, en la app y la familia de direcciones que te interese. Confirma qué se permitió durante el hueco, no qué mostró el icono después. Registra la versión del cliente y la política junto al resultado, porque ambos cambian y ninguno se ve desde la pantalla de ajustes del teléfono. Es la única forma de separar un hueco real de un icono lento.

Si la respuesta importa para el cumplimiento, pídela por escrito en lugar de deducirla de una etiqueta de producto.