Table des matières
La résolution des noms
Ce n'est pas parce que les routes sont en place que democlient1
(ou 2 d'ailleurs) va être capable de retrouver l'adresse d'un nœud de l'internet. La preuve sur democlient1
:
ping -c1 irp.nain-t.net ping: irp.nain-t.net: Échec temporaire dans la résolution du nom
Pourtant:
ping -c1 51.68.121.59
PING 51.68.121.59 (51.68.121.59) 56(84) bytes of data.
64 bytes from 51.68.121.59: icmp_seq=1 ttl=52 time=19.6 ms
--- 51.68.121.59 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 19.576/19.576/19.576/0.000 ms
C'est parce que notre client ignore l’existence de serveurs DNS capables de le renseigner. Une solution triviale serait de lui signaler que 192.168.60.254 (le routeur dans notre plateforme de tests) sait faire. Mais nous allons faire bien mieux…
Installation d'un serveur DNS
Le système DNS est capable, s'il est correctement renseigné, de retrouver l'adresse IP qui permet à un client quelconque de l'internet de joindre un nœud de l'internet en connaissant seulement son URI.
Pour l'utilisateur final, il lui suffit de connaître l'adresse IP d'un «résolveur DNS». Tout F.A.I se doit de fournir à ses clients un tel système. En général c'est la Box qui est le résolveur que le client connaît. Ce résolveur peut travailler de différentes manières. Ceci est étudié en détail dans le chapitre dédié à DNS.
Dans l'immédiat, nous allons installer un système complètement indépendant du système de résolution de nom proposé par le FAI, ce qui présente éventuellement quelques avantages:
- Il est tentant pour certains gouvernements un peu trop «paternalistes», d'imposer aux FAI de ne pas permettre à leurs clients de résoudre certains URI jugés dangereux. Notre système a des chances de passer par dessus d'éventuelles blocages, du moins s'ils sont faits de façon basique.
- Notre système, sil reste en service en permanence, répondra probablement plus rapidement aux résolutions récurrentes des nœuds de notre réseau.
- Si le système de résolution proposé par le FAI tombe en panne, ce qui est maintenant rarissime certes, le notre devrait continuer à fonctionner.
- Enfin, si nous disposons d'un nom de domaine officiel (genre
nain-t.net
), il nous sera possible de créer en interne un sous-domaine (genreprivate.nain-t.net
, qui saura résoudre le nom des nœuds de notre LAN. Mais là, il y aura plus de travail pour y arriver.
Sur demoserver
installons le très célèbre bind9
avec un simple apt install bind9
. Il faudra s'assurer qu'il accepte de répondre aux requêtes arrivant sur les interfaces de nos LAN. En attendant, tel qu'il est installé,
Tel qu'il est installé, il est capable par lui-même de résoudre les URI de l'internet. Pour s'en assurer sur demoserver
:
host irp.nain-t.net 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: irp.nain-t.net is an alias for vps.nain-t.net. vps.nain-t.net has address 51.68.121.59La commande
host
permet d'interroger un serveur DNS pour retrouver l'adresse d'un URI. Ici, nous spécifions l'adresse du serveur DNS à interroger : 127.0.0.1 (localhost) et nous obtenons bien la réponse.
Dans la pratique, notre DNS est capable de résoudre par lui-même toutes les demandes d'adresses pour des URI valides.
Pourquoi c'est bien mieux ? Nous l'apprendrons dans le paragraphe destiné au fonctionnement de DNS.
Le signaler aux clients
Là encore, le serveur DHCP va faire le travail.
{ "Dhcp4": { "interfaces-config": { "interfaces": [ "enp7s0" ] }, "valid-lifetime": 360, "renew-timer": 180, "rebind-timer": 350, "authoritative": true, "lease-database": { "type": "memfile", "persist": true, "name": "/var/lib/kea/kea-leases4.csv", "lfc-interval": 3600 }, "subnet4": [ { "subnet": "192.168.61.0/24", "pools": [ { "pool": "192.168.61.100 - 192.168.61.120" } ], "option-data": [ { "name": "routers", "data": "192.168.61.1" }, { "name": "domain-name-servers", "data": "192.168.61.1" } ], } ] } }Le surlignage bleu rappelle l'option concernant la route par défaut, le surlignage jaune est ajouté pour indiquer le serveur DNS accessible.