Dos VPN de iPhone a la vez: ¿cuál transporta tu tráfico?

Dos aplicaciones VPN muestran ambas Conectado, y se supone que el tráfico ahora pasa por las dos, una dentro de la otra. Normalmente no es así. iOS tiene un modelo de coexistencia concreto, y no es una cadena. Una clase de configuración se limita a una sola instancia activada, la otra puede ejecutarse junto a ella, y la precedencia de rutas decide los conflictos. Dos interruptores encendidos no son dos saltos. El modelo está documentado, lo que significa que la ruta puede predecirse en lugar de adivinarse por los iconos.

Mito: dos VPN conectadas son una cadena

Una cadena de dos saltos necesita un transporte exterior definido, un túnel interior definido, un enrutamiento de extremos compatible y un plan para lo que ocurre cuando falla cualquiera de los dos. Dos configuraciones independientes no crean eso por existir al mismo tiempo. La prioridad de ruta no es lo mismo que la encapsulación, y que una configuración gane una búsqueda de ruta no dice nada sobre si la otra transporta los paquetes resultantes.

Si necesitas anidamiento, diséñalo como anidamiento. No lo deduzcas de dos indicadores de conexión. Esa distinción ahorra mucha depuración.

El modelo documentado detrás de ese mito

NETunnelProviderManager de Apple describe configuraciones VPN empresariales normales y afirma que solo una de ese tipo puede estar activada a la vez. La misma referencia permite que una Personal VPN siga activada y conectada junto a ella, y da precedencia a las rutas empresariales donde ambas se solapan.

Aquí Personal VPN es el término de la API para la implementación integrada de IPsec o IKEv2 gestionada mediante NEVPNManager. NETunnelProviderManager es el modelo de proveedor de túnel. Una aplicación de consumo puede usar el modelo de proveedor, así que un nombre de producto que contenga personal no lo clasifica.

Apple documenta una combinación permitida, y el permiso no te dice que los perfiles de dos proveedores sean compatibles, así que pregunta a cada proveedor qué par está soportado. Sus tipos de configuración, rutas y políticas siguen decidiendo el resultado.

Mito: la VPN personal recibe el tráfico de navegación

Un perfil de trabajo que reclama todos los destinos ganará también la búsqueda de ruta para la navegación pública, así que la salida personal no transporta nada de ella. Según la precedencia documentada, las rutas empresariales ganan donde entran en conflicto, así que la navegación pública no toma automáticamente la salida personal solo porque esa aplicación también informe de conexión. Una configuración de trabajo más estrecha puede cambiar el panorama de enrutamiento, pero el cliente de la organización aún puede imponer requisitos de DNS, bloqueo o dispositivo. Obtén el arreglo soportado de su propietario en lugar de editar esos requisitos localmente.

Las configuraciones gestionadas por aplicación tienen su propio alcance. No extrapoles una regla de nivel de dispositivo a cada despliegue gestionado.

Anota los dos flujos antes de probar: el nombre y el rango privados del servicio de trabajo, y una solicitud nueva de navegación pública. Ambos son legítimos, y necesitan comprobaciones distintas.

Precedencia de rutas con un perfil de trabajo de túnel dividido

Un perfil de trabajo con túnel dividido reclama los prefijos privados y el sufijo DNS interno que enumera, y esas rutas ganan cualquier búsqueda que coincida con ellos. Los destinos públicos que no coinciden con ninguna ruta empresarial caen al enlace físico salvo que la VPN personal los reclame primero. La regla de precedencia decide solo las coincidencias solapadas, por eso los dos perfiles deben leerse como tablas de rutas y no como iconos.

Escribe el par en dos líneas y nombra al ganador esperado de cada una: un nombre de host de trabajo que resuelva a 10.x o 172.16.x debería salir por el túnel empresarial, y una dirección pública sin prefijo coincidente debería tomar la ruta predeterminada que quede. Si ambas líneas nombran la misma salida, la división no hace lo que describe la documentación.

Anota dos flujos y prueba cada uno

Para cada flujo, anota qué configuración aprobada debe transportarlo y qué resolutor debe recibir cada tipo de nombre. Luego verifica con solicitudes nuevas, no con una página de trabajo en caché ni con un resultado de IP antiguo.

Detén una configuración y repite ambos flujos. El comportamiento ante fallos es parte del diseño, y es la parte que los usuarios notan. Cuando los dos proveedores no pueden soportar la combinación, quédate con una configuración aprobada y documenta qué flujo transporta, o pasa a un diseño gestionado de un solo túnel. La documentación de NETunnelProviderManager es la fuente de la regla de coexistencia.