L'adresse du pair change en cours de session : ce que fait float dans OpenVPN

L'ordinateur portable passe du Wi-Fi du bureau au partage de connexion d'un téléphone, le tunnel tient encore quelques secondes, puis le trafic s'arrête tandis que l'interface continue d'affirmer qu'elle est connectée. Sur le serveur, la liste d'état continue d'afficher l'ancienne adresse publique. C'est la situation pour laquelle float existe, et c'est aussi celle où l'on en attend bien plus qu'il n'en fait. Bien poser la frontière transforme un blocage déroutant en un changement de configuration d'une ligne ou en une enquête complètement différente.

Ce que float assouplit et ce qu'il n'assouplit jamais

Normalement, une session continue de parler à l'adresse et au port externes avec lesquels elle a commencé, et les paquets arrivant d'ailleurs sont ignorés. L'option float supprime cette liaison stricte une fois que le pair a déjà fait ses preuves, de sorte qu'un mappage de source modifié peut poursuivre la même session au lieu d'être rejeté. Rien ne change dans les contrôles cryptographiques : les clés, les certificats et toute protection HMAC restent exactement comme configurés.

C'est une décision par paquet, pas une politique sur qui peut se connecter. Une machine inconnue qui envoie un paquet depuis une nouvelle adresse n'a rien prouvé, et son paquet est écarté comme tout autre trafic non authentifié. Seul le trafic qui passe l'authentification propre à la session peut déplacer l'adresse du pair enregistrée, et c'est pourquoi float peut rester activé sans risque dans les environnements où les clients se déplacent.

Il ne dit rien non plus du tunnel interne. Une adresse externe déplacée ne réattribue pas une adresse de tunnel, ne change pas le pool et ne donne pas au pair accès à quelque chose de nouveau. Dans le tunnel, la même identité et les mêmes routes poussées s'appliquent avant et après le déplacement. Un déplacement ne renégocie pas non plus le canal de données, donc le chiffrement et les clés négociés continuent.

Le paquet qui déplace une session doit s'authentifier

Démarrez une session de la manière habituelle vers le distant configuré, et float gère ce qui se passe lorsque le mappage change. Un opérateur mobile qui renumérote en plein flux, une passerelle NAT qui réécrit son mappage de port ou un portable qui change de liaison montante produisent tous la même forme : des paquets authentifiés venant d'un nouveau tuple, qui arrivent sur une session qui croit encore à l'ancien.

Quand on vous demande si float fonctionne, la preuve utile est une poignée de main terminée suivie d'un changement de source accepté, pas une ligne de journal sur la seule adresse. Corrélez les adresses externes ancienne et nouvelle avec la session qui est restée vivante, puis confirmez que le trafic a réellement continué dans le tunnel.

Si la session meurt au lieu de se déplacer, le paquet arrivé de la nouvelle adresse a probablement échoué à l'authentification ou n'est jamais arrivé. Les deux cas sont identiques du point de vue du client. Sur le serveur, une capture sur l'interface publique vous dit lequel des deux vous avez avant de toucher à la moindre configuration.

La découverte est un mécanisme entièrement distinct

float ne résout pas de noms sur un minuteur et ne suit pas un enregistrement DNS dynamique. Si le nom d'hôte du serveur commence à se résoudre vers une nouvelle adresse, un client inactif n'a aucune raison de le remarquer et aucun paquet du nouveau point de terminaison à authentifier. Ce problème relève de la logique de reconnexion, du comportement de nouvelle tentative du client lui-même et du DNS, pas de float.

Ajouter l'option une fois de plus ne compense pas l'absence de route vers la nouvelle adresse. Elle n'aide pas non plus quand le pair est silencieux, car un pair silencieux n'envoie jamais le paquet authentifié qui déplacerait quoi que ce soit.

Le pare-feu sous-jacent a aussi son mot à dire. Une règle qui n'autorise que l'ancien point de terminaison externe bloque l'adresse changée avant même que OpenVPN ne la voie, et aucune configuration côté client n'y remédie. Examinez le cycle de vie des adresses autorisées comme une tâche à part ; élargir la règle à n'importe quelle source échange un petit problème contre un gros.

Quand NetworkManager possède le profil

Un profil en ligne de commande et une connexion importée sont des configurations distinctes, et modifier l'un ne touche pas l'autre. Avant de supposer que l'option n'est pas prise en charge, établissez quel type de greffon le profil enregistré utilise réellement et où vivent ses valeurs. L'UUID du profil est l'identifiant qui compte lorsque vous inspectez ou modifiez quoi que ce soit.

Inspectez la connexion enregistrée plutôt que le fichier d'import d'origine. Une ligne qui survit dans un fichier .ovpn ne prouve rien si le gestionnaire actif ne l'a jamais appliquée, et un éditeur sans case à cocher pour une option donnée ne prouve rien non plus sur les capacités du protocole.

Ne corrigez pas un greffon empaqueté pour ajouter le comportement, surtout pas avec un diff écrit pour une version historique d'un composant sans rapport. Si l'intégration installée ne peut vraiment pas exprimer le réglage, la bonne démarche est un profil pris en charge ou un autre chemin client approuvé par le responsable du déploiement.

Prouvez la transition au lieu de la supposer

Exécutez le test comme la panne se produit. Connectez-vous, vérifiez le trafic dans le tunnel, forcez le changement de l'adresse externe, puis vérifiez trois choses : la session existe toujours, l'adresse du pair enregistrée a bougé et une requête réelle atteint encore sa destination. Tout ce qui est moins que les trois est une réponse partielle.

Gardez un accès de secours disponible pendant vos tests, car les expériences d'itinérance ont l'habitude de laisser en rade la machine depuis laquelle vous travaillez. Une console série ou une route hors bande transforme un test raté en récupération de cinq minutes plutôt qu'en visite sur site.

Enfin, ne décrivez que le cas que vous avez réellement exercé. Un changement d'adresse réussi pendant une session ne prouve pas que des migrations DNS, une autre implémentation client ou un profil reconstruit se comporteront de la même manière. La documentation de link-options énonce précisément la portée de l'option ; votre journal de test devrait indiquer quelle partie de cette portée vous avez réellement couverte.