Como MOBIKE mantén vivo un VPN IKEv2 cando cambia a rede

Un teléfono deixa o Wi-Fi e únese á rede móbil, un portátil pasa de Ethernet a un punto de acceso, e o túnel IKEv2 ou sobrevive ou non. MOBIKE é a extensión que lle permite sobrevivir, avisando ao extremo remoto de que o enderezo de orixe cambiou en lugar de comezar de novo. O que non fai é manter viva cada aplicación durante o cambio. Son dúas afirmacións, e a segunda é a que a xente adoita querer dicir.

Percorra a transición por etapas, porque cada etapa falla de forma distinta.

Que cambia realmente a actualización

Mentres a asociación de seguridade aínda é válida, o iniciador aprende o seu novo enderezo e envía unha actualización ao respondedor, que despois usa ese enderezo para a mesma asociación. Os parámetros de seguridade non se renegocian desde cero. Ese é todo o beneficio: ningunha rolda nova de autenticación, ningún intercambio de claves novo, ningunha solicitude ao usuario. Tamén significa que o estado supervivente segue pertencendo á sesión antiga.

MOBIKE tamén pode trasladar o tráfico á encapsulación UDP, e por iso un túnel que funciona ás veces comeza a usar o porto 4500 despois dun cambio de rede. Esa transición por si soa non demostra que se detectase NAT, aínda que as dúas cousas adoitan aparecer xuntas.

O seu perfil actívao de verdade

Ambos os extremos teñen que admitir a extensión, e o despregamento ten que activala. En strongSwan o comportamento é configurable por conexión, e os cambios de interface ou de ruta poden desencadear unha busca de ruta e unha actualización cando sexa necesario. Inspeccione a configuración real da conexión en lugar de supoñer que todos os perfís IKEv2 a activan. Un perfil copiado dunha guía anterior a esta función é unha fonte habitual disto.

O estado negociado nos dous extremos é a autoridade, non a documentación da familia de produtos.

Percorra a transición por etapas

Rexiste o estado da aplicación antes de cambiar de rede. Despois cambie, e rexiste o estado do cliente e do servidor despois. Un enderezo que falta, un par inalcanzable e unha aplicación que ten que reconectar a súa propia sesión son tres resultados distintos. Só os dous primeiros pertencen á capa VPN; o terceiro pertence ao protocolo que fala a aplicación.

Compare un cambio de rede cunha proba estacionaria, para saber que evento desencadea o problema. Unha medición de rendemento na rede final non pode reproducir unha transición. Mide o destino, non a viaxe.

Separe as capas de fallo

Unha sesión TCP de longa duración pode fallar por motivos alleos ao intercambio IKEv2. A nova rede pode filtrar, resolver ou encamiñar de forma diferente. O enderezo do túnel pode non cambiar en absoluto mentres a ruta por baixo si cambia. Por iso unha reconexión da aplicación pode arranxar algo que o VPN nunca rompeu.

Manteña a política de bloqueo no seu sitio mentres se recupera, tamén.

A mobilidade automática e unha regra que impide o tráfico directo son controis distintos, e desactivar a segunda para que funcione a primeira é un mal intercambio. Se a actualización de mobilidade falla, o bloqueo debería manterse en lugar de deixar escapar tráfico arredor do túnel.

Que rexistrar cando se repite

Conserve as marcas de tempo e ambos os valores de enderezo dos dous lados. Ese rexistro mostra se a actualización se completou antes de que a aplicación perdese o contacto, que é a diferenza entre un fallo de mobilidade e un tempo de espera da aplicación. Logo compare a dirección do cambio: saír do Wi-Fi cara á rede móbil non é simétrico co contrario. Unha dirección pode funcionar mentres a outra falla.

Esa asimetría é o bastante común como para ser o primeiro que hai que probar.

Co rexistro na man, o incidente deixa de ser outra icona desconectada e convértese nun evento dunha secuencia cun responsable coñecido. Que é todo o que un percorrido pode prometer honestamente.