WireGuard ne pousse pas de DNS : servir une zone BIND privée

Vous avez monté WireGuard, le tunnel fait passer du trafic, et le nom interne ne se résout toujours pas. L'étape suivante consiste généralement à chercher un réglage DNS dans la configuration WireGuard, comme si un pair pouvait pousser un résolveur à la manière d'autres VPN. Il ne peut pas. La poignée de main transporte des clés, des adresses d'interface et des IP autorisées, et elle n'a aucun champ pour des serveurs DNS ou des domaines de recherche. La politique de résolution vit sur le client, et c'est là que se situe la correction.

Le tunnel et le résolveur sont deux contrats distincts

WireGuard est délibérément petit. Il déplace des paquets pour les adresses que vous listez et authentifie les pairs ; tout ce qui se trouve au-dessus de cette couche relève de votre conception. OpenVPN peut pousser un dhcp-option DNS parce que son canal de contrôle transporte de la configuration, et cette différence fait trébucher ceux qui passent de l'un à l'autre.

Un tunnel qui fonctionne ne dit donc rien de la résolution de noms. Le client peut avoir une route parfaite vers 10.90.0.1 et envoyer quand même ses requêtes à un résolveur public, d'où le symptôme “le VPN a cassé le DNS” alors que le DNS n'a jamais été pointé vers le VPN.

Servez la zone sans devenir un résolveur récursif

Le côté serveur est une petite zone autoritative, pas un résolveur général. Dans cet exemple, la passerelle est 10.90.0.1, les clients sont 10.90.0.0/24, et l'application qui vous intéresse répond sur 10.60.0.20.

Fusionnez ces réglages dans le bloc options existant plutôt que d'en créer un second :

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

Déclarez ensuite la zone et son fichier :

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};

$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

Validez avant de recharger, car une erreur de syntaxe au rechargement fait tomber tout le serveur pour chaque zone qu'il sert :

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

N'ouvrez UDP et TCP 53 que sur l'interface VPN. Publier une autorité privée sur l'interface publique invite à la fois les requêtes et l'énumération, et allow-transfer doit rester fermé sauf si un secondaire en a réellement besoin.

Pointez le client dessus, par liaison

Supposez que NetworkManager possède la connexion et que systemd-resolved soit le résolveur. Lisez d'abord la politique existante, en particulier un éventuel domaine de routage racine, car une entrée ~. primera sur ce que vous êtes sur le point d'ajouter.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

Le tilde est le caractère important. Il marque le domaine comme route seule : les noms sous corp.example vont au serveur DNS de cette liaison, et le domaine n'est pas ajouté comme suffixe de recherche de nom court. Sans lui, taper portal commence à résoudre portal.corp.example, ce qui est pratique pour vous et surprenant pour tous les autres. Gardez le tilde à l'intérieur des guillemets, car un tilde sans guillemets est une expansion du shell qui attend de pointer vers votre répertoire personnel.

Appliquez la modification via le gestionnaire qui possède l'interface, puis reconnectez la connexion. Ne lancez pas une seconde instance de wg-quick pour la même interface ; deux propriétaires se disputeront les routes et l'un d'eux gagnera au pire moment.

Vérifiez le chemin avant le nom

Interrogez le nom depuis le client et confirmez à la fois la réponse et le serveur qui l'a produite :

resolvectl query portal.corp.example

Si cela renvoie 10.60.0.20, le contrat DNS est rempli. Si cela expire, vérifiez d'abord la route vers 10.90.0.1, puis la règle de pare-feu, puis allow-query sur le serveur. Les échecs de résolution de noms dans cette configuration sont presque toujours un problème d'accessibilité ou une ACL, pas le fichier de zone. Travaillez depuis le client vers l'extérieur, car le serveur ne peut pas vous dire pourquoi une requête n'est jamais arrivée.

Rappelez-vous que l'application a toujours besoin de sa propre route et de sa propre autorisation de service. Un nom résolu qui pointe vers une adresse injoignable est une autre panne portant les mêmes habits.

Ce qui n'est toujours pas automatique

Les applications dotées de leur propre logique de résolution ignorent complètement le résolveur du système, et aucune quantité de nmcli n'y changera rien. Les déploiements qui valident DNSSEC ont besoin d'une conception explicite d'ancre de confiance pour la zone privée ; la réponse n'est pas une consigne générale de désactiver la validation. Testez avec le même logiciel client que vos utilisateurs exécutent, pas avec un outil qui utilise par hasard le résolveur du système. L'écart entre les deux, c'est tout le rapport de bug.

Les flottes peuvent automatiser cette politique client via leur système de provisionnement, mais la politique reste un objet distinct avec un propriétaire. La référence BIND 9 couvre les contrôles d'écoute et d'interrogation utilisés plus haut, et c'est le bon endroit pour confirmer le comportement pour votre version installée.

Étape suivante : ajoutez l'incrément de numéro de série de la zone et les commandes de vérification à votre procédure de changement, afin qu'une modification d'enregistrement ne puisse pas atteindre la production sans contrôle.