Le port 1194 est déjà utilisé : à qui appartient ce socket OpenVPN ?

Démarrez deux fois le même profil de serveur : le second processus se termine par une erreur d’adresse déjà utilisée pour le port 1194. Dans le cas courant, le lancement de diagnostic a créé le conflit, et l’instance d’origine continue de servir parfaitement les clients. Cette histoire explique une grande partie de ces signalements, et il vaut la peine de la reconnaître avant de redémarrer quoi que ce soit. C’est aussi la version la moins coûteuse à résoudre.

L’erreur décrit une liaison locale et rien au-delà. Elle ne prouve pas qu’un fournisseur bloque le port, qu’un client a envoyé un mauvais mot de passe ou que la chaîne de certificats est rompue.

Lisez l’erreur de liaison exacte

Deux erreurs de cette famille signifient des choses différentes, et les confondre vous envoie à la mauvaise couche. « Adresse déjà utilisée » indique qu’un autre socket détient le point de terminaison demandé. « Adresse non disponible » indique que l’adresse demandée n’existe pas encore sur cet hôte, ce qui est un problème de disponibilité et non un doublon.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

Copiez le texte de l’erreur avant de modifier quoi que ce soit, y compris l’adresse et le port qu’elle mentionne. Un service qui attend l’apparition d’une interface enregistrera la seconde erreur à répétition puis se liera correctement dès que l’adresse existe ; un service qui enregistre la première erreur n’aboutira jamais tant que le doublon n’est pas résolu. Noter laquelle des deux vous avez vue ne coûte rien et évite une recherche d’interface inutile.

Inventoriez le socket, pas le port

Un numéro de port est un inventaire incomplet. Le point de terminaison est un transport, une famille d’adresses, une adresse locale et un port, le tout dans un seul espace de noms réseau. Un écouteur UDP et un écouteur TCP sur le même numéro sont des sockets différents, et deux processus sur le même numéro dans des espaces de noms différents ne se rencontrent jamais.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

Exécutez d’abord le transport que le profil utilise réellement. Regardez ensuite la colonne de l’adresse locale plutôt que le seul numéro : une liaison générique couvre toutes les adresses locales, si bien qu’un second processus demandant une adresse précise peut entrer en collision avec elle même si les chaînes imprimées diffèrent. Les options de réutilisation de socket et les règles de la plateforme décident du résultat exact, et c’est pourquoi cela doit être une observation et non une règle que vous appliquez à chaque déploiement.

Trouvez quel processus le possède

Les points de terminaison numériques plus les informations de processus identifient le propriétaire lorsque vos privilèges le permettent, et le propriétaire est ce dont vous avez besoin, pas le nom du programme. Deux processus OpenVPN peuvent exécuter des profils différents, et celui qui détient l’écouteur peut être celui que vous soupçonnez le moins.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

Comparez ce que vous trouvez avec le gestionnaire de services, un environnement d’exécution de conteneurs ou un processus de terminal resté d’un test antérieur. L’absence de détails sur le processus ne prouve pas que le socket n’a pas de propriétaire ; elle signifie généralement que la requête a été exécutée sans autorisation suffisante. De même, une liste limitée à TCP n’écarte pas un conflit UDP, alors inspectez le transport nommé dans l’erreur. Le nom du processus seul ne dit jamais quel profil a été chargé, et c’est le profil qui décide du point de terminaison.

Un propriétaire, ou deux instances conçues

Si le déploiement prévoit un seul serveur, gardez un seul propriétaire de cycle de vie et lisez le journal de cette instance ou le journal configuré au lieu de lancer une seconde copie pour la surveiller. Lorsqu’une exécution contrôlée au premier plan est réellement nécessaire, arrêtez délibérément l’instance gérée et tenez compte des clients qu’elle sert avant de le faire.

Si deux instances sont prévues, donnez-leur des écouteurs distincts et tout le reste distinct : pools d’adresses, interfaces virtuelles, politique de routage et propriété de la configuration. Un port différent ne sépare rien d’autre que le socket, et les deux serveurs se disputeront encore le même pool et les mêmes routes.

Trois raccourcis méritent d’être nommés parce qu’ils apparaissent dans chaque fil sur cette erreur. Ne tuez pas un PID arbitraire qui ressemble au coupable. N’activez pas le partage de socket pour faire taire le message. Ne basculez pas un profil de serveur vers une configuration non liée de type client parce que cela fait disparaître l’erreur de liaison ; le serveur devient inaccessible d’une manière plus difficile à diagnostiquer que le conflit d’origine.

Changer de port n’est une réponse légitime que lorsque le nouvel écouteur fait partie d’une conception approuvée, qui inclut la règle de transfert et le point de terminaison du client. Si ceux-ci n’ont pas été mis à jour, vous avez déplacé le conflit là où personne ne peut le trouver.

Vérifiez la liaison avant tout le reste

Après la correction ciblée, confirmez que l’instance prévue est active, que son écouteur apparaît sur le transport attendu et qu’un client peut se connecter. Une liaison réussie ne termine que l’étape du socket local ; elle ne certifie rien sur l’authentification ni sur le trafic une fois le tunnel monté.

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

Si le socket est présent et que le client échoue encore, le problème restant est en aval et l’erreur de liaison appartient désormais au passé. Cette séparation est tout l’intérêt de lire d’abord le message exact : une erreur, une couche, un propriétaire. Lisez-le ainsi et le symptôme suivant partira d’un état connu plutôt que d’une supposition.