OpenVPN : l’adresse locale face à l’adresse du tunnel : deux sockets différents

Le client refuse de démarrer et se plaint de ne pas pouvoir lier une adresse locale, et le correctif évident semble consister à le pointer vers l’adresse du tunnel qu’il s’attend à recevoir. Cela ne peut pas fonctionner, et la raison mérite d’être comprise : avant que le tunnel existe, il n’y a pas d’adresse intérieure, et le socket qui contacte le serveur doit exister d’abord. Deux adresses différentes sont en jeu, et une seule peut être choisie localement.

L’erreur de bind nomme une adresse locale

Quand OpenVPN signale qu’il ne peut pas lier une adresse locale, il parle du socket de transport : le point de terminaison UDP ou TCP qui porte la connexion chiffrée vers le pair.

Une directive local explicite demande au démon de lier ce socket à une adresse locale précise. L’adresse doit exister dans l’espace de noms réseau où le processus s’exécute, et elle doit être attribuable au moment où le client démarre.

Une adresse publique traduite sur un routeur ou en bordure de cloud n’est pas une adresse locale que le démon peut lier, même si c’est l’adresse que voit le serveur. Cette distinction explique pourquoi un profil fonctionne à la maison et échoue sur une instance cloud. Elle explique aussi pourquoi ajouter l’adresse publique à une interface loopback n’aide pas, puisque le transport partirait alors d’une adresse à laquelle le réseau ne peut pas répondre. Lisez la liste des interfaces avant de modifier le profil.

Ce que local et remote sélectionnent réellement

remote nomme le pair à contacter. local lie l’extrémité proche du même socket. nobind laisse le système d’exploitation choisir à la fois l’adresse locale et le port, ce qui explique pourquoi les clients derrière un routeur domestique fonctionnent généralement sans l’une ou l’autre directive.

Aucune de ces directives n’a de rapport avec l’adresse à l’intérieur du tunnel.

Dans un conteneur ou un espace de noms réseau, la même règle s’applique avec des frontières plus étroites : les adresses de l’hôte n’y sont pas présentes, si bien qu’une ligne local copiée depuis la configuration de l’hôte échoue pour une raison totalement différente de celle d’une adresse erronée.

ip -brief address show
ip route get 203.0.113.10

L’adresse intérieure vient du serveur

L’adresse à l’intérieur du tunnel est négociée ou attribuée après l’établissement du canal de contrôle. Avec un pool dynamique, le serveur la décide à la connexion, et avec une configuration propre au client, elle peut être fixée par identité.

Écrire local avec une adresse intérieure ne demande pas au serveur d’attribuer cette adresse. Au mieux le bind échoue ; au pire le client trouve une adresse d’hôte sans rapport avec la même valeur et commence à l’utiliser pour le transport.

Les interfaces à lire diffèrent elles aussi. Les paramètres ifconfig et la configuration du pool décrivent l’intérieur, tandis que remote, local, proto et nobind décrivent l’extérieur. Garder les deux listes séparées explique presque tous les exemples déroutants que vous trouverez sur un forum. Le manuel OpenVPN 2.6 les documente dans des sections distinctes pour cette raison même.

Le piège : un tunnel complet qui capture son propre transport

Une fois le tunnel monté et portant la route par défaut, les paquets qui le maintiennent ne doivent pas y être routés. C’est un problème de routage et non d’adressage, et le démon le traite en installant une route plus spécifique vers l’adresse du serveur via la passerelle d’origine.

Si vous épinglez le transport sur une adresse locale précise et que vous changez ensuite le chemin qu’utilise cette adresse, la connexion extérieure peut se perdre alors que l’intérieur reste configuré. Le tunnel continue de signaler qu’il est connecté parce que l’intérieur va bien. Seul le transport est cassé, et c’est pourquoi les journaux se lisent comme des contradictions.

Les symptômes ressemblent alors à un tunnel qui se connecte et se fige, ou à un tunnel qui se reconnecte en boucle sans erreur utile. Vérifiez la route vers l’adresse du pair avant de vérifier quoi que ce soit à l’intérieur du tunnel, et confirmez que l’adresse locale liée appartient toujours à l’interface attendue.

Une habitude qui évite la confusion

Lisez chaque adresse d’un profil et décidez à quelle couche elle appartient avant de la modifier.

Si elle nomme l’extrémité distante du transport ou lie son extrémité proche, c’est une adresse extérieure et elle doit exister avant le démarrage. Si elle décrit ce qui se passe à l’intérieur du tunnel, elle vient du serveur ou de la topologie, et aucune directive locale ne peut la remplacer.

Écrivez les deux listes dans les notes de déploiement à côté du profil. La prochaine session de dépannage commencera alors par la couche plutôt que par une supposition.