Administration de Parc Informatique TP03 : Résolution de noms

Institut Galilée L2 Info S1 Année 2013 2014 Administration de Parc Informatique TP03 : Résolution de noms Le but de ce TP est d apprendre aux machines à se connaître par le nom plutôt que simplement par leurs adresses IP. C est-à-dire qu on veut pouvoir faire ping m1 au lieu de devoir systématiquement faire ping 10.0.0.1. Ceci est très utile car les noms de machines ont une logique humaine et sont donc plus facile à retenir que les adresses IP. 1 Un Réseau simple 1.1 Mise en place initiale Ouvrir un nouveau projet. Mettre deux ordinateurs et les connecter à l aide d un câble. Démarrer les ordinateurs. Modifier les fichiers /etc/network/interfaces (cf TP02, partie 4) de manière à assigner une adresse IP statique à chaque machine (prendre un netmask à 255.255.0.0 pour toutes les machines du TP). Activer les interfaces à l aide de ifup. Vérifier que le réseau fonctionne à l aide de ping. 1.2 Configuration logicielle Tout d abord, nous allons configurer statiquement les liens entre les noms de machines et leur adresse IP. Ces liens sont stockés dans le fichier /etc/hosts Regarder la manuel de hosts. Le premier paragraphe, ainsi que la ligne d exemple qui suit immédiatement, explique le contenu du fichier. Chaque ligne contient simplement une adresse IP suivie du nom de la machine correspondante. Éditer le fichier /etc/hosts. Il contient déjà plusieurs lignes reliant des adresses IP à des noms. En particulier, la dernière ligne doit faire le lien entre l adresse de loopback (127.0.0.1) et la machine courante. Comme tout ce qui concerne lo, il ne faut jamais la modifier. Rajouter une ligne au fichier pour indiquer l adresse de la deuxième machine. Répéter l opération sur la deuxième machine. Vérifier en utilisant ping sur le nom des machines (et pas sur les adresses IP) que ça fonctionne. Ce système fonctionne comme un carnet d adresses : chaque machine conserve la liste d adresses de toutes les autres machines. Le problème, c est que si une machine change d adresse, il faut répercuter ce changement dans tous les carnets d adresses. Ce qui peut être long et pénible dans le cas de gros réseaux comme celui de la fac avec une centaine de machines... 2 DNS direct Le DNS (Domain Name System) direct permet de transformer automatiquement un nom de machine en adresse IP. Ce système fonctionne plutôt comme un annuaire (en ligne). Seul l annuaire (le serveur DNS) connaît les adresses de tout le monde. Les autres machines (clients DNS) ne connaissent que l adresse de l annuaire. Quand on a besoin de connaître l adresse de quelqu un d autre, on consulte l annuaire, ce qui est un peu plus long que de consulter son carnet d adresses, mais permet de découvrir des nouvelles adresses. Quand quelqu un déménage, il suffit de changer son adresse dans l annuaire et on n a pas besoin de modifier tous les carnets d adresses individuels. Nous allons mettre en place un système avec 3 machines qui cette fois ci ne seront plus similaires. L une d elles servira de serveur DNS et fournira aux autres, appelées clients DNS le service de résolution des noms. Nous n aborderons pas le DNS inversé qui permet de transformer les adresses IP en nom de machine. Attention! La structure du DNS pour un petit réseau local comme nous allons le faire est nécessairement la même que celle qui soutient tout Internet et permet, en permanence, de connaître l adresse de tous les ordinateurs au monde! Il s agit donc, comme on peut l imaginer, de quelque chose de relativement complexe et il convient de bien faire attention aux différentes étapes du processus. 1

