Noms DNS internes avec WireGuard

Utiliser les adresses IP brutes des pairs WireGuard pour se connecter aux ressources internes de votre réseau WireGuard peut être difficile pour les utilisateurs ordinaires. Heureusement, il est facile de configurer un serveur DNS interne qui permet à vos utilisateurs d’accéder aux ressources exposées via WireGuard avec des noms DNS conviviaux.

Par exemple, supposons que vous ayez configuré un serveur de chat interne avec une adresse IP de pair WireGuard de 10.0.0.11 sur votre réseau WireGuard. Au lieu de nécessiter à vos utilisateurs d’entrer son adresse IP 10.0.0.11 dans leur application de chat ou navigateur Web pour y accéder, vous pouvez configurer votre serveur DNS interne pour utiliser un nom DNS convivial comme chat.wg.corp.

Cet article vous montrera comment configurer un serveur CoreDNS sur le hub d’un réseau WireGuard hub-and-spoke, permettant aux noms DNS résolus par le serveur CoreDNS d’être utilisés pour accéder aux ressources du réseau via le hub. Nous suivrons ces étapes :

1. Désactiver le résolveur de stub

2. Installer CoreDNS

   • Via Docker, ou
   • Via Deb

3. Configurer CoreDNS

• Via Inline Hôtes, or
  • Via Fichier de Hôtes Unique, or
  • Via Fichiers de Hôtes Séparés, or
  • Via Fichiers de Zone Séparés

4. Configurer le Client WireGuard

Réseau Exemple

Nous utiliserons le réseau WireGuard suivant comme exemple, configuré comme le scénario Site Gateway en tant que Spoke de l’article Multi-Hop WireGuard :

Le central Hub WireGuard (configuré comme Hôte C du scénario “Site Gateway en tant que Spoke”) permet à un Client WireGuard (configuré comme Point de terminaison A du scénario “Site Gateway en tant que Spoke”) de se connecter au réseau NY Office via la NY Gateway (configurée comme Hôte β du scénario “Site Gateway en tant que Spoke”) ; et aussi au réseau Cloud Ingénierie via l’Eng Gateway, et à d’autres pairs sur le réseau WireGuard comme le Serveur Chat.

Nous allons configurer un serveur CoreDNS sur le Hub afin que l’utilisateur du Client puisse accéder au Serveur de Chat via un nom DNS convivial chat.wg.corp, au lieu de son adresse IP WireGuard 10.0.0.11; et accéder à l’imprimante de la Bureau de New York via le nom DNS convivial printer.ny.corp, au lieu de son adresse IP LAN 192.168.200.22; et accéder au serveur de fichiers ingénierie via le nom DNS convivial files.eng.corp, au lieu de son adresse IP du réseau Cloud Ingénierie 10.10.10.43.

Pour le serveur de fichiers, nous allons configurer le serveur CoreDNS sur le Hub WireGuard pour déléguer à un serveur DNS privé en cours d’exécution dans le réseau cloud à l’adresse 10.0.0.44, qui est déjà configuré pour résoudre les noms DNS du domaine eng.corp. Pour le Serveur de Chat et l’imprimante, nous allons configurer notre propre serveur CoreDNS pour résoudre les noms DNS des domaines wg.corp et ny.corp.

Désactiver le Résolveur Stub

La première étape pour exécuter CoreDNS sur le Hub est de désactiver tout autre serveur DNS existant sur le Hub (pour libérer le port 53).

Si vous exécutez systemd sur le Hub, vous devrez désactiver le résolveur stub intégré de systemd. Éditez le fichier /etc/systemd/resolved.conf, et définissez son champ DNSStubListener à no :

DNSStubListener=no

Ensuite, appliquez vos modifications en exécutant la commande suivante :

$ sudo systemctl restart systemd-resolved

DNS=127.0.0.1
Domains=~.

Installer CoreDNS

CoreDNS s’exécute en tant que seul exécutable. Vous pouvez simplement télécharger le dernier archive de version à partir de la page des versions de CoreDNS sur GitHub, extraire l’archive (qui contient un seul fichier exécutable), définir les permissions sur l’exécutable et le lancer. Vous pouvez également tirer la dernière image Docker CoreDNS pour exécuter CoreDNS en tant que conteneur Docker; ou vous pouvez construire un fichier deb ou RPM pour installer CoreDNS en tant que service systemd sur les distributions Linux basées sur Debian ou Fedora.

Via Docker

Vous pouvez lancer CoreDNS via Docker Compose à l’aide du fichier docker-compose.yml suivant :

