DNS OpenVPN sur la passerelle : dnsmasq et portée du pare-feu

Lancez dnsmasq sur l'adresse du tunnel, autorisez le DNS uniquement depuis le pool de clients, poussez le résolveur, puis testez les requêtes directes et la recherche propre à l'application.

Les clients du tunnel joignent la passerelle, et la passerelle joint le résolveur interne, donc le DNS devrait fonctionner. Il ne fonctionne pas, car ce sont deux autorisations différentes et un service DNS fonctionnel est une troisième chose. L'écouteur doit exister sur une adresse que les clients joignent, le pare-feu doit autoriser les requêtes vers cette adresse, et il faut dire au client de l'utiliser. Ouvrir le tunnel dans les deux sens règle les deux premiers par accident et laisse le troisième inachevé.

L'écouteur est un service local à deux sens

En entrée, un client envoie une requête à l'adresse du tunnel de la passerelle sur le port 53. En sortie, le démon transmet cette requête à son amont configuré. Les deux moitiés doivent fonctionner, et elles échouent de façons différentes.

Un délai signalé par le client et un délai observé sur la passerelle ne sont pas la même panne.

Liez l'adresse du tunnel, pas toutes les adresses

Une instance dnsmasq dédiée à cette tâche a besoin d'une adresse d'écoute explicite, d'un mode de liaison qui tolère l'apparition du tunnel après le démarrage, et d'un amont clair. C'est la plus petite version que j'utilise :

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic lie les adresses individuelles et gère le cas où tun0 apparaît plus tard, ce qui compte sur un hôte où le service VPN redémarre. Lister loopback garde les outils locaux fonctionnels sans ajouter d'écouteur public. no-resolv empêche le démon d'hériter des amonts de la configuration du résolveur de l'hôte, et no-hosts empêche cette instance de publier le fichier hosts de la passerelle. Aucune de ces options ne donne à quiconque l'autorisation d'interroger le service.

Vérifiez s'il existe un écouteur déjà présent sur le port 53 avant de démarrer un second démon, et utilisez le propriétaire de configuration de la distribution plutôt qu'un fichier égaré dans le mauvais répertoire.

Autorisez l'entrée DNS, pas le transit du tunnel

Les règles de pare-feu qui rendent cela possible sont des règles d'entrée locales limitées à l'interface du tunnel, au pool de clients, à l'adresse de la passerelle et au port 53. Deux règles, une par protocole, suffisent :

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

Le DNS passe par TCP comme par UDP, donc une règle UDP seule laisse les grandes réponses échouer d'une manière qui semble intermittente. Ce ne sont pas ufw route des autorisations, et elles ne doivent pas devenir une autorisation large sur tun0. L'ordre compte autant que le contenu : une règle antérieure qui rejette toute entrée depuis tun0 gagne encore, et ajouter une autorisation sous un rejet terminal ne crée rien.

Si le DNS de la passerelle fait désormais partie de la conception, révisez cette politique antérieure volontairement et notez pourquoi.

La moitié amont est un chemin séparé

Les requêtes quittent la passerelle depuis sa propre adresse vers le résolveur amont, donc la route de la passerelle et la politique de sortie vers ce résolveur doivent autoriser l'échange. C'est une règle différente de celle qui laisse les clients joindre l'écouteur, et elle échoue avec un symptôme différent.

N'ajoutez pas de sortie de tunnel non restreinte pour faire fonctionner les réponses ; les réponses suivies n'en ont pas besoin.

Poussez l'option, puis vérifiez la remise

Le serveur peut annoncer le résolveur aux clients avec une option poussée. C'est une option, pas une instruction que le système d'exploitation doit obéir :

push "dhcp-option DNS 10.90.0.1"

Un client Linux en ligne de commande peut avoir besoin de l'intégration du résolveur de son gestionnaire de connexions, et un appareil géré peut avoir besoin d'un profil de gestion mis à jour. Confirmez le résolveur actif sur le client après connexion au lieu de supposer que la poussée a été appliquée. Quand deux mécanismes tentent de définir le DNS en même temps, vous obtenez une course qui se présente comme une résolution instable.

L'objectif est un seul propriétaire pour la configuration du résolveur du client, et la poussée n'est ce propriétaire que lorsque la plateforme du client est d'accord.

Testez ce que vous avez réellement construit

Interrogez un nom privé pleinement qualifié et un nom externe autorisé directement contre l'adresse du tunnel, en UDP et en TCP. Répétez ensuite via le chemin de recherche ordinaire de l'application.

Si les requêtes directes fonctionnent et que l'application échoue encore, la panne est dans la remise et non sur le serveur :

  • Le client n'a jamais appliqué l'option poussée.
  • Un autre résolveur a été défini plus tard et a gagné la course.
  • L'application utilise sa propre bibliothèque de résolution ou une réponse en cache.

Terminez en confirmant qu'une source hors du chemin VPN approuvé ne peut pas du tout utiliser l'écouteur. Une résolution réussie n'autorise pas l'adresse qu'elle a renvoyée, alors gardez ces deux questions séparées.

Articles similaires