iPhone Always On VPN: dos túneles pueden compartir una IP virtual

En un iPhone supervisado con un perfil Always On gestionado, el teléfono mantiene un túnel por cada interfaz IP activa, de modo que la red móvil y el Wi-Fi tienen cada una el suyo. El servidor muestra entonces dos asociaciones de seguridad IKE para un solo dispositivo, a menudo compartiendo una dirección virtual, y el primer instinto es llamarlo bucle de rekey y empezar a cambiar temporizadores. Ese instinto suele ser erróneo. Recorra los pasos siguientes en el orden en que aparecen las pruebas en el servidor y deje la configuración del teléfono quieta hasta que el servidor le diga qué caso tiene.

Empiece por las dos filas que el servidor ya tiene

Liste las asociaciones con swanctl --list-sas y lea cuatro campos en ambas entradas: la dirección remota, la identidad autenticada, la IP virtual asignada y la hora de creación. Dos direcciones externas distintas con una identidad y una IP virtual es la forma que inició esta pregunta, y merece la pena anotarla antes de cualquier cambio. Después revise las asociaciones hijas asociadas a cada una, porque los selectores de tráfico deciden si una búsqueda de destino podría distinguir alguna vez los dos túneles. Un par que aparece y desaparece en segundos es un animal distinto de un par en el que ambos viven horas.

Ordene la lista por hora de creación antes de sacar una conclusión. La adyacencia en la salida no significa nada, y un listado tabular invita justo a ese error.

Decida qué solapamiento está mirando

El rekey de IKEv2 y la reautenticación make-before-break crean un solapamiento breve a propósito, estableciendo la nueva asociación antes de borrar la antigua. Las marcas de tiempo resuelven el caso, porque una SA antigua que desaparece uno o dos segundos después de que aparezca la nueva es renovación haciendo su trabajo. Los túneles independientes por interfaz nunca se ven así, ya que cada uno persiste mientras su interfaz está activa y borrar uno no se deriva de crear el otro.

El comportamiento gestionado de Always On de Apple es por interfaz, por eso un dispositivo supervisado puede parecer legítimamente más ocupado que un perfil configurado a mano. El interruptor de conexión automática de una app de proveedor no implica lo mismo, y una regla on-demand normal tampoco. La descripción general de despliegue de Apple describe el modelo por interfaz; compare sus dos filas con ella antes de suponer un bucle. Ambas formas también beben del mismo grupo del servidor, así que el solapamiento es su única señal temprana.

Vea por qué una dirección virtual para dos túneles rompe las respuestas

Una respuesta al teléfono se dirige a la dirección interna, y el núcleo elige un túnel de salida por destino y política, no por la interfaz que usó el teléfono. Dos asociaciones concurrentes que comparten la misma IP virtual con políticas coincidentes dejan la decisión de enrutamiento sin forma de decir a qué sesión pertenece una respuesta. Algunas respuestas toman el túnel equivocado, y el teléfono muestra una conexión que funciona en un sentido o muere cuando aparece el Wi-Fi. Dos salidas de comandos demuestran el estado: swanctl --list-sas mostrando la misma IP virtual en ambas SA, y ip xfrm policy mostrando dos selectores idénticos.

Ese par de salidas es también lo que pega en el registro de cambios. Ninguna de las dos por separado es convincente, porque cualquiera puede parecer plausible sola.

Esto es direccionamiento y política del lado del servidor, no un mal comportamiento del teléfono, y ningún ajuste del cliente separa dos direcciones internas idénticas. El grupo entregó el mismo valor dos veces y el instalador de políticas lo aceptó. Lea el resultado desde el lado del servidor antes de culpar al cliente.

Cambie el grupo o el modelo de concurrencia, no el temporizador de rekey

En la configuración de swanctl, la unicidad es una política explícita en la conexión: unique = replace elimina una conexión anterior cuando se establece una nueva, y unique = keep rechaza a la recién llegada. Ambos valores actúan cuando se configura una conexión, no sobre las SA hijas que contiene.

connections {
  ios-alwayson {
    unique = replace
  }
}

Ninguno de los dos valores es neutro para un cliente por interfaz. keep restaura una pantalla de estado ordenada al rechazar el segundo túnel y rompe el diseño gestionado, mientras que replace derriba el túnel más antiguo y es el mismo compromiso en el otro sentido. Si de verdad se necesitan ambos túneles, el backend del grupo tiene que emitir concesiones distintas para una identidad, y su clave de concesión debe distinguir las peticiones. Una tabla estática de identidad a dirección devolverá alegremente la misma dirección dos veces y reproducirá el problema original con más configuración. Compruebe cómo el backend asigna las claves de concesión antes de añadir una segunda asignación estática.

Pruebe las transiciones que realmente despliega

Salga del alcance del Wi-Fi con una sesión activa, luego vuelva a entrar, y compruebe que las respuestas llegan en ambos sentidos. Hágalo dos veces, porque la segunda transición es donde suele aparecer una política obsoleta. Pruebe con un servicio que responda en la conexión que abrió, y repita la salida mientras el túnel lleva tráfico en lugar de estar parado. Un teléfono que puede enviar pero no recibir parece sano en un registro de handshake y roto en un navegador.

Una pantalla de estado reducida a una fila no es prueba de un diseño que funciona, solo prueba de que un túnel se ha ido. Ambos sentidos tienen que funcionar antes de que una transición pase. Anote lo que observó, junto con las dos salidas de la comprobación de solapamiento, para que el siguiente ingeniero pueda comparar en lugar de repetir el paseo.