# /srv/coredns/docker-compose.yml
coredns:
  image: coredns/coredns
  command: -conf /etc/coredns/Corefile
  ports:
  - 53:53/udp
  - 53:53/tcp
  volumes:
  - ./conf:/etc/coredns

Pour exemple, créez un répertoire /srv/coredns/ sur le Hub et placez le fichier docker-compose.yml mentionné ci-dessus à l’intérieur. Ensuite, créez un sous-répertoire conf/ dans /srv/coredns/, et placez le Corefile suivant à l’intérieur :

# /srv/coredns/conf/Corefile
. {
  whoami
  log
}

Démarrez Docker Compose depuis le répertoire /srv/coredns :

$ cd /srv/coredns
$ sudo docker-compose up
Pulling coredns (coredns/coredns:)...
latest: Pulling from coredns/coredns
9731739b2823: Pull complete
4dfb45b72a09: Pull complete
Digest: sha256:017727efcfeb7d053af68e51436ce8e65edbc6ca573720afb4f79c8594036955
Status: Downloaded newer image for coredns/coredns:latest
Creating coredns_coredns_1 ... done
Attaching to coredns_coredns_1
coredns_1  | .:53
coredns_1  | CoreDNS-1.10.0
coredns_1  | linux/arm64, go1.19.1, 596a9f9

Testez-le en exécutant la commande suivante sur le Hub :

$ dig @127.0.0.1 example.com

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> @127.0.0.1 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22048
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9b3888d9496d270e (echoed)
;; QUESTION SECTION:
;example.com.                   IN      A

;; ADDITIONAL SECTION:
example.com.            0       IN      A       172.17.0.1
_udp.example.com.       0       IN      SRV     0 0 41596 .

```markdown
;; Temps de requête : 0 msec
;; SERVEUR : 127.0.0.1#53(127.0.0.1) (UDP)
;; QUAND : Jeudi 19 janvier 2023 20:13:03 UTC
;; TAILLE DE MSG rcvd : 114

Comme nous avons configuré CoreDNS avec le plugin whoami (pour des tests), la réponse dans la section “additionnelle” montrera l’adresse IP (172.17.0.1) et le port UDP (41596) à partir duquel vous avez interrogé CoreDNS — pas les informations DNS réelles de example.com.

Vous verrez une entrée de journal correspondante pour la requête dans la sortie de CoreDNS :

coredns_1  | [INFO] 172.17.0.1:41596 - 22048 "A IN example.com. udp 52 false 1232" NOERROR qr,aa,rd 91 0.000098518s

Via Deb

Sur Debian (ou une distribution Linux basée sur Debian comme Ubuntu), vous pouvez installer CoreDNS via un paquet deb. Cela configurera un service systemd convivial pour vous.

Tout d’abord, clonez le dépôt CoreDNS Deployment :

$ git clone https://github.com/coredns/deployment.git coredns/deployment
Clonage dans 'coredns/deployment'...
remote: Énumération des objets : 970, terminée.
remote: Comptage des objets : 100% (111/111), terminé.
remote: Compression des objets : 100% (70/70), terminé.
remote: Total 970 (delta 57), réutilisé 70 (delta 35), réutilisation de paquets 859
Reception d'objets : 100% (970/970), 270.48 KiB | 8.20 MiB/s, terminé.
Résolution des deltas : 100% (525/525), terminé.

$ cd coredns/deployment
$ dpkg-buildpackage -us -uc -b
Command 'dpkg-buildpackage' not found, but can be installed with:
sudo apt install dpkg-dev

Vous devrez peut-être installer les dépendances suivantes pour construire avec succès le paquet deb :

$ sudo apt install dpkg-dev debhelper jq
Lecture des listes de paquets... Fait
...
$ dpkg-buildpackage -us -uc -b
dpkg-buildpackage: info: source package coredns
...

Après que la commande de construction ait réussi, remontez d’un répertoire et vous devriez avoir un nouveau paquet deb CoreDNS :

$ cd ..
ls -1
coredns_0-0_arm64.buildinfo
coredns_0-0_arm64.changes
coredns_1.10.0-0~22.040_arm64.deb
deployment

Installez le paquet deb avec la commande suivante :

$ sudo dpkg -i coredns*.deb
Sélection du paquet précédemment non sélectionné coredns.
(Lecture de la base de données... 71988 fichiers et répertoires actuellement installés.)
Préparation à l'installation de coredns (1.10.0-0~22.040) ...
Dépaquetage de coredns (1.10.0-0~22.040) ...
Paramétrage de coredns (1.10.0-0~22.040) ...
Création du lien symbolique /etc/systemd/system/multi-user.target.wants/coredns.service → /lib/systemd/system/coredns.service.
Traitement des déclencheurs pour man-db (2.10.2-1) ...

Cela installera CoreDNS en tant que service systemd, écoutant sur les ports UDP et TCP 53. Par défaut, il sera configuré avec un fichier Corefile de test similaire auquel nous avons utilisé pour le conteneur Docker ci-dessus :

$ cat /etc/coredns/Corefile
# Fichier Corefile par défaut, voir https://coredns.io pour plus d'informations.

```markdown
# Répondez à chaque requête en dessous de la racine avec le plugin whoami. Enregistrez toutes les requêtes et erreurs sur la sortie standard.
. {
    whoami  # coredns.io/plugins/whoami
    log     # coredns.io/plugins/log
    errors  # coredns.io/plugins/errors
}

