Serveur et client OpenVPN sur un même hôte : pourquoi les clients décrochent

Ajoutez un profil client à une machine qui exécute déjà un serveur VPN, et le service d’origine est la première victime. Le nouveau tunnel peut ne jamais s’établir, ou bien monter pendant que les clients existants du serveur cessent discrètement de recevoir des réponses. Deux collisions produisent les deux résultats : un pool de tunnels déjà utilisé, et une route par défaut installée par la moitié cliente qui couvre toute la table. Aucune des deux ne produit de message d’erreur OpenVPN, ce qui explique que la panne soit lue comme un problème de serveur.

Une machine, deux rôles, et deux réponses incompatibles sur la destination des réponses.

Le même pool, deux serveurs : lequel gagne

Chaque instance de serveur a besoin de son propre sous-réseau de tunnel. Copier une ligne comme server 10.8.0.0 255.255.255.0 dans la seconde configuration donne le même préfixe aux deux instances, et le résultat est soit un refus de démarrer, soit une compétition silencieuse où les clients d’un serveur reçoivent des adresses que l’autre croit aussi posséder. Des ports UDP différents et des noms de périphériques différents n’y changent rien, car ni l’un ni l’autre ne touche à l’espace d’adressage. Changez le second pool, et changez-le partout où les routes le mentionnent.

Énumérez ce qui est actif avant de modifier : ip -4 addr show liste les périphériques de tunnel, ss -lunp liste les écouteurs, et systemctl list-units nomme les unités. Un coup d’œil aux adresses du tunnel suffit à savoir si les pools se chevauchent.

Ce que le profil client ajoute à la table

La moitié cliente écrit des routes dès qu’elle se connecte. redirect-gateway def1 découpe la route par défaut en 0.0.0.0/1 plus 128.0.0.0/1, toutes deux routées via le nouveau périphérique, avec une route d’hôte vers le serveur distant délibérément épinglée sur l’interface physique. Cette épingle existe pour que le tunnel garde un chemin pour son propre transport. Tout le reste, y compris les réponses que le serveur local doit à ses propres clients, suit désormais la nouvelle route par défaut et sort par le lien distant.

La seconde collision n’est donc pas un tunnel cassé. C’est un tunnel qui fonctionne au mauvais endroit dans la table.

Trois façons de séparer les rôles

Le correctif le moins invasif garde la route par défaut hors du profil client : route-nopull plus des lignes route explicites pour les préfixes distants, afin que la table locale ne change que là où vous l’avez demandé. L’étape suivante est une règle de politique qui exempte le sous-réseau de tunnel local, laissant les réponses aux clients locaux sortir par l’interface par laquelle elles sont arrivées, même en présence d’une route par défaut. La plus complète est un espace de noms réseau séparé pour le rôle client, qui supprime entièrement la table partagée et coûte un second contexte de routage à maintenir.

Quel que soit le chemin choisi, l’exception doit nommer le sous-réseau de tunnel local et non le LAN. La réponse envoyée par le serveur local a pour destination une adresse de tunnel, donc une exception en forme de LAN ne la concerne jamais.

Laquelle des deux instances est en cause

Arrêtez l’instance cliente et retestez les clients d’origine. Un rétablissement immédiat signifie routage, pas serveur. Remettez le client en route et suivez une seule réponse avec ip route get auquel on fournit à la fois une adresse source et une adresse de destination, ce qui montre le chemin que le noyau choisirait, puis observez l’interface réellement utilisée par les paquets avec tcpdump -ni any port 1194. Le fichier d’état du serveur, écrit toutes les quelques secondes via la directive status, contient la liste des clients connectés et les compteurs d’octets dans les deux sens.

Lisez ces compteurs l’un par rapport à l’autre. Un trafic qui sort et ne revient jamais est une réponse de routage, pas un problème de poignée de main.