Votre client OpenVPN doit-il utiliser nobind ou un port fixe ?

Deux profils qui ne diffèrent que d'une ligne se comportent différemment dès qu'un second client démarre sur le même hôte. L'un porte nobind et prend n'importe quel port local que le noyau lui attribue ; l'autre réserve 1194, et la seconde instance meurt avec une adresse déjà utilisée. Cette ligne décide qui choisit le port source, ce qui décide à son tour si le profil peut coexister avec quoi que ce soit d'autre sur la machine. Trois questions tranchent la question, et la première répond à la plupart des profils avant que vous n'arriviez aux deux autres.

Ce que nobind évite réellement

Par défaut, le client lie une socket locale avant de se connecter, et le port local vaut 1194 sauf si le profil dit le contraire. nobind supprime cette réservation, si bien que la pile alloue un port inutilisé au moment de la connexion. C'est une exception, pas un défaut, et un client sans la ligne retient 1194, ce qui explique précisément pourquoi une seconde instance non épinglée entre en collision. La plupart des profils clients livrés portent la directive pour cette raison, et le fait qu'un fichier d'exemple fasse quelque chose n'équivaut pas à ce que le mécanisme le fasse par défaut.

Ce qui ne change pas, c'est le côté distant. Le serveur écoute toujours là où le profil dit qu'il écoute, et le port de destination dans la configuration reste le port de destination. Un port source dynamique change l'adresse de retour de votre propre socket et rien de celui du serveur.

Il ne cache rien non plus. Votre adresse publique est ce que le chemin en fait, le paquet traverse toujours le réseau local, et quiconque exploite ce réseau voit toujours un flux. nobind n'est ni une fonction de confidentialité ni un contournement de pare-feu.

Trois conditions qui tranchent

Une question décide des deux autres, alors répondez-y avant de modifier quoi que ce soit. Si le pair se connecte vers l'extérieur, les questions restantes ne font qu'affiner une décision déjà prise. S'il accepte des connexions entrantes, aucun réglage du port local ne le rend joignable.

Ce pair initie-t-il la connexion ? S'il se connecte vers l'extérieur, un port source dynamique est inoffensif et généralement préférable, car la réponse revient par le même flux. S'il attend des connexions entrantes, un port dynamique le rend injoignable à moins que quelque chose devant ne publie le port. Cette seule réponse sépare chaque profil client de chaque profil serveur.

Le chemin filtre-t-il sur le port source ? Une règle stricte écrite pour un port connu impose un port local explicite, et le profil devrait consigner la règle à laquelle il satisfait. La plupart des réseaux ne filtrent que sur la destination, cette condition est donc plus rare que la première. Là où elle s'applique, elle l'emporte sur la préférence pour un port dynamique.

Plusieurs instances partagent-elles l'hôte ? Un seul port fixe ne peut pas en servir deux, et une instance redémarrée peut trouver 1194 encore en état de fermeture. Les ports dynamiques suppriment ce conflit sans rien changer d'autre. Si vous ne pouvez pas répondre à celle-ci avec assurance, supposez que oui et laissez le noyau choisir.

Où un port épinglé est la bonne réponse

Certains réseaux filtrent sur le port source aussi bien que sur la destination, si bien qu'un opérateur a peut-être écrit une règle qui ne laisse passer le trafic que depuis un port connu. Épingler le port local est alors correct, et le profil devrait porter un commentaire nommant la règle à laquelle il satisfait. Épingler par symétrie avec le port du serveur n'est pas une raison, car les deux nombres n'ont rien à voir entre eux. Si l'épinglage n'existe que parce qu'un modèle l'avait, supprimez-le.

Sinon, un port épinglé achète des ennuis : deux clients sur une même machine ne peuvent pas tous deux retenir 1194, et le second échoue avec une erreur qui pointe le port plutôt que le profil. Un conteneur qui redémarre vite se heurte au même mur. Le remède est la directive que les profils livrés contenaient déjà.

Serveur et client ne sont pas symétriques

manuel OpenVPN 2.6 place nobind à côté de lport, ce qui est l'argument en une ligne : une option dit que le noyau choisit, l'autre dit que c'est vous. Un port local dynamique ne fonctionne que pour le pair qui se connecte, car le côté qui répond ne peut pas connaître le port à l'avance. C'est pourquoi copier un profil client sur un serveur produit un écouteur que personne ne peut joindre.

Sur un hôte à plusieurs interfaces réseau, l'adresse est une décision distincte du port. Lier une adresse locale précise et lier un port précis sont deux réglages différents, et un serveur à deux liens montants épingle généralement les deux. Un client qui épingle les deux a repris la même rigidité sans aucun bénéfice.

Le résumé porte sur les rôles plutôt que sur la sécurité : celui qui se connecte peut être souple sur sa propre source, et celui qui répond ne le peut pas. Aucun des deux choix ne change ce que l'autre extrémité apprend sur votre identité. C'est aussi pourquoi la directive apparaît dans les exemples clients et presque jamais dans ceux des serveurs.

Vérifiez le port choisi par le noyau

Après la connexion, lisez la socket plutôt que la configuration, car la configuration énonce l'intention et la socket énonce ce qui s'est passé. Les faits qui méritent d'être notés sont le port local, le point de terminaison distant et si quelque chose écoute encore. Sur un hôte Linux, les trois sont à une commande.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

Un client avec nobind affiche un port local élevé et le port distant configuré, ce qui est la forme attendue. Un serveur affiche une socket en écoute sur son port configuré, et si cette socket manque, le profil soit n'est pas un écouteur, soit n'a pas pu se lier. Lorsqu'un flux existe mais qu'aucun paquet ne revient, comparez le port source choisi à tout filtre de ports sur le chemin avant de modifier le profil. Changez une chose, reconnectez-vous et relisez la socket.