Cómo MOBIKE mantiene vivo un VPN IKEv2 cuando cambia la red

Un teléfono deja el Wi-Fi y se une a la red móvil, un portátil pasa de Ethernet a un punto de acceso, y el túnel IKEv2 o sobrevive o no. MOBIKE es la extensión que le permite sobrevivir, avisando al extremo remoto de que la dirección de origen ha cambiado en lugar de empezar de nuevo. Lo que no hace es mantener viva cada aplicación durante el cambio. Son dos afirmaciones, y la segunda es la que la gente suele querer decir.

Recorra la transición por etapas, porque cada etapa falla de forma distinta.

Qué cambia realmente la actualización

Mientras la asociación de seguridad sigue siendo válida, el iniciador aprende su nueva dirección y envía una actualización al respondedor, que luego usa esa dirección para la misma asociación. Los parámetros de seguridad no se renegocian desde cero. Ese es todo el beneficio: ninguna ronda nueva de autenticación, ningún intercambio de claves nuevo, ninguna solicitud al usuario. También significa que el estado superviviente sigue perteneciendo a la sesión antigua.

MOBIKE también puede trasladar el tráfico a la encapsulación UDP, y por eso un túnel que funciona a veces empieza a usar el puerto 4500 después de un cambio de red. Esa transición por sí sola no demuestra que se haya detectado NAT, aunque ambas cosas suelen aparecer juntas.

Si su perfil lo habilita de verdad

Ambos extremos tienen que admitir la extensión, y la implementación tiene que habilitarla. En strongSwan el comportamiento es configurable por conexión, y los cambios de interfaz o de ruta pueden desencadenar una búsqueda de ruta y una actualización cuando sea necesario. Inspeccione la configuración real de la conexión en lugar de suponer que todos los perfiles IKEv2 la activan. Un perfil copiado de una guía anterior a esta función es una fuente habitual de esto.

El estado negociado en ambos extremos es la autoridad, no la documentación de la familia de productos.

Recorra la transición por etapas

Registre el estado de la aplicación antes de cambiar de red. Después cambie, y registre el estado del cliente y del servidor luego. Una dirección que falta, un par inalcanzable y una aplicación que tiene que reconectar su propia sesión son tres resultados distintos. Solo los dos primeros pertenecen a la capa VPN; el tercero pertenece al protocolo que habla la aplicación.

Compare un cambio de red con una prueba estacionaria, para saber qué evento desencadena el problema. Una medición de rendimiento en la red final no puede reproducir una transición. Mide el destino, no el trayecto.

Separe las capas de fallo

Una sesión TCP de larga duración puede fallar por motivos ajenos al intercambio IKEv2. La nueva red puede filtrar, resolver o enrutar de forma diferente. La dirección del túnel puede no cambiar en absoluto mientras la ruta bajo ella sí cambia. Por eso una reconexión de la aplicación puede arreglar algo que el VPN nunca rompió.

Mantenga la política de bloqueo en su sitio mientras se recupera, también.

La movilidad automática y una regla que impide el tráfico directo son controles distintos, y desactivar la segunda para que funcione la primera es un mal intercambio. Si la actualización de movilidad falla, el bloqueo debería mantenerse en lugar de dejar escapar tráfico alrededor del túnel.

Qué registrar cuando se repite

Conserve las marcas de tiempo y ambos valores de dirección de ambos lados. Ese registro muestra si la actualización se completó antes de que la aplicación perdiera el contacto, que es la diferencia entre un fallo de movilidad y un tiempo de espera de la aplicación. Luego compare la dirección del cambio: salir del Wi-Fi hacia la red móvil no es simétrico con lo contrario. Una dirección puede funcionar mientras la otra falla.

Esa asimetría es lo bastante común como para ser lo primero que hay que probar.

Con el registro en la mano, el incidente deja de ser otro icono desconectado y se convierte en un evento de una secuencia con un responsable conocido. Que es todo lo que un recorrido puede prometer honestamente.