tun précréée sous OpenVPN : comparer les deux modèles de propriété

Quelqu’un a précréé tun1, le profil indique dev tun1, et la connexion ne s’attache toujours pas. L’existence du nom sur l’hôte ne dit presque rien, car l’attachement dépend de l’espace de noms, du type de périphérique, de qui possède le lien et de ce que le démon est autorisé à faire. Réutiliser un périphérique impose aussi une décision que la configuration par défaut masque : quel composant écrit les adresses et les routes. Les modes de défaillance des deux arrangements diffèrent bien plus que les lignes de configuration, alors décidez avant de modifier un profil.

Un nom n’est pas un attachement

dev tun1 demande à OpenVPN cette interface nommée, et les versions traditionnelles en espace utilisateur tenteront de l’ouvrir. Si le nom ne suit pas le schéma habituel tun ou tap, le profil a aussi besoin d’un dev-type correspondant, car le type n’est jamais déduit d’une chaîne. Un périphérique TAP n’est pas un périphérique TUN avec une autre étiquette : attacher le mauvais échoue soit d’emblée, soit produit un lien qui transporte des trames que personne n’attend. Vérifiez le type avant tout le reste, puisque chaque vérification ultérieure suppose que les deux côtés s’accordent là-dessus. Ensuite, confirmez que le processus peut réellement ouvrir le périphérique, et pas seulement le voir.

dev tun1
dev-type tun

L’interface réseau et /dev/net/tun sont des objets différents : l’une est un lien dans un espace de noms, l’autre est le périphérique de caractères qu’un programme en espace utilisateur utilise pour s’attacher. La documentation Linux TUN/TAP décrit ce chemin d’attachement et les règles de propriété des périphériques persistants. Un shell root capable d’exécuter ip link prouve seulement que le shell a des privilèges, pas que le démon en a. La propriété du nœud de périphérique, l’ensemble de capacités du service et l’utilisateur sous lequel il s’exécute doivent tous concorder avant que l’ouverture réussisse.

Un périphérique qui existe et ne s’ouvre pas est un problème de propriété, pas de routage. Traitez-le comme tel pendant le débogage, sinon l’après-midi passe à lire des tables de routage qui n’ont jamais été le problème.

Qui configure le lien : deux modèles de propriété

Dans le premier modèle, OpenVPN configure les adresses et les routes en même temps qu’il monte la connexion. C’est le comportement par défaut et le plus facile à raisonner, car un seul composant crée l’état puis le retire. Dans le second, un gestionnaire externe possède l’interface, et ifconfig-noexec empêche OpenVPN d’exécuter ses commandes de configuration d’adresses et remet les paramètres à des scripts. Le gestionnaire doit alors appliquer lui-même la configuration locale et celle du pair, ce qui représente plus de travail que le nom de l’option ne le suggère. Choisir entre les deux revient à demander qui peut modifier le lien pendant qu’il est monté.

ifconfig-noexec ne couvre que les adresses : la table de routage reste intacte, et la configuration des routes revient à route-noexec. Traitez les deux directives comme des contrôles distincts avec des propriétaires distincts, car en régler une et supposer l’autre est une source courante de liens à moitié configurés. Choisissez exactement un propriétaire par couche, les adresses à un endroit et les routes à un endroit. Un gestionnaire réseau et un assistant VPN qui écrivent tous deux des adresses, voilà comment une déconnexion supprime un état dont l’autre côté dépend encore.

Inspectez le périphérique depuis l’espace de noms qui compte

Inspectez le périphérique depuis l’espace de noms dans lequel le processus VPN s’exécute, pas depuis celui où votre shell se trouve par hasard. Les deux commandes ci-dessous répondent à des questions différentes, et la différence apparaît quand un hôte voit une interface qu’un conteneur ne voit pas. Exécutez-les dans l’ordre indiqué, car la seconde n’a de sens qu’une fois que vous savez si le lien existe.

ip -details link show dev tun1
ip tuntap show

La première commande affiche le lien tel que le noyau le voit, y compris les drapeaux et le type d’interface, et c’est ainsi que vous confirmez qu’il s’agit du périphérique voulu. La seconde liste les entrées tun/tap persistantes, qui existent sans qu’aucun processus ne les détienne. Une interface qui attend son propriétaire attitré est une situation différente d’un tunnel actif attaché à un autre VPN, et seule la seconde explique pourquoi votre propre attachement échoue. Trouvez le processus qui détient le périphérique avant de changer quoi que ce soit, car une entrée persistante et une interface occupée ont des correctifs différents.

La prise en charge de files multiples est un agencement de pilote précis avec ses propres exigences, pas une autorisation pour des processus sans rapport de partager une interface. La session active d’un autre propriétaire est un problème de coordination, et aucune modification de profil ne le résout.

Deux sortes de persistance

La persistance du noyau et persist-tun décrivent des durées de vie faciles à confondre et coûteuses à mélanger. Un périphérique persistant existe indépendamment de tout processus, il survit donc à un arrêt et peut être réutilisé au démarrage suivant. persist-tun conserve les ressources au fil des réinitialisations douces prises en charge à l’intérieur d’un même processus OpenVPN, un horizon bien plus court. Ni l’un ni l’autre ne promet que l’arrêt du service laisse les routes et les adresses en place, et une interface qui reste visible n’est pas la preuve d’une session chiffrée qui fonctionne.

Vérifiez aussi le moteur, car une interface précréée ne dit rien de l’implémentation qui l’ouvrira. Les versions communautaires qui embarquent le chemin de données direct tenteront de l’utiliser, sauf si la conception dit le contraire. Là où la version prend en charge le commutateur, disable-dco sélectionne plutôt le chemin en espace utilisateur ; les moteurs plus anciens et les autres clients n’ont pas cette directive, donc gardez la condition de version à côté de l’option au lieu de supposer qu’elle s’applique.

Ce qui casse quand on ne teste que le démarrage

Un accord de propriété peut passer le premier test et échouer au dernier, ce qui fait du démarrage un contrôle médiocre à lui seul. Observez plutôt deux transitions : une réinitialisation douce, et un arrêt complet suivi d’un démarrage.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Le démarrage est le cas facile : l’unité monte, le lien apparaît et la sortie d’état nomme le profil chargé. L’attachement est le moment où le démon ouvre le périphérique, alors lancez la vérification du lien après que l’unité signale qu’elle est active, pas avant. Si le lien existe alors que l’état s’active encore, vous regardez un périphérique persistant auquel personne ne s’est encore attaché, pas un tunnel qui fonctionne. Faites passer du trafic réel par le lien avant de continuer, car une interface attachée sans route utilisable reste un échec.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Une réinitialisation douce devrait laisser la session utilisable et les ressources intactes, et c’est le travail que fait persist-tun. L’arrêt complet est l’endroit où un gestionnaire externe se révèle : si le lien ou ses adresses survivent à l’arrêt, quelqu’un d’autre en est propriétaire, et c’est soit l’état que vous avez documenté, soit le bogue que vous venez de trouver. Consignez les deux observations à côté du profil, pour que la prochaine modification parte de preuves plutôt que d’un schéma.