Et nous verrons un résultat similaire à celui avec le conteneur Docker ci-dessus si nous exécutons une requête de test contre lui :

$ dig @127.0.0.1 example.com
...
;; SECTION ADICIONAL:
example.com.            0       IN      A       127.0.0.1
_udp.example.com.       0       IN      SRV     0 0 39581 .
...

Et nous verrons un log de sortie similaire à partir de journald pour lui :

$ journalctl -u coredns.service
Jan 19 20:33:57 hub systemd[1]: Started CoreDNS DNS server.
Jan 19 20:33:57 hub coredns[42762]: .:53
Jan 19 20:33:57 hub coredns[42762]: CoreDNS-1.10.0
Jan 19 20:33:57 hub coredns[42762]: linux/arm64, go1.19.1, 596a9f9
Jan 19 20:37:01 hub coredns[42762]: [INFO] 127.0.0.1:39581 - 58758 "A IN example.com. udp 52 false 1232" NOERROR qr,aa,rd 91 0.024847392s

Configurer CoreDNS

Nous pouvons maintenant mettre à jour le fichier de configuration de test Corefile (à /srv/coredns/conf/Corefile si vous avez installé Via Docker, ou /etc/coredns/Corefile si vous avez installé Via Deb) avec une configuration utile pour nos domaines internes.

Via Hôtes Inline

example.com {
    hosts {
        127.0.0.1 example.com
        fallthrough
    }
}

Cela permet à CoreDNS de répondre aux requêtes DNS pour example.com avec l’adresse IP 127.0.0.1.

La méthode la plus simple pour que CoreDNS résolve nos noms DNS internes est de les lister avec le format traditionnel du fichier /etc/hosts directement dans le Corefile. Par exemple, nous pouvons lister les trois noms DNS que nous voulons résoudre (chat.wg.corp, printer.ny.corp, et files.eng.corp) ainsi que leurs adresses IP respectives dans notre Corefile :

# /etc/coredns/Corefile
. {
  hosts {
    10.0.0.11 chat.wg.corp
    192.168.200.22 printer.ny.corp
    10.10.10.43 files.eng.corp
  }
  errors
}

Si nous mettons à jour notre Corefile comme ci-dessus et redémarrons CoreDNS, CoreDNS peut maintenant résoudre ces trois noms DNS — mais seulement ces trois noms DNS :

$ dig +short @127.0.0.1 chat.wg.corp
10.0.0.11
$ dig +short @127.0.0.1 printer.ny.corp
192.168.200.22
$ dig +short @127.0.0.1 files.eng.corp
10.10.10.43
$ dig +short @127.0.0.1 repo.eng.corp
$ dig +short @127.0.0.1 example.com

Ce que nous voulons vraiment faire pour tous les domaines non listés dans notre Corefile est de transférer toutes les requêtes eng.corp au serveur DNS Eng à l’adresse 10.10.10.44, et de transférer toutes les autres requêtes vers un serveur DNS public comme Quad9. Nous pouvons le faire en ajustant notre Corefile pour ajouter une directive fallthrough au plugin hosts, ainsi que deux directives forward — l’une pour notre résolveur DNS Eng, et l’autre pour les résolveurs Quad9 :

# /etc/coredns/Corefile
. {
  hosts {
    10.0.0.11 chat.wg.corp
    192.168.200.22 printer.ny.corp
    fallthrough
  }
  forward eng.corp 10.10.10.44
  forward . 9.9.9.9 149.112.112.112
  errors
}

