Com MOBIKE manté viu un VPN IKEv2 quan canvia la xarxa

Un telèfon deixa el Wi-Fi i s'uneix a la xarxa mòbil, un portàtil passa d'Ethernet a un punt d'accés, i el túnel IKEv2 o sobreviu o no. MOBIKE és l'extensió que li permet sobreviure, dient a l'extrem remot que l'adreça d'origen ha canviat en lloc de començar de nou. El que no fa és mantenir viva cada aplicació durant el canvi. Són dues afirmacions, i la segona és la que la gent sol voler dir.

Recorreu la transició per etapes, perquè cada etapa falla de manera diferent.

Què canvia realment l'actualització

Mentre l'associació de seguretat encara és vàlida, l'iniciador aprèn la seva nova adreça i envia una actualització al responedor, que després utilitza aquesta adreça per a la mateixa associació. Els paràmetres de seguretat no es renegocien des de zero. Aquest és tot el benefici: cap ronda nova d'autenticació, cap intercanvi de claus nou, cap sol·licitud a l'usuari. També significa que l'estat supervivent encara pertany a la sessió antiga.

MOBIKE també pot moure el trànsit a l'encapsulament UDP, i per això un túnel que funciona de vegades comença a fer servir el port 4500 després d'un canvi de xarxa. Aquesta transició per si sola no demostra que s'hagi detectat NAT, tot i que les dues coses sovint apareixen juntes.

El vostre perfil l'activa realment

Tots dos extrems han de suportar l'extensió, i el desplegament l'ha d'activar. A strongSwan el comportament és configurable per connexió, i els canvis d'interfície o de ruta poden desencadenar una cerca de camí i una actualització quan cal. Inspeccioneu la configuració real de la connexió en lloc de suposar que tots els perfils IKEv2 l'activen. Un perfil copiat d'una guia anterior a aquesta funció és una font habitual d'això.

L'estat negociat als dos extrems és l'autoritat, no la documentació de la família de productes.

Recorreu la transició per etapes

Registreu l'estat de l'aplicació abans de canviar de xarxa. Després canvieu, i registreu l'estat del client i del servidor després. Una adreça que falta, un extrem inabastable i una aplicació que ha de reconnectar la seva pròpia sessió són tres resultats diferents. Només els dos primers pertanyen a la capa VPN; el tercer pertany al protocol que parla l'aplicació.

Compareu un canvi de xarxa amb una prova estacionària, per saber quin esdeveniment provoca el problema. Una mesura de rendiment a la xarxa final no pot reproduir una transició. Mesura la destinació, no el viatge.

Separeu les capes de fallada

Una sessió TCP de llarga durada pot fallar per motius fora de l'intercanvi IKEv2. La xarxa nova pot filtrar, resoldre o encaminar de manera diferent. L'adreça del túnel pot no canviar gens mentre el camí que hi ha a sota sí que canvia. És per això que una reconnexió de l'aplicació pot arreglar una cosa que el VPN mai no va trencar.

Mantingueu la política de bloqueig al seu lloc mentre us recupereu, també.

La mobilitat automàtica i una regla que impedeix el trànsit directe són controls diferents, i desactivar la segona per fer funcionar la primera és un mal intercanvi. Si l'actualització de mobilitat falla, el bloc hauria de mantenir-se en lloc de deixar escapar trànsit al voltant del túnel.

Què cal registrar quan es repeteix

Conserveu les marques de temps i tots dos valors d'adreça dels dos costats. Aquest registre mostra si l'actualització es va completar abans que l'aplicació perdés el contacte, que és la diferència entre un error de mobilitat i un temps d'espera de l'aplicació. Després compareu la direcció del canvi: sortir del Wi-Fi cap a la xarxa mòbil no és simètric amb el contrari. Una direcció pot funcionar mentre l'altra falla.

Aquesta asimetria és prou comuna per ser la primera cosa que cal provar.

Amb el registre a la mà, l'incident deixa de ser una altra icona desconnectada i es converteix en un esdeveniment d'una seqüència amb un propietari conegut. Que és tot el que un recorregut pot prometre honestament.