Always On VPN frente a VPN On Demand en iPhone: qué desplegar

Dos iPhone pueden decir ambos VPN y comportarse de forma totalmente distinta. On Demand abre un túnel cuando coincide una regla, y el usuario todavía puede desactivarlo en Ajustes. Always On gestionado mantiene la cobertura impuesta en un dispositivo supervisado, incluso en los momentos en que el túnel no puede levantarse. Elija preguntando qué debe ser cierto cuando el usuario no hace nada, y luego pruebe las transiciones en lugar del estado estable. Los pasos siguientes van en el orden en que un despliegue falla de verdad.

Paso 1: establezca qué puede imponer el dispositivo

Always On es una función para dispositivos supervisados. Si el parque no está supervisado, la conversación termina antes de empezar, y ninguna clave de payload convierte un teléfono no supervisado en uno impuesto. Confirme la supervisión desde el lado de gestión y desde el dispositivo, y luego confirme quién firmó el perfil.

En el teléfono: Ajustes, luego General, luego VPN y gestión de dispositivos. La entrada del perfil nombra a su propietario, y un perfil personal instalado a mano se ve distinto de uno entregado por un servicio de gestión. No deduzca la imposición del nombre del perfil ni de una etiqueta comercial del proveedor; la etiqueta no es la política de la plataforma.

Anote tres hechos antes de tocar la configuración: supervisado o no, perfil gestionado o personal, y qué cliente transporta el túnel. Cada paso posterior depende de esos tres, y trasladar el comportamiento de un teléfono personal a un perfil gestionado es como se aprueba un despliegue contra una base equivocada.

Paso 2: lea las reglas on-demand, no el nombre de la función

On Demand es una lista de reglas evaluadas en orden. Cada regla nombra una acción y las condiciones que la seleccionan, y las condiciones son lo interesante: tipo de interfaz, SSID de Wi-Fi, sufijo de dominio DNS o una URL de sonda. Un conjunto de reglas que nunca coincide es una función que nunca conecta.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Lea toda la matriz y haga dos preguntas por regla: ¿puede esta condición ser cierta alguna vez en este parque?, y ¿qué ocurre cuando no coincide ninguna regla? Las redes empresariales renombran puntos de acceso, fusionan SSID y cambian sufijos DNS, y cada una de esas ediciones separa una regla de la realidad en silencio.

La condición de sufijo DNS es la que más falla sobre el terreno, porque el sufijo que un teléfono informa en una red de invitados no es el que sirve el resolutor corporativo. Verifique el nombre que el dispositivo resuelve realmente antes de confiar en la regla.

Paso 3: pruebe las transiciones, no la conexión estática

Un túnel levantado mientras lo mira demuestra muy poco. Ejecute cada transición a propósito y anote qué hace el dispositivo, usando el mismo recurso privado cada vez para que los resultados sean comparables:

• Únase a una red donde una regla debería coincidir, luego solicite el recurso privado y confirme que carga.
• Pase a la red móvil con la aplicación en segundo plano, tráigala al frente y repita la solicitud.
• Conéctese a un Wi-Fi con portal cautivo y vea si el portal es alcanzable o si la imposición lo bloquea antes de que pueda autenticarse.
• Desactive el túnel manualmente en un dispositivo supervisado y compruebe si vuelve solo y con qué rapidez.

Ejecute la misma lista en un dispositivo no supervisado si tiene uno. La diferencia entre ambos resultados es el comportamiento real del despliegue, y esa es la parte que una captura de un túnel conectado nunca muestra.

Paso 4: conozca las dos formas de fallo

La cobertura impuesta falla bloqueando. Cuando el túnel no se establece, el dispositivo pierde el acceso normal a internet junto con los recursos privados, y el usuario vive un teléfono conectado que no puede navegar. Reconexión y bloqueo son observaciones separadas, así que registre ambas en lugar de tratar la falta de internet como un solo síntoma.

On Demand falla no disparándose. La regla no coincide, no aparece ningún túnel y el recurso privado simplemente expira. Es fácil diagnosticarlo mal como un problema del servidor, porque el cliente se comporta exactamente como está configurado.

Un portal cautivo se sitúa entre los dos: necesita conectividad antes de que exista el túnel, así que una política que bloquea todo hasta que el túnel sube necesita una ruta documentada a través del portal. Decídalo en el diseño, no en el mostrador de ayuda.

Paso 5: verifique y luego ensaye la reversión

La verificación va en la ruta real con tráfico inofensivo: solicite un recurso privado que no debe ser público, confirme qué dirección presenta el dispositivo hacia fuera y repita tras un reinicio para haber visto la secuencia de arranque y no solo el estado caliente.

Luego ensaye la retirada en un dispositivo de prueba antes de necesitarla en producción. Quitar el perfil devuelve el dispositivo a su estado anterior, y saber cuánto tarda y qué ve el usuario forma parte del runbook. La guía de seguridad VPN de Apple es la referencia de lo que la plataforma documenta sobre estas políticas, y vale la pena leerla antes de escribir una configuración que afirme más que la plataforma.

Mantenga los tres hechos del primer paso junto al conjunto de reglas y a los resultados de las pruebas. Cuando la siguiente persona pregunte por qué un teléfono conecta en una red y en otra no, esas notas responden en un minuto en lugar de reconstruir.