Redémarrez CoreDNS, et maintenant nous pouvons résoudre les noms DNS codés en dur à partir de notre plugin hosts, ainsi que tout nom DNS de notre serveur DNS privé Eng (comme repo.eng.corp) — et tous les domaines publics (comme example.com), aussi :

$ dig +short @127.0.0.1 chat.wg.corp
10.0.0.11
$ dig +short @127.0.0.1 printer.ny.corp
192.168.200.22
$ dig +short @127.0.0.1 files.eng.corp
10.10.10.43
$ dig +short @127.0.0.1 repo.eng.corp
10.10.10.49
$ dig +short @127.0.0.1 example.com
93.184.216.34

# /etc/coredns/Corefile
. {
hosts {
10.0.0.11 www.example.com
fallthrough
}
forward . 9.9.9.9 149.112.112.112
errors
}

$ dig +short @127.0.0.1 www.example.com
10.0.0.11
$ dig +short @9.9.9.9 www.example.com
93.184.216.34

Via Fichier d’Hôtes Unique

Au lieu de définir des noms DNS personnalisés directement dans notre Corefile, nous pouvons les extraire dans un fichier séparé. L’avantage de cela est a) nous pourrions utiliser le propre /etc/hosts du Hub directement si nous le voulions, et b) nous pouvons configurer CoreDNS pour vérifier périodiquement ce fichier à la recherche de mises à jour (au lieu d’avoir besoin de redémarrer CoreDNS chaque fois qu’on change un nom DNS).

Par exemple, nous pouvons extraire nos noms DNS personnalisés dans un fichier appelé /etc/coredns/hosts :

# /etc/coredns/hosts
10.0.0.11 chat.wg.corp
192.168.200.22 printer.ny.corp

Et ensuite, mettez à jour notre Corefile pour charger les noms DNS à partir de celui-ci (et le recharger toutes les 60 secondes) :

# /etc/coredns/Corefile
. {
  hosts /etc/coredns/hosts {
    reload 60s
    fallthrough
  }
  forward eng.corp 10.10.10.44
  forward . 9.9.9.9 149.112.112.112
  errors
}

Via des Fichiers Hosts Séparés

Nous pouvons également extraire les domaines distincts dans des fichiers hosts séparés, pour notre propre commodité administrative. Par exemple, nous pouvons lister nos entrées DNS wg.corp dans un fichier /etc/coredns/hosts/wg.corp, et nos entrées DNS ny.corp dans un fichier /etc/coredns/hosts/ny.corp :

# /etc/coredns/hosts/wg.corp
10.0.0.11 chat.wg.corp

# /etc/coredns/hosts/ny.corp
192.168.200.22 printer.ny.corp

Le plugin hosts ne peut être utilisé qu’une seule fois par bloc de niveau supérieur dans un fichier Corefile, donc nous devons maintenant structurer notre Corefile avec des blocs de niveau supérieur distincts pour nos domaines wg.corp et ny.corp (et si nous le faisons, il vaut mieux également extraire notre domaine eng.corp dans son propre bloc de niveau supérieur) :

# /etc/coredns/Corefile
wg.corp {
  hosts /etc/coredns/hosts/wg.corp {
    reload 60s
  }
  errors
}
ny.corp {
  hosts /etc/coredns/hosts/ny.corp {
    reload 60s
  }
  errors
}
eng.corp {
  forward . 10.10.10.44
  errors
}
. {
  forward . 9.9.9.9 149.112.112.112
  errors
}

Via des Fichiers de Zone Séparés

Nous pouvons également utiliser des fichiers de zone traditionnels au style RFC 1035 pour définir nos entrées DNS personnalisées. Cela nous permet d’exploiter pleinement les fonctionnalités DNS, comme l’utilisation de CNAME ou SRV records, ou l’application de différentes valeurs TTL (Time To Live) à différentes entrées DNS.

Par exemple, nous pourrions créer le fichier de zone suivant pour le domaine wg.corp :

; /etc/coredns/zones/db.wg.corp
$ORIGIN wg.corp.
$TTL 1h
@                      IN SOA (
                          ns          ; serveur de nom principal
                          .           ; email de l'administrateur du domaine
                          1           ; numéro de série
                          24h         ; intervalle de rafraîchissement
                          2h          ; intervalle de répétition
                          1000h       ; intervalle d'expiration
                          10m         ; TTL négatif
                       )
                       IN NS ns
chat                   IN A 10.0.0.11
hub                    IN A 10.0.0.3
ns                  5m IN A 10.0.0.3
_irc._tcp              IN SRV 10 10 6667 chat.wg.corp.