2.1 Mise en place matérielle Ouvrir un nouveau projet. Y mettre 3 machines. Une sera appelée serveur, les deux autres m1 et m2 (par exemple). Rajouter un hub. Connecter les machines au hub. Tout démarrer. 2.2 Adresses et nom de domaine Modifier les fichiers /etc/network/interfaces pour assigner à chaque machine une adresse IP statique. Afin de conserver ici la dissymétrie du réseau, le serveur aura l adresse 10.0.0.254 et les machines 10.0.0.1 et 10.0.0.2 Mettre les netmask à 255.255.0.0 Activer les cartes réseaux (à l aide de ifup) et vérifier à l aide de ping que le réseau fonctionne. Il faut maintenant choisir un nom de domaine pour l ensemble du réseau. Le nom de domaine est ce qui est rajouté après le nom de la machine pour obtenir le nom internet complet. Par exemple, la machine dont le nom est www (nom traditionnel des serveurs web... ) et dont le nom de domaine est google.fr a pour nom internet complet www.google.fr. De même, la machine dont le nom est www et le nom de domaine est univ-paris13.fr a pour nom internet complet www.univ-paris13.fr Bien que ces deux machines aient le même nom (www), elles n appartiennent pas au même domaine et il s agit donc bien de deux machines différentes. Il faut donc un nom de domaine pour le réseau que nous sommes en train de construire. Par exemple, api.fr. Le nom de domaine de chaque machine est indiqué dans le fichier /etc/resolv.conf, ainsi que l adresse du serveur DNS. Ça tombe bien, il nous faut modifier ces deux informations! Regarder le manuel de resolv.conf Après les deux premiers paragraphes, le manuel décrit un certain nombre d options de configurations. La première est nameserver, suivi d une adresse IP, qui correspond au serveur de nom, c est-à-dire au serveur DNS. La deuxième option est domain suivi du nom du domaine local. Seules ces deux options nous intéressent pour l instant. Éditer le fichier resolv.conf Ajouter deux lignes, une pour chacune des options vue précédemment, indiquant le nom de domaine (api.fr) et l adresse IP du serveur DNS (10.0.0.254). Répéter cette opération pour chacune des trois machines. 2.3 Serveur DNS : créer un nouveau domaine Il faut maintenant indiquer au serveur DNS qu il a un nouveau domaine à gérer et lui expliquer comment le gérer. Le nom du programme qui gère le serveur DNS est bind (ou named, son ancien nom). Les fichiers de configuration le concernant sont donc dans le répertoire /etc/bind/ Aller dans le répertoire /etc/bind/ En regarder le contenu. Les fichiers db.* permettent de gérer les domaines correspondants (db est l abréviation de DataBase, base de données). Les fichiers named.conf.* sont des fichiers de configuration de named (i.e. bind) et les deux autres fichiers ne nous intéressent pas. Le principal fichier de configuration, qui contrôle et utilise les autres, est le fichier named.conf Regarder sans le modifier son contenu (par exemple avec less ou more). Les lignes commençant par // sont des commentaires (comme en C). La première ligne utile commence par include : il s agit tout simplement d aller lire le fichier correspondant. Viennent ensuite une série de blocs zone. À chaque zone correspond (entre accolades), un type et un fichier de configuration. Enfin, la dernière ligne du fichier inclut le fichier named.conf.local C est ce fichier qui doit contenir toutes les modifications locales du serveur DNS. Sur le serveur, éditer le fichier named.conf.local (on pourra, en parallèle, visualiser sur une autre machine le fichier named.conf afin de s en inspirer... ) Il faut rajouter un bloc zone pour le nouveau domaine. En s inspirant 1 des blocs zone du fichier named.conf, rajouter un bloc dans named.conf.local sur le serveur (uniquement). Le nom de la zone correspond au nom du domaine à gérer (api.fr). Le type de la zone doit être master car le serveur est le maître de ce domaine et connaît toutes les informations 1. Faire attention notamment aux guillemets, accolades, points-virgules. 2

