Donnez à votre VPN domestique ses propres enregistrements DNS pour nas.home.arpa

Une fois le tunnel monté, la dernière étape est généralement un nom qui fonctionne au lieu d'une adresse que vous collez dans un favori. Un enregistrement d'hôte dnsmasq et une adresse de résolveur que le client peut joindre font cela avec deux fichiers et sans multicast. La décision qui demande vraiment réflexion est plus étroite : le client envoie-t-il tout le DNS via le résolveur de la maison, ou seulement les noms sous home.arpa ? Tout ce qui suit suppose une installation WireGuard approuvée avec un client Linux et un résolveur de laboratoire que l'administrateur de la maison gère déjà.

Trois façons de fournir un résolveur au client

Pour un portable qui rejoint le tunnel occasionnellement, le split-DNS est le meilleur choix par défaut : il garde les noms Internet ordinaires sur le résolveur auquel la machine fait déjà confiance. Pour une machine qui existe pour atteindre les services de la maison, pousser le résolveur est plus simple et le coût de portée n'importe pas.

Publiez l'enregistrement sur le résolveur qui possède la zone

Séparez les rôles avant d'écrire la configuration : l'adresse du client VPN, le résolveur et le service sont trois hôtes différents avec trois tâches différentes. Dans ce laboratoire, ce sont 10.77.0.2 pour le client, 192.168.50.53 pour dnsmasq et 192.168.50.20 pour le NAS, le tunnel routant le LAN de la maison.

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

La ligne host-record fournit l'adresse et la ligne local= garde les questions home.arpa inconnues à l'intérieur de ce résolveur au lieu de les transmettre en amont. Lisez d'abord votre configuration existante et réconciliez tout ce qui définit déjà un serveur, une interface ou le même domaine local ; empiler un fragment sur un fragment contradictoire produit un résolveur qui se charge joyeusement et répond mal. Le manuel de dnsmasq définit les deux directives et les contrôles d'écoute.

Vérifiez ensuite le service en cours d'exécution, pas le fichier. Un test de configuration suivi d'un redémarrage est le minimum, et la réponse effective est ce qu'une requête renvoie.

Routez le résolveur, pas seulement la page web

L'AllowedIPs de WireGuard décide quelles destinations entrent dans le tunnel. Si l'adresse du résolveur tombe en dehors, la requête sort par la route normale et n'atteint jamais dnsmasq, même si le NAS lui-même est joignable. Incluez l'adresse du résolveur, ou le préfixe LAN qui la contient, et vérifiez la politique de transfert de la passerelle de l'autre côté.

Autorisez UDP et TCP sur le port 53 depuis la plage de tunnel autorisée, avec un chemin de retour vers l'adresse de tunnel du client. Ne transférez pas le port 53 depuis le WAN pour faciliter les tests : un résolveur récursif ouvert sur une connexion domestique est trouvé en quelques heures. Se lier à une interface n'est pas une politique d'accès en soi.

Vérifiez la réponse avant l'application

Interrogez d'abord le résolveur directement, puis le système, puis l'application. Chaque étape isole un maillon de la chaîne, et la différence entre elles est le diagnostic.

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

La requête TCP vaut la peine d'être exécutée car une réponse UDP tronquée force une nouvelle tentative, et une politique qui abandonne TCP 53 produit des pannes qui semblent intermittentes. L'étape getent montre ce que la configuration de résolveur de la machine fait réellement, ce qui n'est pas toujours ce que vous avez poussé.

Décidez de ce qui se passe quand le tunnel est coupé

Si le DNS général du client pointe vers 192.168.50.53, toute résolution de noms cesse de fonctionner quand le tunnel n'est pas monté. C'est acceptable sur une machine qui n'est utile qu'avec le tunnel, et inacceptable sur un portable qui utilise aussi le Wi-Fi d'un café. Le split-DNS évite entièrement la question, car seules les recherches home.arpa dépendent du résolveur de la maison.

Rappelez-vous ce qu'est le nom : home.arpa est réservé aux réseaux résidentiels et n'est pas unique au niveau mondial, donc un autre réseau peut légitimement utiliser le même nom. C'est une commodité locale, pas un identifiant fiable. Maintenez l'enregistrement à jour lorsque le service déménage, et retirez la politique de résolveur lorsque le laboratoire est retiré plutôt que de laisser un portable pointer vers une adresse qu'il ne peut atteindre que par un tunnel qui n'existe plus.