Une seule adresse de service sur chaque nœud OpenVPN : ce qu’elle ne fait pas

Un client se connecte à l’un de plusieurs serveurs OpenVPN puis a besoin d’un petit service qui tourne sur ce nœud : une page d’état, un point de métriques, un agent de sauvegarde. Donner à chaque nœud la même adresse privée de service rend la configuration du client identique quel que soit le serveur sur lequel il a atterri. Cette commodité est réelle, et il est aussi facile de la surinterpréter : l’adresse partagée vous dit quel nœud vous avez atteint, pas que quelque chose soit redondant.

Pourquoi la même adresse sur chaque nœud fonctionne

Chaque nœud possède l’adresse localement et répond pour elle, si bien qu’un client qui l’atteint par son tunnel actuel obtient le service à l’autre bout de ce tunnel. Rien n’est coordonné entre les nœuds, et aucun trafic ne passe d’un nœud à l’autre.

L’adresse est une étiquette locale, répétée plutôt que répliquée. Chaque nœud ne répond que pour lui-même, et aucun d’eux ne transfère de trafic pour l’adresse au nom d’un autre nœud. C’est ce qui garde une seule configuration client valide pendant que les serveurs restent indépendants. C’est aussi pourquoi la conception n’a besoin d’aucune coordination entre les nœuds.

C’est pourquoi la même configuration fonctionne sur chaque serveur sans protocole de routage entre eux. C’est aussi pourquoi la conception ne dit rien sur la santé : l’adresse existe sur un nœud malade exactement comme sur un nœud sain, parce qu’elle est liée à l’hôte et non au fait que le service soit utile.

Assignez-la au loopback, pas au tunnel

Placer l’adresse sur une interface loopback la découple de la durée de vie de tout périphérique de tunnel, si bien qu’une reconnexion ou un rechargement de configuration ne la supprime pas. L’adresse existe tant que l’hôte existe.

Une adresse sur lo n’est pas un filtre. Le service doit toujours écouter dessus, et le pare-feu de l’hôte évalue toujours le chemin entrant réel, qui arrive sur l’interface du tunnel. Quiconque suppose que loopback signifie local seulement finit soit par bloquer des clients légitimes, soit par exposer quelque chose qu’il ne voulait pas.

Rendez l’assignation persistante via la configuration réseau de l’hôte plutôt que de la rajouter depuis un hook. Un hook d’installation ne se déclenche pas sur un nœud où aucun tunnel n’est monté, et l’adresse de service ne devrait pas dépendre de l’activité du tunnel. Placez l’adresse dans la configuration d’interface que votre distribution gère, puis redémarrez une fois et vérifiez-la. Un redémarrage est le seul test qui survive à un changement de configuration ultérieur.

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

Poussez une route et visez une seule destination

Le client a besoin d’une route d’hôte pour l’adresse, proposée par le serveur auquel il se connecte. Comme chaque serveur propose la même destination, le profil ne change pas quand le client se déplace.

Vérifiez ce que le client a installé avant d’accuser le service.

ip route get 10.250.0.1

Pour un service HTTP, donnez à l’adresse un nom et un certificat pour ce nom. L’IP partagée n’est pas une identité, et elle ne supprime pas la vérification TLS, ni ne justifie de copier une clé privée sur chaque nœud. Un nom qui résout vers l’adresse partagée garde l’histoire du certificat ordinaire et vous laisse conserver une identité par nœud si vous en avez besoin.

Ce que l’adresse partagée ne peut pas faire

Elle n’assure pas de bascule en cas de panne. Si le nœud choisi meurt, l’adresse meurt avec lui, et le client doit se reconnecter ailleurs.

Elle ne migre pas une session TCP vivante, car une nouvelle connexion se termine sur un autre hôte qui ne sait rien de l’ancienne.

Elle ne choisit pas un nœud sain, n’équilibre pas la charge et ne synchronise pas les données entre les nœuds. Chacun de ces éléments est un mécanisme distinct avec ses propres modes de défaillance, et prétendre que l’astuce d’adressage les couvre est la façon dont une conception simple acquiert une réputation imméritée de résilience. Si deux tunnels sont actifs en même temps, le sens de la destination devient ambigu, alors gardez explicite l’hypothèse d’un seul tunnel actif.

Gardez l’identité du service avec le nom

Écrivez ce que l’adresse signifie : elle atteint le service sur le nœud auquel le client est actuellement connecté. Cette seule phrase évite la majeure partie du malentendu que ce schéma attire.

Documentez ensuite les pièces ensemble : l’adresse, l’interface sur laquelle elle vit, la route que le serveur pousse, et le nom et le certificat que le service présente. Quatre petits faits qu’un lecteur futur peut vérifier, dans l’ordre où il les vérifiera.

Si l’exigence est une destination stable pour un service local au nœud, le schéma convient et ne coûte presque rien.

Si l’exigence est la disponibilité, montez d’une couche : un répartiteur de charge, un nom de service avec des contrôles de santé, ou un système d’orchestration qui sait déjà comment remplacer un nœud.

Le décider tôt garde l’adresse partagée ce qu’elle est, une étiquette commode, au lieu d’un composant dont on attend silencieusement qu’il fasse un travail pour lequel il n’a jamais été conçu.