Pourquoi une réponse UDP d’OpenVPN part d’une adresse incorrecte

Un client OpenVPN compose une adresse, le serveur répond depuis une autre, et le tunnel ne monte jamais. Le journal du serveur montre le paquet qui arrive et une capture montre une réponse qui part, si bien que la panne est imputée au client. Sur un hôte doté de plusieurs interfaces, ou de plusieurs adresses sur une même interface, les deux côtés ne sont simplement pas d’accord sur l’adresse utilisée. La réponse est valide au niveau IP, mais de nombreux clients écartent un datagramme dont la source n’est pas l’adresse qu’ils ont contactée.

Ce que le client voit quand la source change

Une socket UDP qui n’est pas liée à une adresse locale précise n’a pas de source fixe, le noyau en choisit donc une au moment de l’envoi. Ce choix provient d’une recherche de route vers l’adresse du client, et la source devient l’adresse de l’interface que la recherche retient. Sur une machine à une seule interface le choix est invisible ; sur un hôte doté d’une adresse de gestion, d’une adresse publique et d’une adresse secondaire sur la même carte réseau, il dépend des métriques et de la politique de routage. Le routage par politiques rend la discordance plus probable et non moins probable, car une règle peut retenir un lien montant que le client n’a jamais atteint. Une route par défaut apprise d’un fournisseur plus une règle de source pointant vers un autre suffisent à la produire.

Les clients qui filtrent les réponses, et le suivi de connexions qui attend le quadruplet exact et la source, écarteront la réponse sans message utile. Le tunnel expire alors comme si rien n’était arrivé, et c’est pourquoi cela est pris à tort pour un problème de pare-feu côté client. Une capture prise uniquement sur le serveur confirme l’erreur au lieu de l’expliquer, car la réponse part bel et bien. Comparez la source de la réponse à l’adresse composée par le client avant de changer quoi que ce soit d’autre.

Ce que fait réellement l’option multihome

La directive s’écrit multihome dans un fichier de configuration et --multihome sur la ligne de commande, et elle fait qu’un serveur UDP répond depuis l’adresse atteinte par le paquet du client. Le noyau livre l’adresse de destination d’origine comme donnée auxiliaire à la réception, et OpenVPN utilise cette valeur comme source de la réponse. Ainsi un serveur qui écoute sur une adresse générique, local 0.0.0.0 pour IPv4 ou son équivalent IPv6, se comporte comme si chaque client avait atteint un écouteur dédié. Les clients entrés par l’adresse publique reçoivent des réponses depuis l’adresse publique, et les clients sur une adresse interne les reçoivent depuis celle-ci. Rien d’autre dans le chemin du paquet ne bouge : la route, les règles de filtre et la configuration du tunnel restent exactement telles qu’elles étaient.

C’est cette dernière propriété qui rend l’option sûre à ajouter à un serveur qui fonctionne par ailleurs, et c’est aussi pourquoi elle ne peut pas réparer un filtre qui n’autorise qu’une seule adresse. Le paquet doit toujours être accepté sur le chemin qu’il emprunte, donc la correction de la source change l’origine de la réponse et rien de plus. Elle ne concerne que l’UDP : un écouteur TCP ne connaît pas ce problème sous la même forme, car la connexion est identifiée par le quadruplet et non par l’adresse source de la réponse.

Quand une adresse locale fixe est le mauvais réglage par défaut

Avant de recourir à l’option, vérifiez si le serveur lie une adresse locale précise, car un écouteur lié répond toujours depuis cette adresse. C’est correct pour un déploiement à une seule interface et faux dès que des clients utilisent légitimement plus d’une adresse. Si la liaison était délibérée, décidez si le serveur doit accepter du trafic sur des adresses supplémentaires. Retirer la liaison augmente l’exposition, donc les interfaces et les réseaux sources autorisés doivent être imposés par le service et le filtre, pas seulement par l’adresse de liaison.

La référence OpenVPN limite l’option aux serveurs UDP, signale le traitement supplémentaire dans le chemin du paquet et indique quelles plateformes la prennent en charge. Vérifiez-le sur la version installée avant de planifier en conséquence. Là où elle n’est pas prise en charge, l’alternative consiste à lier l’adresse précise ou à corriger la route de retour, et les deux sont des changements plus étroits qu’ils n’en ont l’air. L’écoute générique a aussi des conséquences au-delà des réponses : un serveur sur toutes les adresses est joignable depuis chaque réseau auquel l’hôte est rattaché, et ce n’est peut-être pas l’exposition que quelqu’un avait prévue.

Prouvez la source de la réponse depuis l’extérieur

Testez depuis l’extérieur du serveur, et relevez l’adresse et le transport exacts utilisés par le client avant de capturer quoi que ce soit. Les trois sondes ci-dessous répondent à trois questions différentes, et l’ordre compte.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

La capture montre l’adresse source de la réponse, et c’est le fait sur lequel repose tout l’article. La liste des sockets montre ce que le serveur a réellement lié, car un écouteur générique et un écouteur précis se ressemblent dans un fichier de configuration et se comportent différemment sur le réseau. La recherche de route montre la source que le noyau choisirait pour ce flux, ce qui explique la capture avant que vous ne changiez quoi que ce soit. Répétez les trois pour IPv4 et IPv6 séparément, car ce sont des écouteurs distincts et des recherches distinctes, et une entrée générique pour une famille ne dit rien de l’autre.

Routage, découverte et filtrage restent séparés

Préserver la source de la réponse n’installe pas de route sortante, ne met pas à jour le DNS dynamique et ne fait pas accepter une famille d’adresses par l’autre. Sur un serveur doté de plusieurs liens montants, le chemin de retour de chaque source doit être convenu délibérément, sinon les réponses sortent par une interface que le filtre du client n’a jamais autorisée. De même, une nouvelle adresse après un changement de préfixe doit atteindre les clients par la découverte et le flux de reconnexion pris en charge, et non par l’ancien enregistrement.

Laissez les contrôles d’identité du serveur et la vérification des certificats exactement tels qu’ils sont, car une adresse changée ne justifie pas d’accepter un pair non vérifié. Si la réponse part désormais de la source prévue et que le tunnel échoue encore, considérez le problème de source comme résolu et passez à la suite. La prochaine erreur observée relève du routage, du filtrage ou de l’authentification, et changer de nouveau l’écouteur ne l’atteindra pas. Inscrivez la source de la réponse dans le ticket à côté de l’adresse composée par le client, afin que la personne suivante puisse vérifier le même fait avec une seule commande.