¿La misma identidad IKEv2 en dos iPhone? Se turnan para conectarse

Dos teléfonos, un perfil y un patrón que parece sobrenatural hasta que alguien mira la puerta de enlace. Un dispositivo mantiene el túnel, el segundo se conecta y el primero lo pierde en cuestión de segundos. El primero se reconecta y el segundo se cae. Se culpa al ahorro de batería, al roaming Wi-Fi y al NAT del operador, mientras que la causa real está en un campo de texto que se copió junto con todo lo demás. IKEv2 identifica un peer por un nombre, y ambos teléfonos presentan el mismo.

La identidad es la clave bajo la que el servidor te guarda

Dentro de un intercambio IKEv2 cada parte declara quién es: el iniciador envía un identificador local, el respondedor contesta con el suyo y además comprueba la identidad que el iniciador afirmó contra la política. La puerta de enlace guarda su estado por identidad en lugar de por dispositivo, porque un dispositivo no es algo que pueda ver. Por eso dos teléfonos con un identificador llegan como un solo peer, y el segundo intercambio tiene que sobrescribir el primero. El problema solo aparece mientras ambos están en uso, y por eso una prueba con un solo teléfono nunca lo reproduce.

Nada de esto es un fallo del cliente. El cliente envió exactamente lo que el perfil le dijo que enviara.

Cómo se ve la colisión desde la puerta de enlace

Mire la lista de peers mientras ambos teléfonos están despiertos y en uso. Una colisión muestra una sola entrada cuya dirección cambia a medida que los teléfonos se alternan, y el contador de sesiones activas nunca llega a dos. El desmontaje bajo demanda se ve distinto, y distinguirlos requiere una observación en lugar de una teoría.

Anote ambos eventos con marcas de tiempo mientras ocurre. Una caída que coincide con la conexión del otro terminal apunta al identificador, y una caída que llega un intervalo de inactividad después del último paquete apunta a un temporizador.

De dónde vienen los duplicados

Exportar una configuración que funciona y editar solo la dirección del servidor produce un segundo archivo con la identidad del primero todavía dentro. Ese es el camino habitual hacia este fallo, y suele ocurrir al incorporar a un grupo pequeño con prisa.

Los nombres de los campos hacen que sea fácil pasarlo por alto. El identificador remoto nombra la puerta de enlace que el teléfono espera, y copiarlo es correcto. El identificador local nombra este terminal ante la puerta de enlace, y copiar ese valor es todo el problema.

Emita un valor por dispositivo

Use algo único para el terminal y estable durante toda su vida, como el identificador del dispositivo del inventario o un valor que su sistema de gestión genere para cada alta. Una etiqueta de departamento, un nombre de cuenta de servicio compartida o la dirección de correo del usuario colisionan en cuanto esa persona tiene un segundo dispositivo.

Genere la carga útil por dispositivo en lugar de distribuir un solo archivo. Registre qué valor pertenece a qué terminal, para que un reemplazo no restaure el perfil antiguo y devuelva el teléfono nuevo directamente a la misma colisión.

Compruebe también el lado del servidor. Una puerta de enlace que asigna la identidad a una dirección de túnel fija todavía puede colisionar cuando dos identificadores distintos reciben la misma asignación, así que confirme que el grupo tiene espacio y que las asignaciones no están fijadas por usuario.

Verifique con ambos teléfonos despiertos

Conecte el primero, llegue a un recurso privado, luego conecte el segundo y deje ambos inactivos un minuto. Ambas sesiones deberían persistir y la lista de peers debería mostrar dos identidades. Después bloquee y desbloquee cada teléfono para confirmar que el caso de inactividad sigue comportándose bien.

Si una sola sesión sigue cayendo una vez al día sin que nada más se conecte, la identidad ya no es el sospechoso. Pase a los temporizadores de inactividad y a los límites de sesión del servidor en lugar de editar el perfil otra vez.