Et le fichier de zone suivant pour le domaine ny.corp :

; /etc/coredns/zones/db.ny.corp
$ORIGIN ny.corp.
$TTL 1h
@                      IN SOA (
                          ns.wg.corp. ; primary nameserver
                          .           ; zone-admin email
                          1           ; serial number
                          24h         ; refresh interval
                          2h          ; retry interval
                          1000h       ; expire interval
                          10m         ; negative TTL
                       )
                       IN NS ns.wg.corp.
canon650i              IN A 192.168.200.22
printer                IN CNAME canon650i

Si nous plaçons les deux fichiers ci-dessus dans le répertoire /etc/coredns/zones sous les noms db.wg.corp et db.ny.corp, nous pouvons les appliquer via le plugin auto de CoreDNS :

# /etc/coredns/Corefile
. {
  auto {
    directory /etc/coredns/zones
    reload 60s
  }
  forward eng.corp 10.10.10.44
  forward . 9.9.9.9 149.112.112.112
  errors
}

Après le redémarrage, nous devrions être en mesure de rechercher notre enregistrement SRV IRC (Internet Relay Chat) :

$ dig @127.0.0.1 SRV _irc._tcp.wg.corp

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> @127.0.0.1 SRV _irc._tcp.wg.corp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60358
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 50115fc0e15cc095 (echoed)
;; QUESTION SECTION:
;_irc._tcp.wg.corp.             IN      SRV

;; ANSWER SECTION:
_irc._tcp.wg.corp.      3600    IN      SRV     10 10 6667 chat.wg.corp.

;; AUTHORITY SECTION:
wg.corp.                3600    IN      NS      ns.wg.corp.

;; ADDITIONAL SECTION:
chat.wg.corp.           3600    IN      A       10.0.0.11

;; Temps de requête : 0 ms ;; SERVEUR : 127.0.0.1#53(127.0.0.1) (UDP) ;; QUAND : Jeudi 19 janvier 2023 20:20:38 UTC ;; TAILLE DE MSG RÉCUE : 166

En plus du enregistrement `CNAME` pour l'imprimante de la branche NY :

```bash
$ dig @127.0.0.1 printer.ny.corp

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> @127.0.0.1 printer.ny.corp
; (1 serveur trouvé)
;; options globales : +cmd
;; Réponse reçue :
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29728
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
;; AVERTISSEMENT : la récursivité a été demandée mais n'est pas disponible

;; SECTION OPT :
; EDNS : version : 0, flags :; udp : 1232
; COOKIE : 71a27f43c8748c85 (répété)
;; SECTION QUESTION :
;printer.ny.corp.               IN      A

;; SECTION ANSWER :
printer.ny.corp.        3600    IN      CNAME   canon650i.ny.corp.
canon650i.ny.corp.      3600    IN      A       192.168.200.22

;; SECTION AUTHORITY :
ny.corp.                3600    IN      NS      ns.wg.corp.

;; Temps de requête : 0 ms
;; SERVEUR : 127.0.0.1#53(127.0.0.1) (UDP)
;; QUAND : Jeudi 19 janvier 2023 20:20:49 UTC
;; TAILLE DE MSG RÉCUE : 166

Configurer le client WireGuard

Maintenant que notre serveur CoreDNS est en cours d’exécution, la seule chose à faire reste de configurer chaque client WireGuard pour utiliser ce dernier comme serveur DNS lorsque l’interface WireGuard est démarrée.

Depuis que le serveur CoreDNS s’exécute sur notre hub WireGuard, nous utiliserons l’adresse IP de notre hub WireGuard (10.0.0.3) pour l’identifier. Nous devons simplement ajouter cette adresse IP comme paramètre DNS à la section [Interface] de chaque configuration client WireGuard :

# /etc/wireguard/wg0.conf

# paramètres locaux pour le client WireGuard
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821
DNS = 10.0.0.3

# paramètres distants pour le hub WireGuard
[Peer]
PublicKey = jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
Endpoint = 192.0.2.3:51823
AllowedIPs = 10.0.0.0/24, 10.10.10.0/24, 192.168.200.0/24

PostUp = resolvectl dns %i 10.0.0.3; resolvectl domain %i ~corp

Redémarrez WireGuard sur le client après avoir apporté ces modifications.

Nous devrions maintenant pouvoir utiliser nos nouveaux noms DNS amicaux sur le client WireGuard :

$ dig +short chat.wg.corp
10.0.0.11

1/20/2023

par Jennifer Ormond

• WireGuard
• DNS