Pourquoi les résolutions de noms échouent sur un tunnel OpenVPN routé

Un hôte répond au ping par adresse et échoue à chaque recherche par nom. Le tunnel est monté et la route existe, donc la conclusion naturelle est que le VPN est mal configuré. Une conclusion plus utile est que la recherche n'a jamais été routable : un tunnel routé transporte de l'unicast IP, alors que la requête était une diffusion cherchant un segment qui n'existe pas de l'autre côté. Une fois le décalage de couches visible, les correctifs se classent d'eux-mêmes par coût.

Mythe : le tunnel est cassé parce que les noms échouent

Le symptôme convainc parce que tout ce qui est au-dessus de la couche des noms fonctionne. Les adresses sont routées, l'interface est montée et le pair répond à un ping. Ce qui a échoué est un mécanisme de découverte qui n'a jamais eu de chemin sur une liaison point à point, et c'est une affirmation différente d'un tunnel cassé. Séparer ces deux affirmations, c'est l'essentiel du diagnostic.

Le traiter comme une panne du tunnel mène à des modifications de profil qui ne peuvent pas aider. Ajouter des options, changer le chiffrement ou réinstaller le client laisse la diffusion exactement où elle était.

Nommez le mécanisme qui a échoué avant de nommer le correctif. Une recherche qui utilise la diffusion a besoin d'un segment, tandis qu'une recherche qui utilise un résolveur a besoin d'une adresse à interroger.

Ce que TUN transporte et ce qu'il ne transporte pas

Un périphérique TUN est une interface IP, et c'est ce qui le rend routable. OpenVPN remet au client une adresse et un jeu de routes, et à partir de là le client envoie des datagrammes à un pair. Rien dans ce modèle ne crée de liaison partagée où chaque hôte entend chaque trame.

Le trafic de découverte ne rentre pas du tout dans ce modèle. Les anciennes requêtes de nom de Windows, les annonces SSDP et les demandes mDNS sont envoyées à tout le monde sur un segment plutôt qu'à une seule destination. Une liaison routée n'a pas de « tout le monde » à qui envoyer. Chacun de ces mécanismes suppose un support partagé.

Le tunnel peut donc être sain tandis que la découverte échoue complètement. C'est cette phrase qu'il faut retenir quand quelqu'un signale le VPN comme tombé.

Le pontage fonctionne en supprimant la frontière

Un périphérique TAP transporte des trames, et un pont le rattache à un vrai segment LAN. Le client détient alors une adresse sur ce segment et entend son trafic de diffusion. C'est pourquoi le pontage semble guérir le problème de noms. Il rend aussi le client dépendant de ce segment pour l'adressage.

Le remède est la suppression de la frontière de routage, non une nouvelle capacité de nommage à l'intérieur du tunnel. Tout ce que le segment diffuse traverse désormais aussi la liaison.

Pour un petit laboratoire, c'est un échange équitable. Sur une équipe dispersée, c'est rarement le cas.

Pousser le DNS et le WINS est la réparation la plus étroite

Donnez au client un endroit précis à interroger. dhcp-option DNS et dhcp-option DOMAIN pointent les noms internes vers un serveur qui connaît la zone, et un client Windows qui s'appuie encore sur NetBIOS peut recevoir un serveur WINS de la même façon. Le tunnel reste routé et le segment reste où il doit être.

Deux conditions décident si cela fonctionne. Le serveur nommé doit répondre pour la zone, et la requête doit être autorisée à travers le tunnel.

Testez le résolveur depuis le client plutôt que depuis le shell du serveur lui-même. Un résolveur qui fonctionne en local ne dit rien de ce que le tunnel transporte.

Déterminez quelle couche a échoué

Faites d'abord un ping sur l'adresse, puis résolvez le nom et lisez quel serveur a répondu. Une réponse négative d'un serveur qui n'héberge pas la zone ne ressemble pas à une requête qui n'a jamais quitté la machine. Un nom qui se résout mais refuse les connexions est un troisième problème tout à fait distinct.

Le multicast est derrière le même mur. Un groupe comme 224.0.0.251 n'est pas transmis par défaut sur un tunnel routé, et une route pour le groupe ne suffit pas sans un chemin compatible multicast ou un réflecteur sur le LAN.