le concernant. Le nom du fichier de configuration pour la zone est libre, mais autant prendre quelque chose qui respecte les noms précédents, par exemple /etc/bind/db.api.fr Remarque : dans le fichier named.conf, les zones dont le nom finit par in-addr.arpa et commence par un chiffre correspondent au DNS inversé (retrouver le nom d une machine à partir d une adresse IP). Pour mettre en place un DNS inversé sur notre domaine, il aurait fallu créer une telle zone dans named.conf.local. Le suffixe.arpa fait référence au nom du précurseur d Internet : Arpanet. 2.4 Serveur DNS : gérer le nouveau domaine Remarque : pour une description complète du contenu des fichiers de zone, on pourra consulter le manuel détaillé à l adresse http://www.bind9.net/manual/bind/9.3.2/bv9arm.ch06.html#id2564557 Il nous faut donc maintenant créer le fichier /etc/bind/db.api.fr pour expliciter la gestion du domaine. Pour ne pas partir de zéro, nous allons nous inspirer d un des fichiers db.* existant. Sur le serveur, faire une copie du fichier db.local, appelée db.api.fr Éditer le fichier /etc/bind/db.api.fr Dans ce fichier, le symbole de commentaire est le point-virgule (ça aurait été trop simple de conserver le même partout... ) Tout ce qui se trouve dans une ligne après un ; est un commentaire et est ignoré. Le fichier contient ensuite quatre phrases (la première s étend sur plusieurs lignes) commençant par @ (la ligne commençant par TTL est sans importance pour nous). Chaque phrase comporte plusieurs champs 2 (rangés en colonnes). Le premier champ indique le nom de la machine concerné par la phrase (@ est un joker pour signifier moi-même ). Le deuxième champ indique à quelle famille 3 d adresses la phrase correspond. En pratique, seule la famille IN (pour InterNet) nous intéresse, elle correspond à la famille inet du fichier /etc/network/interfaces. Le troisième champ indique un type de phrase. Trois types sont présent dans le fichier et c est les trois seuls qui nous intéressent ici. 2.4.1 Start of Authority Commençons par la phrase de type SOA. Il s agit des initiales de Start Of Authority. Il faut une et une seule phrase de type SOA par zone et ce doit être la première phrase rencontrée. La première ligne de cette phrase contient deux informations que nous allons modifier. Les lignes suivantes sont des valeurs (de temps de latence,... ) dont la signification est résumée à la fin de chaque ligne et que nous ne toucherons pas (les valeurs par défaut sont correctes). Sur la première ligne, après le SOA, il y a deux noms séparés par un espace. Le premier est le nom de la machine qui fait serveur DNS. Il faut donc remplacer localhost par le nom complet du serveur, c est-à-dire serveur.api.fr Attention à conserver le point à la fin du nom de la machine! Le deuxième nom correspond à une adresse mail dont le @ a été remplacé par un point. On indique ici à qui doivent être envoyé les rapports d erreur du serveur (root@localhost, devenu root.localhost). On peut encore envoyer les rapport à root et mettre comme adresse root.serveur.api.fr Attention encore à laisser le point à la fin. 2.4.2 Adresses Maintenant, nous pouvons modifier les phrases de type A et NS. Les phrases de type A sont les plus simples, elles indiquent tout simplement à quelle adresse IP correspond une machine donnée (à l intérieur du domaine). La phrase de type A qu on trouve dans le fichier indique ainsi que la machine @ (rappel : c est un joker pour désigner la machine sur laquelle se trouve le fichier) a pour adresse IP 127.0.0.1 (rappel : il s agit toujours de l adresse de loopback qui revient sur la machine elle-même). Cette phrase est à supprimer, mais on peut la conserver un temps pour s en inspirer pour rédiger les remplaçantes. Pour chacun des deux clients, il faut rajouter une phrase de type A. Cette phrase doit contenir 4 champs : le nom de la machine (sans le nom de domaine, on sait qu on est ici en train de gérer le domaine), la classe IN d adresse, le type A de la phrase et l adresse IP de la machine. 2. Le manuel les appelle RR pour Resource Record (enregistrement de ressources). 3. Le manuel les appelle classes. 3

Par exemple : m1 IN A 10.0.0.1 Rajouter les 2 lignes nécessaires pour gérer les 2 clients. Rajouter aussi une ligne complète pour le serveur (de manière à ce qu il connaisse son nom sans passer par le joker) : serveur IN A 10.0.0.254 Supprimer, si ce n est pas déjà fait, la phrase de type A qui était présente initialement dans le fichier. Supprimer aussi la phrase de type AAAA. La phrase de type NS indique... le serveur de noms 4. Il suffit donc de remplacer le localhost par le nom complet du serveur : serveur.api.fr Attention à bien conserver le point à la fin du nom du serveur. 2.5 Et ça démarre! Comme beaucoup de services, DNS est géré par un démon : un petit programme qui tourne en arrière plan et attend les requêtes. Pour démarrer le serveur DNS, il faut donc démarrer le démon bind9 5. Les fichiers de lancement de démons se trouvent dans /etc/init.d/ (initialisation des d émons). Ici, il doit être appelé avec l argument start (ourestart si le démon est déjà lancé) : /etc/init.d/bind9 start Un message s affiche pour indiquer que le démon se lance. Une fois fini, essayer depuis le serveur de faire un ping sur m1 en utilisant directement le nom de machine (pas l adresse IP). Essayer de même de faire un ping de m1 vers m2. Pas besoin de redémarrer les machines puisque le fichier resolv.conf contient le nécessaire. Remarque : le mécanisme pour assurer le lancement automatique de bind est légèrement hors des bornes de ce TP. Aussi, nous nous contenterons pour l instant de lancer manuellement le script (avec la commande indiquée ci-dessus) à chaque démarrage du serveur. 3 Sous-réseau et DNS secondaire Arrêter toutes les machines. Rajouter 3 nouvelles machines au projet, de noms serveurbis, n1 et n2. Rajouter un deuxième hub et connecter les trois nouvelles machines dessus (ne pas connecter les hubs entre eux pour l instant!) Démarrer toutes les machines. Configurer les 3 nouvelles machines avec les adresses 10.0.1.254, 10.0.1.1 et 10.0.1.2 (penser à prendre le netmask 255.255.0.0). Placer toutes les nouvelles machines dans le domaine toto.fr et configurer un serveur DNS sur serveurbis pour gérer ce domaine. Démarrer le serveur DNS et vérifier qu il fonctionne correctement (à l aide de ping). Arrêter toutes les machines. Rajouter un câble entre les deux hub. Redémarrer toutes les machines. Se connecter sur les serveurs et lancer les démons bind. 3.1 Sous-réseau Depuis m1, vérifier à l aide d un ping directement sur l adresse IP 10.0.1.1 que les deux sous réseaux sont bien connectés (Y a-t-il le bon type de câble entre les hubs?) Attention si ça ne marche pas, il est possible que ça vienne d un netmask trop restrictif. Vérifier qu ils sont bien tous fixés à 255.255.0.0 Vérifier que depuis m1, il est impossible de pinger n1 par son nom. En effet, le serveur DNS de m1 est serveur qui ne connaît pas les machines du domaine toto.fr 3.2 Relais DNS Pour résoudre ce problème, on pourrait recréer, sur serveur, une zone DNS pour gérer le domaine toto.fr (avec le fichier de zone correspondant). Cette solution n est guère praticable car elle obligerait à multiplier les information du DNS et ne serait, au final, guère plus efficace que de mettre les adresses 4. Non, on ne se mord pas complètement la queue, cette phrase est utile dans le cas où il y a des serveurs secondaires qui relaient l information mais ont besoin de connaître le serveur principal. 5. 9 est le numéro de version. 4

