OpenVPN sur un VPS : aucun périphérique /dev/net/tun à ouvrir

Le premier démarrage échoue avec un message sur /dev/net/tun ou un périphérique TUN/TAP qui ne peut pas être ouvert. Les certificats n’ont pas encore été lus, donc rien dans le profil n’est en cause. Le démon demande au noyau un objet que cet invité n’a pas.

Cet objet est un périphérique de caractères pris en charge par le module tun. Que vous puissiez le créer dépend de qui possède le noyau.

Ce que le démon demande au noyau

OpenVPN ouvre /dev/net/tun et demande une interface au pilote. Le pilote est le module tun, et le nœud de périphérique est le handle que l’espace utilisateur utilise pour l’atteindre. Si le module n’est pas chargé, le nœud peut manquer ou l’ouverture peut échouer. Aucune des deux conditions n’est corrigée en modifiant server.conf.

Lisez l’erreur d’abord comme une question de plateforme. Une erreur de configuration apparaît après l’ouverture du périphérique, pas avant.

VM ou invité à noyau partagé

Sur KVM, Xen ou une autre machine virtuelle complète, vous contrôlez le noyau. Vous pouvez charger des modules et créer le nœud. Sur OpenVZ, Virtuozzo ou un conteneur de style LXC, l’invité partage le noyau de l’hôte, donc root à l’intérieur ne peut pas charger un module que l’hôte n’a pas chargé.

La même panne a donc deux propriétaires très différents. Dans le premier cas, vous pouvez la corriger depuis l’intérieur de l’instance. Dans le second, vous demandez à l’hôte, ou au fournisseur, d’exposer quelque chose.

Exécutez ls -l /dev/net/tun, lsmod | grep tun et ip -brief link show avant de décider dans quel cas vous êtes.

Sur une VM, chargez le module au démarrage

Sur une machine virtuelle, modprobe tun crée généralement le nœud de périphérique. Vérifiez qu’il apparaît, puis rendez le chargement permanent via la configuration des modules de la distribution au lieu de vous fier à une commande tapée une fois. Un nœud qui disparaît après un redémarrage devient le même ticket le mois suivant.

Vérifiez aussi que le noyau que vous avez démarré dispose du module. Un noyau de fournisseur allégé peut en être dépourvu.

Si le nœud existe mais que l’ouverture échoue encore, les permissions et les numéros major/minor du périphérique sont les suspects suivants. Ce sont des correctifs locaux, pas des demandes au fournisseur.

Dans un conteneur, l’hôte possède le périphérique

Dans un conteneur, le périphérique et la capacité sont deux exigences distinctes. Le runtime doit transmettre /dev/net/tun, et le conteneur a besoin de la capacité réseau pour créer une interface. Un runtime sans root qui n’accorde ni l’une ni l’autre continuera de produire la même erreur d’ouverture, quelle que soit la rédaction du profil. Beaucoup d’hôtes OpenVZ exposent un commutateur TUN/TAP dans le panneau client, et l’activer plus un redémarrage suffit souvent.

Posez au fournisseur deux questions précises : le module tun est-il chargé sur l’hôte, et le périphérique est-il disponible dans cette instance ? Un ticket vague obtient une réponse vague.

Pourquoi reconstruire le module aide rarement

Construire un module dans l’invité aide rarement. La compilation nécessite la configuration du noyau exactement en cours d’exécution, et /proc/config.gz est facultatif et souvent absent des images minimales. Même un module fonctionnel ne peut pas être inséré dans un noyau que le conteneur ne possède pas.

Une fois le périphérique apparu, redémarrez le service et confirmez l’interface avant de tester le trafic. Voir tun0 montre que le démon a ouvert le périphérique. Cela ne dit encore rien du transfert, des règles de pare-feu ou des routes que les clients reçoivent.

Ce sont des questions distinctes avec des preuves distinctes. Un périphérique manquant est un échec de prérequis ; un tunnel qui existe mais ne transporte rien est un échec de politique.