Comment MOBIKE maintient un VPN IKEv2 en vie lorsque le réseau change
MOBIKE met à jour une connexion IKEv2 prise en charge lorsque l'appareil change de réseau. Le routage, le filtrage et la reprise de session de l'application doivent encore fonctionner.
Un téléphone quitte le Wi-Fi et rejoint le réseau cellulaire, un portable passe d'Ethernet à un point d'accès, et le tunnel IKEv2 survit ou ne survit pas. MOBIKE est l'extension qui lui permet de survivre, en informant l'extrémité distante que l'adresse source a changé au lieu de repartir de zéro. Ce qu'elle ne fait pas, c'est garder chaque application en vie pendant le changement. Ce sont deux affirmations, et la seconde est celle que les gens veulent généralement dire.
Parcourez la transition par étapes, car chaque étape échoue différemment.
Ce que la mise à jour change réellement
Tant que l'association de sécurité est encore valide, l'initiateur apprend sa nouvelle adresse et envoie une mise à jour au répondeur, qui utilise ensuite cette adresse pour la même association. Les paramètres de sécurité ne sont pas renégociés depuis zéro. C'est tout l'avantage : pas de nouvelle manche d'authentification, pas de nouvel échange de clés, pas d'invite pour l'utilisateur. Cela signifie aussi que l'état survivant appartient toujours à l'ancienne session.
MOBIKE peut aussi déplacer le trafic vers l'encapsulation UDP, ce qui explique qu'un tunnel fonctionnel se mette parfois à utiliser le port 4500 après un changement de réseau. Cette transition ne prouve pas à elle seule que NAT a été détecté, même si les deux apparaissent souvent ensemble.
Votre profil l'active vraiment
Les deux pairs doivent prendre en charge l'extension, et le déploiement doit l'activer. Dans strongSwan, le comportement est configurable par connexion, et les changements d'interface ou de route peuvent déclencher une recherche de chemin et une mise à jour si nécessaire. Inspectez les paramètres réels de la connexion au lieu de supposer que chaque profil IKEv2 l'active. Un profil copié depuis un guide antérieur à la fonctionnalité est une source courante de ce problème.
L'état négocié aux deux extrémités fait autorité, pas la documentation de la famille de produits.
Parcourez la transition par étapes
Enregistrez l'état de l'application avant de changer de réseau. Puis changez, et enregistrez ensuite l'état du client et du serveur. Une adresse manquante, un pair injoignable et une application qui doit reconnecter sa propre session sont trois résultats différents. Seuls les deux premiers relèvent de la couche VPN ; le troisième relève du protocole que parle l'application.
Comparez un changement de réseau à un test stationnaire, afin de savoir quel événement déclenche le problème. Une mesure de débit sur le réseau final ne peut pas reproduire une transition. Elle mesure la destination, pas le trajet.
Séparez les couches de défaillance
Une session TCP de longue durée peut échouer pour des raisons extérieures à l'échange IKEv2. Le nouveau réseau peut filtrer, résoudre ou router différemment. L'adresse du tunnel peut ne pas changer du tout alors que le chemin en dessous change. C'est pourquoi une reconnexion de l'application peut corriger quelque chose que le VPN n'a jamais cassé.
Gardez aussi la politique de blocage en place pendant la reprise.
La mobilité automatique et une règle empêchant le trafic direct sont deux contrôles différents, et désactiver le second pour faire fonctionner le premier est un mauvais échange. Si la mise à jour de mobilité échoue, le blocage devrait tenir plutôt que de laisser fuir le trafic autour du tunnel.
Ce qu'il faut enregistrer lorsque cela se répète
Conservez les horodatages et les deux valeurs d'adresse des deux côtés. Cet enregistrement montre si la mise à jour s'est terminée avant que l'application perde le contact, ce qui fait la différence entre un défaut de mobilité et un délai d'attente de l'application. Comparez ensuite le sens du changement : quitter le Wi-Fi pour le réseau cellulaire n'est pas symétrique avec l'inverse. Un sens peut fonctionner tandis que l'autre échoue.
Cette asymétrie est assez courante pour être la première chose à tester.
Avec l'enregistrement en main, l'incident cesse d'être une icône déconnectée de plus et devient un événement dans une séquence avec un propriétaire connu. Ce qui est tout ce qu'un parcours peut honnêtement promettre.