OpenVPN sur le port 53 : trois conversations que l’on confond
La résolution du point de terminaison, le transport chiffré et le DNS après le tunnel sont trois conversations. Identifiez l’étape qui a échoué avant de changer un port ou un résolveur.
Les rapports qui affirment que le VPN est bloqué sur le port 53 mélangent trois observations qui échouent pour des raisons différentes. La résolution du nom du point de terminaison a lieu avant l’existence de tout tunnel, le transport chiffré est une conversation distincte, et les requêtes DNS effectuées ensuite en sont une troisième. Chacune a sa propre signature de panne, et une seule d’entre elles concerne réellement le DNS.
Triez les paquets par objectif avant de changer quoi que ce soit, car le correctif suit l’étape.
Trois conversations, un numéro de port
La première conversation est une résolution de nom pour le point de terminaison : votre machine demande à son résolveur configuré où se trouve vpn.example.com, et cette réponse arrive par DNS ordinaire avant que le client n’envoie le moindre paquet de tunnel. La deuxième est le transport OpenVPN lui-même, qui se connecte à l’adresse produite par la résolution, sur le protocole et le port que nomme le profil. La troisième se produit une fois le tunnel établi, lorsque les applications demandent des noms et que les paramètres de résolveur poussés décident qui répond.
Ces trois peuvent réussir ou échouer indépendamment. Un client peut parfaitement résoudre son point de terminaison et pourtant ne pas atteindre l’écouteur, et il peut établir un tunnel alors que chaque résolution de nom interne échoue parce que les paramètres DNS ne sont jamais arrivés.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Lisez le tableau comme une liste de vérification, non comme une description. Si le nom du point de terminaison ne se résout pas, rien de ce qui suit ne peut fonctionner, et le tunnel ne démarre jamais.
Le numéro de port ne nomme pas l’application
Le port 53 transporte du DNS par convention, et un opérateur OpenVPN peut aussi y publier un écouteur, ce qui explique précisément pourquoi ce numéro est un mauvais identifiant. Une session OpenVPN sur UDP 53 reste une session OpenVPN, et une requête DNS vers un serveur sur le port 53 ne dit rien sur le fait qu’un tunnel soit autorisé. Les lignes proto et remote du profil définissent le point de terminaison externe ; le numéro de port ne définit rien en lui-même.
Cela coupe dans les deux sens en diagnostic : une sonde UDP générique vers le port 53 prouve qu’un port répond, pas que le service VPN répond. Testez avec le vrai client et le vrai profil, car seule cette combinaison exerce la poignée de main que le service attend.
Prouvez l’écouteur avant d’accuser le réseau
Sur le serveur, vérifiez ce qui est lié avec ss -lunp | grep 53 et comparez-le au protocole et au port du profil. Depuis le réseau du client, lancez le client avec une verbosité plus élevée pour que le journal montre quelle adresse et quel transport il a tentés. Si le serveur écoute et que les paquets du client n’arrivent pas, le chemin ou la politique les refuse, et c’est une conversation pour le propriétaire du réseau, non une raison de changer de port.
Un autre port n’aide que si le service écoute réellement là et si le déploiement le permet. Déplacer un écouteur pour contourner le filtrage d’un réseau géré est une décision de politique, pas une étape de dépannage. Demandez au propriétaire du réseau ce qui est autorisé avant de modifier le service, car un contournement qui viole la politique finira quand même par être fermé. Notez cette réponse à côté du profil pour que la personne suivante ne répète pas la demande.
Vérifiez le DNS après le tunnel, séparément
Une fois le tunnel établi, inspectez l’état du résolveur sur l’interface VPN et interrogez un nom interne et un nom public. Si les noms internes échouent alors que le tunnel transporte du trafic, les paramètres DNS poussés n’ont pas été appliqués, ce qui est une question d’intégration du client et non de transport. Si les noms publics échouent et que les internes fonctionnent, la politique de tunnel divisé fait ce pour quoi elle a été configurée.
Laissez les changements DNS au propriétaire du résolveur. Écraser une configuration de résolveur gérée pour faire passer un test peut casser les noms privés pour tout le reste de la machine. Si le tunnel pousse un résolveur et que le client l’ignore, corrigez l’intégration du client plutôt que d’ajouter une entrée statique ailleurs. Les entrées statiques masquent la panne jusqu’à ce que quelqu’un change de réseau. Notez quel résolveur est censé répondre à chaque espace de noms.