Résumé

  • Lorsque l’adresse d’accès externe change mais que la passerelle VPN et le VPN-TIA restent identiques, MOBIKE actualise le chemin extérieur ; l’i-HA ne voit volontairement aucun déplacement.
  • Prouver la continuité exige de relier le changement d’accès, l’échange MOBIKE, le TIA, l’éventuelle inscription Mobile IPv4, le reverse tunnel et l’observation applicative. Aucun accusé isolé ne certifie l’ensemble.

Deux témoins, deux géographies

Le terminal quitte un réseau public, acquiert une nouvelle adresse et met à jour sa passerelle par MOBIKE. Pour IKEv2 et IPsec, le pair a changé de chemin : la Security Association continue sur une nouvelle adresse extérieure.

Dans le tunnel, le VPN-TIA ne bouge pas. C’est toujours cette adresse interne que l’i-HA connaît comme care-of address. Son binding cache reste identique. Dire que l’un des journaux « manque » le déplacement serait faux : le déplacement n’existe pas dans sa couche.

L’incident apparaît quand le tableau de bord supprime les coordonnées et affiche seulement « mobilité réussie ». Réussie pour quel pair, quelle adresse et quel trafic ?

Adresse d’accès, TIA et adresse de rattachement

RFC 5266 stabilise l’adresse de rattachement Mobile IPv4 à travers les réseaux internes et externes. À l’extérieur, la passerelle attribue un VPN-TIA, normalement routable dans le réseau de confiance. Le terminal enregistre ce TIA comme CoA auprès de l’agent interne.

L’adresse acquise sur le réseau d’accès enveloppe le tunnel IPsec. MOBIKE modifie cette coordonnée externe. Au-dessus, l’adresse de rattachement et, souvent, le TIA ne changent pas.

Une colonne « IP actuelle » ne peut donc pas représenter le système. Il faut conserver le triplet, l’autorité qui maintient chaque valeur et le moment où elle devient effective.

Deux tunnels impliquent deux commits

Le chemin place un tunnel Mobile IPv4 dans un tunnel IPsec. Le premier rejoint l’i-HA ; le second rejoint la passerelle mVPN. Le reverse tunneling par l’agent de rattachement est obligatoire dans cette configuration.

La réponse MOBIKE atteste que la passerelle a accepté la nouvelle adresse pour la relation IKE/IPsec. La réponse d’inscription atteste que l’i-HA a accepté une association entre adresse de rattachement et CoA. Ni l’une ni l’autre n’atteste que les paquets ont traversé les deux enveloppes ou qu’une transaction applicative a abouti.

L’optimisation du TIA stable évite un commit interne inutile. Elle crée aussi une limite d’observation : l’historique de l’i-HA ne peut reconstituer les réseaux externes successifs.

Le changement de TIA déplace la frontière de preuve

Tant que le terminal reste sur la même passerelle et conserve son TIA, l’i-HA peut légitimement rester silencieux. Une reconnexion qui attribue un nouveau TIA, ou un changement de passerelle, impose en revanche une nouvelle inscription Mobile IPv4.

Le contrôle utile compare donc les événements. Un MOBIKE sans changement de TIA et sans inscription interne est attendu. Un nouveau TIA sans mise à jour du binding est une rupture. Compter simplement le nombre de messages confondrait ces deux situations.

Traverser la frontière lance deux opérations parallèles

Après un changement de connectivité, le terminal peut envoyer simultanément un message MOBIKE vers la passerelle et une Registration Request non encapsulée vers l’i-HA. La réponse de la passerelle sans réponse interne soutient la conclusion « extérieur ». Une réponse i-HA protégée répondant aux conditions TNC soutient « intérieur ».

La passerelle peut rester joignable depuis le réseau interne ; sa réponse ne classe donc pas la frontière. Et tant que la classification n’est pas terminée, le trafic normal ne devrait pas partir.

En allant de l’intérieur vers l’extérieur, l’établissement du VPN n’est que le premier commit. Si l’i-HA n’a pas répondu directement, une inscription doit ensuite passer dans le tunnel. La communication avec l’adresse de rattachement ne reprend qu’après cette réponse.

Le trafic direct échappe à la promesse de continuité

Certaines implémentations autorisent du trafic Internet direct à l’extérieur du VPN. RFC 5266 ne l’interdit pas, mais précise que ce trafic ne bénéficie ni de la mobilité ni de la continuité de session de la solution. Le trafic du tunnel Mobile IP, lui, passe toujours par la passerelle VPN.

Voir des octets sortir de la nouvelle interface ne prouve donc pas le rétablissement du service d’entreprise. Il faut distinguer flux direct, tunnel IPsec et tunnel Mobile IP imbriqué.

Le NAT peut lui aussi apparaître aux deux niveaux : traversal IPsec à l’extérieur et parfois traversal Mobile IPv4 autour d’un TIA privé. Chaque mapping possède sa propre durée et son propre producteur de preuve.

Construire le reçu de mobilité en couches

Conserver l’ancienne et la nouvelle adresse d’accès, l’interface et l’heure ; l’identité de la SA IKE, la passerelle et le commit MOBIKE ; le VPN-TIA, son allocateur et son maintien ou remplacement ; l’adresse de rattachement, la CoA, la requête/réponse Mobile IPv4 et la version du binding ; le chemin direct ou encapsulé vers l’i-HA ; TNC, authentification et rejeu ; reverse tunnel, sélecteurs IPsec, NAT et compteurs aux deux frontières ; puis la reprise transport et l’accusé applicatif.

Le reçu doit pouvoir écrire deux phrases à la fois : « le chemin extérieur a changé » et « le binding intérieur est resté identique ». C’est leur corrélation, non leur fusion, qui décrit la réalité.

Sources