en dur dans le fichier hosts (en particulier quand les adresses IP changent et que la base de donnée DNS doit alors être mise à jour... sur tous les serveurs... ) À la place, on va indiquer à serveur que toute requête DNS pour une machine du domaine toto.fr doit être retransmise à serveurbis Éditer le fichier /etc/bind/named.conf.local de serveur Rajouter à la fin une nouvelle zone pour le domaine toto.fr Pour cette zone là, serveur n est pas le maître, il se contentera de retransmettre les requête à un autre serveur. La zone doit donc être de type forward (et non master comme précédemment). Comme la zone est juste une retransmission, il faut maintenant donner l adresse du serveur à qui on retransmet les requêtes. Elle est introduite par le mot clé forwarders (attention au pluriel). Comme il peut y avoir plusieurs serveurs à qui on retransmet les requêtes, leurs adresses (même si ici il n y en a qu une), sont données entre accolades et non entre guillemets, avec un point-virgule après chaque adresse. Rajouter l adresse de serveurbis comme redirection. La nouvelle zone doit maintenant contenir les information suivantes : Une déclaration de zone, avec le nom du domaine entre guillemets (comme pour la zone api.fr), puis une accolade ouvrante pour marquer le début des paramètres de la zone. Un type pour la zone, ici forward, terminé par un point-virgule pour marquer la fin du paramètre type Une liste (réduite à un élément) d adresses de redirection. La liste doit être entre accolades, chaque adresse suivie d un point-virgule, et la liste est introduite parle mot clé forwarders et terminée par un point-virgule (après l accolade fermante de fin de liste). Une accolade fermante pour finir les paramètres, suivie d un point-virgule (comme pour la zone api.fr). Une fois ces modifications effectuées, il faut recharger les paramètres de bind en lançant la commande /etc/init.d/bind9 reload Après, on devrait pouvoir, depuis serveur, m1 ou m2, faire un ping sur une des machines de l autre sous-réseau en utilisant le nom et pas seulement l adresse IP. En utilisant le nom complet, bien sûr, puisque la machine n est pas dans le même sous-réseau (on fait un ping sur www.google.fr, car l ordinateur ne peut pas deviner tout seul si on faisait ping www vers quel serveur web doit se diriger le ping (www.google.fr ou www.univ-paris13.fr?)) 3.3 Zone de recherche On peut vouloir autoriser les machines des deux sous-réseaux à se parler en s appelant par leur petit nom, sans avoir besoin d utiliser leur nom complet. Pour cela, il faut rajouter dans le fichier resolv.conf une directive indiquant les domaines dans lesquels on doit chercher à compléter le nom de machine en un nom complet (par défaut, le domaine dans lequel se trouve la machine est toujours pris en compte). Sur m1, rajouter dans le fichier /etc/resolv.conf une ligne : search toto.fr La machine cherche maintenant à compléter les noms non seulement dans le domaine api.fr (son domaine propre) mais aussi dans toto.fr Essayer de faire, toujours depuis m1, un ping n2. 4 Ce qu il faut retenir Vous devez connaître les fichier /etc/hosts et /etc/resolv.conf ; le concept de DNS et l asymétrie serveur/client. Vous devez connaître l existence : des fichiers de zones (/etc/bind/db.api.fr) en ayant une idée globale de leur contenu ; du répertoire /etc/init.d et de la manière de (re)lancer des services avec les programmes qui s y trouvent. 5