Ajouter cette page à votre livre
Retirer cette page de votre livre
Voir ou modifier le livre ( 
Aide
A. Prise en main de la distribution Ubuntu
Tout système ne déroge pas à la règle qui consiste à s’adapter à la configuration demandée, voire au profil personnel de l’administrateur… Bien gérer son serveur passe par une optimisation du système et la mise en œuvre de réglages indispensables. Bien sûr, cela prend du temps, mais au final vous gagnerez à utiliser cette pratique plus professionnelle.
1. Le principe des paquetages
RPM, sigle bien connu, signifie Red Hat Package Manager (ou RPM Package Manager). À l’origine, c’est une technologie créée par la société RedHat, une des pionnières dans l’élaboration de distributions Linux. Philosophie Linux oblige, ce gestionnaire de paquetages est sous licence GPL. Ubuntu utilise un autre outil de gestion des paquets venant de la distribution Debian : APT (Advanced Package Tool). Existent aussi deux outils plus “évolués” utilisant APT : Aptitude, en mode semi-graphique et Synaptic, cette fois-ci en mode graphique (indisponible en version serveur car ne disposant pas de serveur graphique).
Aptitude gère mieux les dépendances surtout en cas de désinstallation des paquets. Par contre, il vaut mieux l’utiliser dans sa version en ligne de commande en lieu et place d’apt-get plutôt que sa version semi-graphique paradoxalement peu claire… (##komo## demande un temps de prise en main , cf. le lien suivant http://doc.ubuntu-fr.org/aptitude.)
ATTENTION :
On ne doit plus utiliser apt-get après avoir travaillé avec la commande aptitude sous peine de problèmes dans la gestion des paquets. (##komo## plus précis : Il n’est pas conseillé d’utiliser aptitude et apt-get en alternance, le log d’aptitude ne sera pas exhaustif ce qui risque de provoquer des problèmes lors de désinstallations (un grand nombre de paquets à enlever par exemple).
a. Autres méthodes d’installation
Vous pouvez aussi installer un paquetage à partir des sources. Vous adaptez par cette méthode plus finement l’installation à votre configuration mais il faut avoir installé les outils de développement (compilateur, etc.) avec une bonne connaissance de leur utilisation. Vous avez aussi à gérer le problème des dépendances, ce qui n’est pas une chose facile.
Une autre possibilité est que l’installation s’effectue à partir d’un binaire spécial (généralement pour des raisons de copyright), sous forme de binaires autonomes (.bin). Dans ce cas, l’application apporte toutes les bibliothèques (librairies ou lib sous Linux) nécessaires à son fonctionnement. Exemple : le logiciel Acrobat Reader sous Linux.
b. Utilisation d’APT
APT utilise un fichier indiquant les sources de provenance des paquets : /etc/apt/sources.list, là aussi de même facture que celui de la distribution Debian. Sur votre serveur SRVLAN, il doit normalement contenir les lignes indiquant le CD-Rom (en commentaire), celles de la distribution, celles des mises à jour et celles concernant le sécurité. D’autres sont en commentaires (vous en verrez une configuration de base dans cette activité).
Voici une “check-list” des commandes essentielles à connaître (et à pratiquer bien sûr en mode console) :
Sur un paquetage en particulier
Installation d’un paquetage : aptitude install nom_du_paquetage ;
Suppression d’un paquetage : aptitude remove nom_du_paquetage ;
Suppression d’un paquetage et des fichiers de configuration : aptitude purge nom_du_paquetage ;
Recherche d’un paquetage non installé : aptitude search nom_du_paquetage ;
Affichage de renseignements sur un paquetage : aptitude show nom_du_paquetage.
Note(s) :
La recherche peut se faire sur une partie du nom. Exemple : aptitude search build retourne tous les paquetages contenant le mot build.
Les commandes ci-dessous complètent avantageusement celles vues par aptitude :
Recherche plus complète d’un paquetage (cherche aussi dans le descriptif de droite) : apt-cache search nom_du_paquetage.
Recherche d’un paquetage installé : dpkgp -l | grep -i nom_du_paquetage.
Variante : COLUMNS=132 dpkg -l | grep -i nom_du_paquetage pour éviter que le nom du paquetage soit tronqué à l’affichage.
Connaître l’appartenance d’un fichier à un paquetage installé : dpkg -S nom_du_fichier.
Sur l’ensemble du système :
Mise à jour de la liste des paquetages disponibles : aptitude update.
Mise à niveau des paquets : aptitude upgrade.
Mise à niveau de tout le système en une seule fois : aptitude dist-upgrade.
Suppression des paquets non utilisés : aptitude clean.
2. La gestion des services au démarrage
Avant de pouvoir configurer l’accès aux services, il faut comprendre les niveaux d’exécution de Linux. Un niveau d’exécution est un mode défini par les services contenus dans le répertoire /etc/rcx.d, où x est le numéro du niveau d’exécution. La distribution Ubuntu distingue les niveaux d’exécution suivants :
0 -> Arrêt
1 -> Mode mono-utilisateur
2 à 5 -> Mode multi-utilisateur complet (réseau)
6 -> Redémarrage
Le fichier /etc/event.d/rc-default décrit le niveau d’exécution pour les processus qui doivent être lancés au démarrage du système (géré par Upstart autrefois dévolu au fichier inittab). Dans ce fichier, la commande telinit 2 donne le niveau de démarrage d’Ubuntu (ici le niveau 2). Pour changer immédiatement de niveau d’exécution en tant que root et utilisez la commande :
[root]# telinit numéro_niveau_d’exécution
# telinit 6 provoque un redémarrage
a. Détails sur les niveaux d’exécution
Sur Ubuntu, c’est le script /etc/init.d/rcS (en fait le script rc) qui exécute les actions pour le niveau passé en argument. Par exemple, un passage de l’argument 2 déclenchera l’exécution des scripts du répertoire /etc/rc2.d. Les répertoires contiennent des scripts du type Snnxxx ou Knnxxx : S pour Start et K pour Kill. Vous comprenez aisément que le niveau 0 ou 6 contiennent des scripts du type K. Le numéro détermine l’ordre d’exécution.
L’outil update-rc.d :
Même s’il existe des outils plus conviviaux (vous verrez sysvconfig plus loin), la connaissance de l’outil update-rc.d, qui gère un service en fonction des niveaux, est indispensable. Voici un exemple qui consiste à retirer le service acpid (gestion de l’énergie) de tous les niveaux de démarrage :
[root]# update-rc.d -f acpid remove
Notez le message de retour car il nous donne des indications sur les ordres d’exécution :
Exemple de commande update-rc.d
Avec ces renseignements vous pouvez réactiver le service par exemple pour le niveau 2 :
[root]# update-rc.d acpid start 99 2 . stop 01 S .
ATTENTION :
Respectez absolument les espaces et les points ; voir le manuel en ligne (man acpid) pour plus de renseignements sur la commande.
3. Premiers réglages indispensables
Vous allez améliorer votre serveur SRVLAN et le rendre plus performant en procédant à des réglages du système.
Note(s) :
Certaines des opérations ci-dessous (modifications de fichiers) sont à réaliser à l’aide de l’éditeur de texte VIM, dont vous devez connaître l’utilisation… (indispensable pour un administrateur réseau). Pour vous rafraîchir la mémoire, consultez l’ANNEXE.
a. Rétablir le compte de l’administrateur
La distribution Ubuntu désactive le compte root et, pour effectuer les tâches administratives, utilise la commande sudo avec le compte de l’utilisateur créé pendant l’installation. Effectuer des tâches en tant que root est dangereux pour le système mais :
nous sommes dans une situation d’apprentissage où nous devons être root ;
l’utilisation de sudo devient vite fastidieuse ;
tous les avantages de sudo sont facilement discutables voire gênant dans quelques cas.
⇒ Passez sous l’identité et l’environnement du compte root par la commande (entrez le mot de passe du super-utilisateur) : [utilisateur@srvlan:~$]# sudo -i.
⇒ Donnez un mot de passe pour l’administrateur : [root]# passwd.
⇒ Indiquez le mot de passe du compte root et sa confirmation.
⇒ Tapez deux fois exit et connectez-vous ensuite en tant que root, toutes les manipulations se dérouleront désormais sous ce compte.
Notez que vous n’avez pas pour root de fichier .bash_profile mais .profile ce qui ne change en fait pas grand-chose. Par contre, vous n’avez pas de fichier .bash_logout ce qui présente l’inconvénient de ne pas effacer l’écran lors d’une déconnexion de la console.
⇒ Pour remédier à cet inconvénient, copiez le fichier .bash_logout de votre utilisateur privilégié dans le répertoire du root :
[root]# cp /home/utilisateur/.bash_logout /root/
b. Contrôler la source des paquetages
Vous allez modifier plus finement le fichier contrôlant les sources d’APT afin de mieux l’adapter à votre serveur (vous devez posséder une connexion à Internet ; en cas de problèmes, reportez-vous à la section Configuration réseau d’un serveur de ce chapitre).
⇒ Récupérez la dernière liste des paquets, d’après le contenu de /etc/apt/sources.list :
[root]# aptitude update
⇒ Mettez à jour le système dans son entier (validez par Y en cas de mises à jour) :
[root]# aptitude dist-upgrade
[root]# aptitude clean
Note(s) :
Rappel : préférez la commande dist-upgrade à upgrade car elle essaie de mettre à jour aussi toutes les dépendances.
4. Suite des réglages indispensables
a. Installer la version complète de VIM
⇒ L’éditeur VI comporte en l’état quelques limitations aussi vous devez installer la version complète (vous pouvez ensuite taper indifféremment vi ou vim) :
[root]# aptitude install vim
b. Créer un fichier des sources plus « propre »
En l’état, le fichier des sources n’est pas très clair, on peut aisément le raccourcir afin de le rendre plus lisible. Notez la présence pour chaque source des déclinaisons main (paquets de la distribution officiels), restricted (paquets non libres maintenus officiellement), universe (paquets maintenus par la communauté) et multiverse (paquets non libres maintenus par la communauté).
Modifiez le fichier par vim /etc/apt/sources.list comme suit :
# Sources Jaunty
deb http://fr.archive.ubuntu.com/ubuntu/ jaunty main restricted universe
multiverse
#deb-src http://fr.archive.ubuntu.com/ubuntu/ jaunty main restricted
universe multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted
universe multiverse
#deb-src http://fr.archive.ubuntu.com/ubuntu/ jaunty-updates main
restricted universe multiverse
deb http://security.ubuntu.com/ubuntu jaunty-security main restricted
universe multiverse
#deb-src http://security.ubuntu.com/ubuntu jaunty-security main restricted
universe multiverse
Les lignes concernant les sources de paquetage sont laissées en commentaires car il est assez rare de les utiliser.
c. L’outil sysvconfig
Il vaut mieux utiliser l’outil sysvconfig pour gérer les services au démarrage. D’autre part, la commande free permet de connaître l’état d’occupation de votre mémoire RAM ce qui va permettre de vérifier l’espace libéré.
⇒ Tapez la commande free et notez l’espace mémoire utilisé.
⇒ Installez le paquetage sysvconfig :
[root]# aptitude install sysvconfig.
⇒ Lancez l’utilitaire par la commande sysvconfig :
Écran principal de l’outil sysvconfig
⇒ Choisissez la première option Enable/Disable (Enable or disable a service) et décochez les cases pour quelques services inutiles pour notre cadre d’expérimentation, notamment avec VMware (il y en a peu si vous utilisez une image JEOS) :
la gestion d’énergie : acpid ;
le service pour les connexions sans-fil : rwpa-ifupdown.
⇒ Une nouvelle option est apparue dans le menu et c’est elle que vous choisissez : Finished (Finish and save files).
⇒ Acceptez et quittez l’utilitaire.
⇒ Redémarrez votre serveur et lancez à nouveau la commande free afin de constater la différence d’occupation mémoire.
Info(s) : Sous Debian
Installer plutôt l'outils sysv-rc-conf :
root@srvlan:~# aptitude install sysv-rc-conf
root@srvlan:~#sysv-rc-conf
d. Configurer et optimiser son poste de travail
Enlevez par vim ou par nano le # de commentaire dans le fichier /root/.bashrc pour avoir un prompt en couleurs à la ligne traitant de la variable PS1 (PS1=…) en dessous de # Comment… (valable à la prochaine connexion).
Utilisez une base de données pour la recherche de fichiers ; la commande updatedb génère la base et la commande locate permet de l’utiliser (voir le manuel en ligne pour plus de précisions) :
[root]# aptitude install locate
[root]# updatedb
Il suffira par exemple ensuite de taper locate interfaces pour trouver l’emplacement du fichier de configuration réseau. La commande locate interface retournera tous les fichiers contenant le mot interface.
e. Utiliser uniquement la langue française
En règle générale, un utilisateur n’utilise qu’une seule “locale”, pour nous celle correspondant à la langue française soit la locale fr_FR. Des espaces peuvent être libérés avec l’utilisation de la seule langue locale et l’installation d’un paquetage spécifique.
Installez le paquetage localepurge :
[root]# aptitude install localepurge
Sans difficulté à configurer, il suffit d’être très attentif lors de la sélection par la barre d’espaces des quatre options suivantes : fr, fr_FR, fr_FR@euro et fr_FR@.UTF-8. Attention : mal répondre peut entraîner la suppression de tous les fichiers de locale, même ceux qui sont utilisés et il s’avère très difficile de les récupérer…
f. Ne pas oublier d’installer les outils VMware…
Ceci est à faire bien sûr, uniquement en cas de machines virtuelles.
⇒ Installez les paquetages :
[root]# aptitude install build-essential linux-headers-`uname -r` psmisc
En revenant dans le navigateur et sur la console d’administration de VMware Server pour srvlan, onglet Summary, bloc Status, cliquez sur le lien Install Vmware Tools et le bouton Install.
⇒ Revenez dans la console de la machine virtuelle et « montez » le CD-Rom des utilitaires :
[root]# mount /media/cdrom
⇒ Copiez le paquetage des utilitaires correspondant à notre distribution :
[root]# cp /media/cdrom/VMwareTools-7.7.5-156745.tar.gz /root
⇒ Désarchivez le paquetage et positionnez-vous dans le répertoire avant de lancer le script PERL d’installation :
[root]# tar -zxvf VMwareTools-7.7.5-156745.tar.gz
[root]# cd vmware-tools-distrib/
[root]# ./vmware-install.pl
Il suffit dans la procédure de valider toutes les questions posées avec les options par défaut proposées à l’exception de celle sur l’installation du module vmhgfs (partage de fichiers entre la machine virtuelle et le système hôte) car il pose quelques problèmes… Répondre alors no dans ce cas.
g. Installer le manuel en ligne
Pour expliciter les commandes Linux, il existe un manuel en ligne, commande : man nom_de_la_commande. Normalement installé par défaut dans une version poste de travail, il faut le faire manuellement pour une version serveur (##komo## A vérifier) :
[root]# aptitude install manpages man-db manpages-fr
h. Alléger le menu Grub
ATTENTION : GRUB 2
Passer cette partie
Le fichier de configuration du démarrage /boot/grub/menu.lst nécessite d’être expurgé de quelques éléments.
Enlevez toutes les lignes de commentaires commençant par le caractère # sauf celle de la ligne color cyan/blue white/blue.
Enlevez la ligne hiddenmenu, non nécessaire, car le menu doit s’afficher au démarrage.
(Optionnel) Enlevez les mots quiet et splash pour avoir plus d’informations au démarrage.
Vous obtenez un fichier beaucoup plus court avec le contenu suivant (les UUID changent selon votre configuration) :
default 0
timeout 3
color cyan/blue white/blue
title Ubuntu 9.04, kernel 2.6.28-11-server
uuid fa2b5bec-2f05-4190-9e47-af3e69e695f6
kernel /boot/vmlinuz-2.6.28-11-server root=UUID=fa2b5bec-2f05-4190-
9e47-af3e69e695f6 ro quiet
initrd /boot/initrd.img-2.6.28-11-server
quiet
title Ubuntu 9.04, kernel 2.6.28-11-server (recovery mode)
uuid fa2b5bec-2f05-4190-9e47-af3e69e695f6
kernel /boot/vmlinuz-2.6.28-11-server root=UUID=fa2b5bec-2f05-4190-
9e47-af3e69e695f6 ro single
initrd /boot/initrd.img-2.6.28-11-server
quiet
B. Configuration réseau d'un serveur
Normalement Ubuntu détecte le pilote de périphérique Ethernet adéquat. Le système Linux se basant sur un noyau de type modulaire, les composants (modules) s’intègrent en fonction des besoins. Une particularité, sur la Debian comme sur la Ubuntu, la configuration réseau diffère des autres distributions Linux.
1. Environnement réseau d’un système Ubuntu
Le module correspondant à votre périphérique carte réseau (nommé eth0 pour la première) est détecté à l’installation du système et chargé ; voir pour cela le résultat des commandes dmesg pour identifier la carte et lsmod pour voir le chargement du module :
Commandes de vérification de la carte réseau eth0
Pour manipuler les modules, le paquet modconf fournit le script /usr/sbin/modconf qui peut être utilisé pour personnaliser la configuration des modules. Autre outil possible, la commande modinfo nom_de_module qui, comme son nom le précise, donne des informations sur un module.
Pour le reste, je suppose connus les rudiments de l’adressage IP, comme les notions de masque de sous-réseau et de diffusion multiple (broadcast). L’adressage IPv6 destiné à remplacer IPv4, ne sera pas vu ici en raison de sa (trop) tardive prise en compte par les acteurs du monde informatique.
a. Principaux fichiers et scripts
Par défaut, le système Ubuntu (en poste de travail et non comme ici en serveur) utilise le logiciel Network Manager pour gérer automatiquement les connexions réseau du système. C’est ce qui rend facile la connexion Wi-Fi d’un poste de travail par exemple. Pour un serveur, le principe consiste à gérer soit même la configuration réseau dans le fichier /etc/network/interfaces.
Fichiers de configuration :
# Associations fixes entre adresses IP et noms de machines
/etc/hosts
# Spécifications du domaine et serveur DNS
/etc/resolv.conf
# Configuration des cartes réseau
/etc/network/interfaces
Scripts de démarrage et commandes :
# Script d’attribution des paramètres réseau
/etc/init.d/networking
# Commande servant à déterminer les routes statiques du réseau
/sbin/route
# Commande modifiant ou affichant la configuration réseau
/sbin/ifconfig
2. Le routage sous Ubuntu
Les machines de votre réseau ont besoin de “parler” avec des ordinateurs situés sur d’autres réseaux et évidemment le réseau des réseaux : Internet. Comme pour la circulation automobile, une route à travers une passerelle (ou porte de sortie) doit être définie. Ceci se réalise et se contrôle avec une table de routage, définie de deux façons :
soit statique et gérée par l’administrateur dans le cas d’un nombre réduit de passerelles ;
soit dynamique, construite par des protocoles de routage dans les autres cas. *
On réserve la pratique de tables de routage statiques pour les machines d’un réseau et de protocoles de routage, donc de tables dynamiques pour les passerelles (voire une combinaison des deux). Tout système Linux dispose d’une table de routage minimale. Pour consulter celle-ci, on utilise soit la commande netstat -rn, soit la commande route (##komo## ip route).
a. Route par défaut et route statique
Dans le cas classique d’un réseau où l’une des machines fait fonction de routeur (ou alors d’un équipement de type commutateur/routeur) pour l’accès Internet, vous devez configurer une route statique par défaut pour les accès externes. Rappel : le routeur sera dans ce cas aussi appelé passerelle. L’ajout de la route par défaut se fait par la commande route.
Exemple :
[root]# route add default gw 192.168.254.2
Ce qui ajoute la ligne suivante dans la table de routage :
default 192.168.254.2 0.0.0.0 UG 0 0 0 eth0
Cette route par défaut s’ajoute aussi par la ligne gateway et sa valeur dans le fichier /etc/network/interfaces. Ensuite, une route statique se crée par :
[root]# route add -net reseau_dest netmask masque_reseau gw passerelle dev interface
Soit pour une route statique vers le réseau 192.168.0.0 avec un masque de 255.255.255.0 et une passerelle en 192.168.0.1 :
[root]# route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.0.1 dev eth0
La suppression d’une route s’effectue par l’emploi de l’option del suivie du réseau de destination. Attention : pour modifier une route, il faut d’abord la supprimer et ensuite la créer à nouveau.
b. La translation d’adresses IP par le NAT
L’acronyme NAT se forge à partir des initiales de Network Address Translation, ou “Traduction d’Adresse Réseau”. Fondamentalement, NAT modifie les adresses IP dans l’en-tête d’un datagramme IP effectuée par un routeur. Dans notre exemple de réseau d’entreprise, on parlera “d’IP Masquerading” ou NAT dynamique. Il s’agit en réalité de PAT (Port Address Translation) plus que d’une simple traduction des adresses IP. En fait, le routeur remplace aussi le port TCP/UDP source par un nouveau qu’il choisit lui-même. Ainsi, puisque c’est lui qui les choisit, il n’en choisira pas deux identiques, et pourra identifier chacune des connexions. Il garde ces informations dans une table NAT de façon à effectuer la correspondance pour le retour. Vous verrez dans un autre chapitre la technique du port forwarding.
c. Pourquoi le NAT ?
Parce qu’il offre deux avantages certains : il masque les adresses IP vis-à-vis de l’extérieur pour la sécurité et il permet de s’affranchir de la gestion des tables de routage, le NAT s’en occupant à notre place. Le serveur DNS sur le réseau n’aura (et ne connaîtra) que l’adresse IP du routeur de votre réseau. Ce dernier se chargera de la transmission des trames IP sur son réseau interne. (##komo## pas clair)
3. Ajouter une interface réseau au serveur
Vous allez modifier la configuration réseau de votre serveur SRVLAN en ajoutant une nouvelle carte réseau à la machine et la fonctionnalité de routeur/NAT. Actuellement la configuration réseau de SRVLAN montrée par la commande ifconfig donne quelque chose comme cela :
Configuration IP du serveur SRVLAN
L’IP indique 192.168.254.129 ce qui correspond au réseau NAT par DHCP Vmware de ma configuration. Elle change pour vous bien évidemment : soit avec un DHCP différent en cas de réseau physique, soit un choix de réseau NAT lui aussi différent.
a. Configuration réseau du serveur SRVLAN
Il existe deux méthodes pour configurer l’interface réseau : la modification des fichiers de configuration ou la commande ifconfig. Cette dernière présente l’inconvénient d’être remise en cause à chaque redémarrage, aussi vous ne verrez que la première. Dans notre modèle, la configuration réseau de l’interface eth0 dépend de deux facteurs :
soit vous êtes dans la situation d’un réseau physique, auquel cas cette configuration c’est-à-dire l’adresse IP de l’interface, de la passerelle et du DNS dépend de votre routeur personnel pour l’accès vers l’extérieur ; vous pouvez alors passer directement à l’ajout de la carte eth1.
soit vous êtes dans la situation d’un réseau virtuel avec VMware Server, auquel cas le mieux est de suivre la configuration donnée par votre NAT mais par une adresse fixe.
b. Modification de la carte eth0
ATTENTION : duplication de réseau
Si vous avez suivi le TP labcisco, vous avez peut être un vmnetx en 192.168.254.0/24, vérifier les réseaux sur vos vmnetx pour qu'il n'y ai pas de réseau dupliqué.
Mon adresse IP s’appuie sur le réseau 192.168.254.0. Comme vmnet8 du système hôte dispose de l’adresse 192.168.254.2 et celle du système hôte 192.168.254.1, le mieux est de fixer l’adresse de SRVLAN à 192.168.254.3. Adaptez votre adresse en fonction de votre réseau (exemple : si vous avez 192.168.45.0, cela donnera 192.168.45.3 pour SRVLAN). Soyez impérativement en adresse de classe C (commençant par 192) pour votre NAT. Au besoin changez-en en lançant le programme vmnetcfg.exe dans Programmes Files - VMware - VMware Server. Une fois lancé : onglet Host Virtual Network Mapping, ligne VMnet8, bouton >, ligne Subnet.
⇒ Changez la configuration du fichier /etc/network/interfaces pour l’interface eth0 (garder les deux lignes ayant trait à l’interface de la boucle locale dite « lo ») qui montre une configuration en DHCP et que vous allez passer en statique :
auto eth0
iface eth0 inet static
address 192.168.254.3
netmask 255.255.255.0
network 192.168.254.0
broadcast 192.168.254.255
gateway 192.168.254.2
⇒ Relancez le service réseau par /etc/init.d/networking restart.
c. Ajout de la carte eth1
Cas de la situation d’un réseau physique :
Installez (si cela n’a pas été fait) l’autre carte réseau eth1. Ensuite allez directement au point : Configuration de la carte eth1.
Cas de la situation d’un réseau virtuel :
Vous allez ajouter, non seulement le réseau pour eth1 mais aussi celles dont vous aurez besoin pour l’ensemble du réseau (comme ça, il ne sera pas nécessaire de refaire cette manipulation).
⇒ Éteignez la ou les machines virtuelles en fonctionnement.
⇒ Lancez l’éditeur de réseau VMware par Programmes - VMware - VMware Server - Manage Virtual Networks (ou au choix lancement de vmnetcfg.exe dans C:\Program Files\VMware\VMware Server), onglet Host Virtual Adapters, bouton Add.
⇒ Ajoutez VMnet2, VMnet3 et VMnet4 et cliquez sur le bouton Appliquer (cela prend un certain temps…).
⇒ Au niveau de l’onglet Host Virtual Network Mapping, indiquez les différents réseaux (subnet) à l’aide du bouton > :
192.168.2.0 pour vmnet2 ;
192.168.3.0 pour vmnet3 ;
192.168.4.0 pour vmnet4.
⇒ Cliquez sur le bouton Appliquer.
Cette manipulation a eu pour effet de créer trois nouvelles interfaces réseau sur le système hôte.
⇒ Au niveau de l’onglet DHCP, cliquez sur le bouton Remove pour chaque sélection de ces trois réseaux et à la fin, cliquez sur le bouton Appliquer.
Explication : il ne faut pas de service DHCP venant de VMware pour ces trois réseaux.
⇒ Cliquez sur le bouton Ok.
⇒ Revenez sur la ligne de votre machine hôte dans le bloc Inventory de la console d’administration et cliquez sur le lien Refresh Network List dans le bloc Commands.
Vous disposez maintenant de vos trois nouvelles interfaces dans le bloc Networks. Une dernière chose concernant ces trois interfaces : techniquement chaque machine virtuelle branchée dessus sera en communication avec le système hôte via l’interface ajoutée par VMware. Pour isoler nos différentes machines, il faut les désactiver sur le système hôte.
⇒ Ouvrez Paramètres - Panneau de configuration - Connexions Réseau ; faites un clic droit sur chaque interface VMnet2, VMnet3, VMnet4 et désactivez-les.
⇒ À partir de l’écran de la machine virtuelle SRVLAN dans la console d’administration, cliquez sur le lien Add Hardware dans le bloc Commands.
⇒ Choisissez Network Adapter avec VMnet4 comme type de connexion, puis cliquez sur le bouton Finish.
Votre nouvelle interface apparaît dans l’inventaire du matériel ; ⇒ démarrez à nouveau le serveur. La carte sera en eth1 et sur le réseau 192.168.4.0 en liaison plus tard avec le client.
d. Configuration de la carte eth1
⇒ Ajoutez à la configuration du fichier /etc/network/interfaces la nouvelle interface eth1
auto eth1
iface eth1 inet static
address 192.168.4.254
netmask 255.255.255.0
network 192.168.4.0
broadcast 192.168.4.255
⇒ Vérifiez la configuration du fichier /etc/resolv.conf qui contient la ou les adresses des serveurs DNS :
# le domaine sur lequel on est, cette ligne peut être supprimée
# elle ne sert qu’en cas d’absence de nom pleinement qualifié
# (FQDN) dans une commande ; le système ajoutant automatiquement
# le domaine à droite de la commande search (faux ami donc)
domain localdomain
search localdomain
# classiquement le ou les DNS du fournisseur d’accès
# rappel : configuration dans une situation VMmware
# vous changez par la vôtre en cas d’un serveur physique
nameserver 192.168.254.2
⇒ Relancez le script de gestion du service /etc/init.d/networking :
[root]# /etc/init.d/networking restart
Ce qui aura pour effet d’arrêter puis de redémarrer le service réseau avec votre nouvelle configuration. On peut évidemment exécuter d’abord un stop puis un start. Vous avez aussi la possibilité d’utiliser la commande service, par exemple : service networking restart. Cela permet de démarrer, stopper ou redémarrer un service sans faire référence à l’emplacement de son script. Par contre, vous devez connaître la syntaxe exacte du nom du service, la complétion (remplissage automatique du nom par la touche tabulation) ne fonctionnant pas à l’inverse de la première commande.
⇒ Vérifiez la bonne configuration réseau de votre machine par la commande ifconfig.
Cette commande sert surtout à donner des informations sur la configuration de l’interface réseau. Un ifconfig eth0 donnera uniquement la configuration de l’interface demandée alors qu’un simple ifconfig donnera la configuration de toutes les interfaces (boucle locale comprise). On peut aussi l’utiliser pour changer de manière ponctuelle la configuration d’une interface réseau mais celle-ci sera réinitialisée au prochain redémarrage de la machine.
En cas de problème vous pouvez utiliser une commande (à installer avant par aptitude install ethtool, il existe aussi l’outil mii-tool moins pratique) vérifiant la bonne connexion (réponse yes si elle est détectée) de l’interface réseau ethtool nom_interface :
Exemple de commande ethtool
⇒ Vérifiez la bonne configuration réseau de votre machine par la commande ping adresse_IP sur ses deux propres interfaces :
[root]# ping 192.168.254.3
[root]# ping 192.168.4.254
Cette commande fondamentale sert à envoyer via le protocole ICMP un “ECHO_REQUEST datagram” pour obtenir un “ECHO_RESPONSE” de façon à tester la connexion physique du réseau. Un petit clin d’œil, si vous ajoutez l’option -c 4 après le ping vous obtenez une sortie à la manière de Windows…
⇒ Vérifiez la passerelle par défaut par la commande route sans paramètre.
Voici une autre façon moins classique (peut-être un peu compliquée…) de connaître la passerelle par défaut :
[root]# netstat -rn | grep UG | awk ’{print $8}’
Ce qui se traduit par l’utilisation de l’outil netstat pour les routes via un “tube” par la commande grep sur l’indicateur U (route is up) et G (use Gateway) et à nouveau par un tube vers l’interpréteur awk permettant l’affichage du huitième champ. Résultat de l’affichage : eth0.
Vérifiez l’accès à l’Internet par (et dans l’ordre) :
un ping réussi sur la passerelle (192.168.254.2) : vous atteignez votre porte de sortie ;
un ping réussi sur www.google.fr : vous allez sur l’Internet.
4. Transformation du serveur SRVLAN en routeur
Transformer un serveur en routeur consiste à faire transiter les paquets arrivant par eth1 vers eth0.
⇒ Tapez la commande positionnant un drapeau pour le processus ip_forward :
[root]# echo 1 > /proc/sys/net/ipv4/ip_forward
Le résultat est immédiat mais temporaire, car annulé au redémarrage du système ; il faut le rendre définitif par la modification d’un fichier de configuration : vous pouvez enlever le # de commentaire à la ligne net.ipv4.ip_forward=1 dans le fichier /etc/sysctl.conf.
La plupart des documentations préconisent cette pratique, mais je lui préfère pour « plus de souplesse », le positionnement dans le fichier /etc/rc.local. Ubuntu fournit ce fichier pour pouvoir placer des scripts personnels exécutés au démarrage de la machine.
⇒ Mettez dans ce fichier la ligne suivante avant exit 0 :
echo 1 > /proc/sys/net/ipv4/ip_forward
Votre réseau peut communiquer avec l’extérieur… mais pas encore en fait. Il faut aussi paramétrer votre serveur pour faire de la translation d’adresses. Petit aparté : si vous êtes resté avec la commande sudo, là vous avez des problèmes… ce qui vous montre par a+b qu’il fallait réinstaller le compte root…
a. Mettre en place la translation d’adresses
NAT fonctionne avec le service iptables. Vous retrouverez ce service lors de la configuration du pare-feu.
⇒ Assurez-vous de sa non-installation par :
[root]# dpkg-query -W | grep -i iptables
Ce qui se traduit par une recherche dans la base via un “tube” par la commande grep du paquetage iptables. Si le résultat de la commande ne vous retourne rien, il faut installer le paquetage.
[root]# aptitude install iptables
⇒ Mettez en place l’IP Masquerading par la commande :
[root]# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Ce qui s’explique par :
-t nat pour indiquer l’utilisation de la table NAT.
-A POSTROUTING pour ajouter la règle sur les paquets sortant de l’interface.
-o eth0 pour indiquer l’interface (celle sur l’extérieur).
-j MASQUERADE pour indiquer l’échange de l’adresse IP avec celle du serveur.
⇒ Vérifiez la bonne prise en compte de la règle par :
[root]# iptables -t nat -L
Sortie de la commande affichant les règles iptables
La ligne MASQUERADE all (toutes les sources et destinations) montre que cela est le cas.
Activer la translation d’adresses (NAT) au démarrage :
⇒ Inscrivez la ligne suivante juste avant exit 0 mais après la ligne concernant le routage dans le fichier /etc/rc.local :
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
⇒ Relancez votre système et vérifiez à nouveau l’existence de la règle NAT à l’aide de la commande vue plus haut.
C. Installation de deux systèmes sur un PC
Dans le cadre de l’étude, l’intérêt réside dans l’installation de systèmes clients afin de montrer deux approches différentes, essentiellement pour Windows avec Samba et Linux avec NFS/NIS/LDAP. La deuxième raison est inhérente à l’architecture client/serveur : montrer comment fournir des services réseau à des postes clients.
1. Les processus de démarrage et d’arrêt
Concrètement, le processus de démarrage d’un ordinateur basé sur un processeur de type x86 suit les étapes suivantes :
Schéma de démarrage de premier niveau :
1. À l’allumage, le processeur lance le BIOS (Basic Input/Output System) à partir de la mémoire morte (ROM).
2. Le BIOS effectue un certain nombre d’opérations liées au système et donne le contrôle au MBR (Master Boot Record) situé sur le premier secteur du premier disque dur.
3. Le MBR exécute le chargeur de démarrage LILO ou GRUB pour Linux.
4. Le chargeur de démarrage charge le noyau dans la mémoire.
5. Le noyau donne le contrôle à INIT, “processus parent” de tous les autres.
Il existe deux formes d’INIT, celle nommée System V (qui nous concerne) et celle de BSD. Vous ne verrez que la première.
Schéma de démarrage de deuxième niveau :
1. INIT exécute le script /etc/rc.d/rc.sysinit (rcS chez Ubuntu), établit les chemins d’exécution par défaut, initialise le swap, vérifie les systèmes de fichiers, etc.
2. INIT utilise le mécanisme Upstart, s’appuyant sur les principes de « jobs » (tâches) situées dans le répertoire /etc/event.d. Il exécute alors le script /etc/event.d/rc-default pour déterminer le niveau d’exécution et les tâches associées.
3. INIT exécute tous les scripts pour le niveau d’exécution par défaut.
4. INIT exécute /etc/rc.d/rc.local.
5. À la fin le programme login est lancé.
Rappel :
Vous avez à votre disposition rc.local pour ajouter des commandes à lancer au démarrage du système : lorsque vous avez des scripts d’environnement pour tous les utilisateurs, vous pouvez utiliser le répertoire /etc/profile.d (fichier profile sous Debian) qui comme son nom l’indique contient les scripts généraux utilisés pour l’environnement du système ; c’est quelquefois préférable aux modifications du bash_profile de chaque utilisateur ; les scripts contenus dans chaque niveau rc, pointent (car ce sont des liens) vers init.d ; la lettre K indique l’argument de démarrage stop alors que S indique l’argument start (les nombres correspondent à l’ordre d’exécution).
On arrête le système en lançant la commande init 0, c’est-à-dire en revenant au niveau zéro, qui est le niveau d’arrêt du système. Il est toutefois préférable d’utiliser d’autres commandes (init 0 est un peu brutal car il n’avertit pas les utilisateurs connectés).
La commande normale pour arrêter un serveur est shutdown (voir le manuel en ligne pour plus de détails) avec par exemple :
# pour un arrêt immédiat du système et de la machine
shutdown -h now
# pour un arrêt dans 5 minutes
shutdown +5
D’autres commandes sont également possibles :
halt ;
les touches [Ctrl]+[Alt]+[Suppr] ;
reboot pour un redémarrage.
2. Utilisation du chargeur de démarrage GRUB
Déjà vu par ailleurs, vous passez cette partie.
TODO
a. La notation des partitions par GRUB
Déjà vu par ailleurs, vous passez cette partie.
TODO
b. Cas particulier : le mode rescue
Déjà vu par ailleurs, vous passez cette partie.
TODO
3. Intégration de la machine cliente au réseau
Deuxième étape dans l’agrandissement de votre réseau : l’installation des deux clients. Ils auront le même nom : CLIENT(##komo##Donner un nom différent pour les machines). Et surtout, les installations s’effectueront dans l’ordre suivant : d’abord le système Windows et ensuite Linux ; car si Linux admet qu’il puisse y avoir d’autres systèmes en ce monde, Windows pas du tout…donc il faudra en tenir compte au moment de son installation.
Le chargeur de démarrage GRUB détectera la présence d’un système précédemment installé. La configuration réseau (IP, masque, DNS…) sera la même pour les deux clients, ceci ne posant pas de problème car chaque client est démarré de façon exclusive.
Schéma du réseau VIRTUALIX avec le(s) client(s)
a. Création de la machine virtuelle (si utilisation VMware Server)
Dans le cas d’utilisation du logiciel VMware, créez une machine virtuelle avec un choix d’OS de type Windows (choix laissé à votre convenance), acceptez la mémoire par défaut (512 Mo maximum, d’où la préférence pour XP Pro au lieu de Vista), une capacité de disque dur de 16 Go (de préférence avec une allocation immédiate du disque dur), une carte réseau sur VMnet4 et pas de lecteur de disquettes, ni d’USB.
Info(s) : Caractéristique de la VM
OS : XP Pro
RAM = 128 Mo
DD = 3 Go
Réseau : une interface réseau sur VMnet4
b. Installation du client Windows (XP professionnel ou Vista)
Note(s) :
Bien sur si vous avez une VM Windows XP fonctionnelle, il est préférable de l'utiliser que d'en créer une ex nihilo. Toutefois vous devez respecter le plan d'adressage.
L’installation du système Windows étant triviale (au sens de banale…), nous ne nous étendrons pas sur le sujet. Spécifiez cependant (en rapport avec notre modèle) les paramètres du réseau ci-dessous :
Adresse IP : 192.168.4.10
Masque de sous-réseau : 255.255.255.0
Passerelle : 192.168.4.254
DNS : 192.168.254.2 (cas VMware)
Nom de machine : clwin
L’installation d’un système Windows ne posant (théoriquement) pas de problèmes, je vous laisse le soin d’en définir vous-même les modalités.
⇒ Effectuez une installation classique de la station en respectant cependant les points suivants :
N’installez pas Windows sur la totalité du disque. Comme vous êtes en situation de test, vous pouvez créer une partition sur la moitié de votre disque avec un minimum de 8 Go en NTFS (Windows XP PRO, un peu plus pour Windows VISTA) et y installer le système.
Une fois le système installé, procédez à l’installation des outils VMware.
ATTENTION :
Vous ne pouvez en aucun cas utiliser Windows XP Edition familiale car ce système ne peut en aucun cas joindre un domaine. Le démarrage d’une session Windows dans une machine virtuelle s’effectue par [Ctrl][Alt][Ins].
Dans la console DOS, menus Démarrer - Exécuter - cmd, procédez à la vérification de la configuration réseau par la commande ipconfig /all :
Résultat de la commande ipconfig sur le client Windows
⇒ Testez la bonne marche du serveur SRVLAN en effectuant dans l’ordre des commandes ping :
sur l’interface en VMnet4 de SRVLAN : ping 192.168.4.254 (vérification de la connexion inter-machines) ;
sur l’interface en VMnet8 de SRVLAN : ping 192.168.254.3 (vérification de la fonction de routage du serveur) ;
sur la passerelle VMware (ou physique) : ping 192.168.254.2 (vérification de la fonction NAT du serveur) ;
sur une adresse Internet n VMnet4 de SRVLAN : ping www.google.fr (vérification de la résolution DNS).
Si l’une des étapes ne fonctionne pas, reprenez les points concernés au niveau de la configuration réseau du serveur.
⇒ Procédez ensuite à l’installation des mises à jour, notamment celles concernant les services pack et les sécurités (##komo## optionnelle).
c. Installation du client Linux Ubuntu
Le client Linux va recevoir un système Ubuntu Desktop plus adapté à la configuration d’un poste de travail. La particularité de cette version d’Ubuntu est qu’elle se présente en système LIVE : vous démarrez sur le CD-Rom et vous avez un système Linux à votre disposition sans que cela influe sur le système déjà présent sur le disque dur. Lorsque vous quittez le système Linux en LIVE, vous retrouvez votre machine comme elle était auparavant… Ce type d’outil s’utilise principalement pour tester une configuration, un système, etc. Parallèlement, Ubuntu propose aussi l’installation sur le disque dur via une interface graphique.
Info(s) : Caractéristique de la VM
OS : Ubuntu Desktop (ou Debian avec interface graphique)
RAM = 256 Mo
DD = 3 Go
Réseau : une interface réseau sur VMnet4
Note(s) :
Bien sur si vous avez une VM Ubuntu Desktop (ou une Debian avec interface graphique) fonctionnelle, il est préférable de l'utiliser que d'en créer une ex nihilo. Toutefois vous devez respecter le plan d'adressage.
⇒ Téléchargez et gravez l’image ISO du CD-Rom (ou DVD-Rom) Ubuntu 9.04 Desktop (i386) de nom ubuntu-9.04-desktop-i386.iso sur le site officiel de la distribution Ubuntu (##komo## Télécharger la version la plus récente).
(##komo## L’installation du système Ubuntu a déjà fait l'objet d'un TP, nous ne reviendrons pas dessus.) Spécifiez cependant (en rapport avec notre modèle) les paramètres du réseau ci-dessous :
Adresse IP : 192.168.4.20
Masque de sous-réseau : 255.255.255.0
Passerelle : 192.168.4.254
DNS : 192.168.254.2 (cas VMware)
Nom de machine : clitux
Une fois le système installé, procédez à l’installation des outils VMware.
⇒ Effectuer une installation classique de la station.
⇒ Configurer le réseau dans le fichier /etc/network/interfaces :
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.4.20
netmask 255.255.255.0
gateway 192.168.4.254
⇒ Configurer le fichier /etc/resolv.conf pour la résolution de nom :
nameserver 192.168.254.2
⇒ Ouvrir une console et procédez à la vérification de la configuration réseau par la commande ifconfig :
mohamed@clitux:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:0c:29:a3:41:52
inet addr:192.168.4.20 Bcast:192.168.4.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fea3:4152/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1490 Metric:1
RX packets:14113 errors:0 dropped:0 overruns:0 frame:0
TX packets:7423 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:15302124 (15.3 MB) TX bytes:783724 (783.7 KB)
Interrupt:19 Base address:0x2000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1173 errors:0 dropped:0 overruns:0 frame:0
TX packets:1173 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:93816 (93.8 KB) TX bytes:93816 (93.8 KB)
⇒ Ouvrir une console et procédez à la vérification de la table de routage :
mohamed@clitux:~$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 192.168.4.254 0.0.0.0 UG 0 0 0 eth0
⇒ Testez la bonne marche du serveur SRVLAN en effectuant dans l’ordre des commandes ping :
sur l’interface en VMnet4 de SRVLAN : ping 192.168.4.254 (vérification de la connexion inter-machines) ;
sur l’interface en VMnet8 de SRVLAN : ping 192.168.254.3 (vérification de la fonction de routage du serveur) ;
sur la passerelle VMware (ou physique) : ping 192.168.254.2 (vérification de la fonction NAT du serveur) ;
sur une adresse Internet n VMnet4 de SRVLAN : ping www.google.fr (vérification de la résolution DNS).
Si l’une des étapes ne fonctionne pas, reprenez les points concernés au niveau de la configuration réseau du serveur.
⇒ Procédez ensuite à l’installation des mises à jour, notamment celles concernant la sécurité (##komo## optionnelle).
4. Simulation de pannes au démarrage
Déjà vu par ailleurs, vous passez cette partie.
TODO
a. Simulation de panne n°1 : plus d’accès à Windows
Déjà vu par ailleurs, vous passez cette partie.
TODO
b. Simulation de panne n°2 : plus d’accès à Linux
Déjà vu par ailleurs, vous passez cette partie.
TODO
D. Installation du service DNS
Base de toutes les reconnaissances de machines, le service DNS se met en place au début afin d’identifier l’ensemble des composants de votre réseau et en faciliter l’accès vers l’extérieur. Il constitue la carte d’identité première de l’entreprise par l’intermédiaire d’Internet. DNS sera identifié et utilisé par les deux clients, indifféremment sous Windows ou sous Linux.
1. Compréhension du système DNS
On ne présente plus le système DNS, hiérarchie de base de données distribuées, destiné à décrire les ordinateurs d’un réseau par la mise en relation d’une adresse IP avec un nom plus facilement reconnaissable pour un humain. On parlera de traduction d’adresses IP. Paradoxalement, chaque client est appelé un “résolveur” alors qu’il ne résout rien mais demande une résolution.
a. Pourquoi DNS est-il nécessaire ?
L’emploi du simple fichier /etc/hosts ne suffit pas pour de grands réseaux et a fortiori pour le réseau des réseaux : Internet. La taille de l’ensemble impose une base répartie de serveurs organisée en structure pyramidale (arbre inversé, la racine se trouvant en haut) pour mémoriser l’ensemble des données.
On nomme serveurs racines (ou “root”) les serveurs dits de premier niveau au nombre de 13, s’occupant des domaines importants comme .com, .net, etc. Chaque serveur (ou nœud) à son niveau s’occupant d’une partie de l’arbre de connaissances pour sa zone.
L’utilisation du service DNS constitue la pierre angulaire de l’administration d’un réseau, il permet l’échange d’informations de beaucoup d’autres services. Sa compréhension est fondamentale aussi ne négligez aucune zone d’ombre. Vous pouvez vous appuyer sur les sites suivants :
le site officiel : http://www.isc.org (en anglais)
une autre adresse de manuel avec surtout un bon index des différentes clauses http://www.zytrax.com/books/dns/
Une auto-formation fournie par l’autorité française AFNIC http://www.afnic.fr/ext/dns/index.html
Vous n’en avez pas fini avec ce service, car un autre chapitre traitera des configurations plus sécurisées.
b. Le vocabulaire DNS
Le domaine inverse : résolution d’une adresse IP en nom de domaine avec l’ajout d’un domaine spécial in-addr.arpa à la fin. Par exemple :
Un réseau 10.1.0.0 et de masque 255.255.0.0 aura pour adresse inverse : 1.10.in-addr.arpa.
Le masque de classe B est volontairement associé à une adresse de classe A afin de montrer de façon claire que c’est le masque de sous-réseau qui détermine (normalement et en IPv4) l’adresse inverse ; voici l’exemple avec une classique adresse de classe C :
Un réseau 192.168.1.0 et de masque 255.255.255.0 aura pour adresse inverse : 1.168.192.in-addr.arpa
La délégation : transfert de responsabilité dans l’administration d’une zone DNS avec autorité pour les serveurs de la zone de la résolution de noms.
Serveur primaire et serveur secondaire : transfert de zones entre serveur maître (primaire) et un autre serveur (secondaire), chacun ayant autorité sur la zone. Vis-à-vis d’un client, l’un ou l’autre répond en fonction de la vitesse du réseau.
Le cache : un serveur utilisant DNS construit sa propre base de données avec les noms résolus. On peut cantonner un serveur uniquement à ce rôle ou à l’inverse l’affranchir complètement dans le cas où celui-ci n’est pas connecté à l’Internet, ou pour d’autres raisons évoquées dans l’activité.
Serveur de type autoritaire : représente officiellement une zone :
maître, serveur principal de conservation des données d’une zone ;
esclave, serveur secondaire copiant ses données à partir du maître ;
stub, idem esclave mais copie uniquement les données du serveur et non les données de l’hôte ; (##komo## chercher info)
distribution, serveur visible uniquement à l’intérieur d’un domaine.
Serveur de type récursif : effectue des requêtes au nom du client jusqu’à la réponse ou l’erreur.
Serveur de type non récursif : renvoie à un autre serveur les requêtes sans réponse.
Les serveurs DNS sous BIND 9 sont généralement récursifs. Vous ne verrez ici que les serveurs maîtres et esclaves et vous transformerez votre serveur DNS principal en non récursif lorsque vous aborderez le mécanisme des vues.
c. Avant l’installation du service
Rappel : on se passe de DNS en utilisant le fichier /etc/hosts de chaque machine. Dans ce cas il faut renseigner la correspondance entre l’adresse IP et le nom de la machine manuellement. Même Windows possède le fichier hosts… Pour Windows XP, il se trouve dans le répertoire C:\WINDOWS\system32\drivers\etc. Sous Linux, il faut de toute façon mettre deux lignes dans le fichier /etc/hosts lorsque l’on implante un service DNS :
La résolution de la zone locale : elle doit déjà y être et il ne faut surtout pas l’enlever !
la propre résolution de la machine dans le domaine DNS d’appartenance ; optionnel pour un client, fortement conseillé pour un serveur.
Exemple pour un serveur DNS de nom ubuntu, de zone testdns et d’IP 192.168.1.1 :
# Fichier /etc/hosts sur le serveur
127.0.0.1 localhost.localdomain localhost
192.168.1.1 ubuntu.testdns ubuntu
Ceci consiste à faire résoudre le nom de la machine par elle-même : en résumé, elle doit connaître son couple IP/nom ! Dans le cas d’un client qui obtient son adresse IP par DHCP, le serveur donne classiquement au client ce genre de renseignement.
Note
D’autres lignes concernant IPv6 sont présentes mais n’en tenez pas compte pour l’instant.
d. Fichiers, structure et contenus
Sur Ubuntu vous utiliserez les fichiers suivants :
le fichier /etc/hosts que l’on vient de voir ;
le fichier /etc/resolv.conf qui indique le domaine à rechercher et le serveur associé ;
le fichier /etc/host.conf qui fixe l’ordre de recherche entre hosts ou bind ;
le fichier /etc/hostname qui contient le nom de la machine ;
le répertoire /etc/bind/ qui contient la configuration générale du serveur DNS avec les fichiers associés ;
les fichiers enregistrements de ressources pour les zones dans /var/cache/bind/.
Ces derniers ont une structure et un rôle. Pour plus de précision revoir le cours R3 : Couche Application Fonctionnalité et Protocoles.
réf : http://www.afnic.fr/ext/dns/html/seq4892.html
2. Installation du DNS
Vous allez mettre en place un service DNS sur le serveur SRVLAN. Il fournira le service DNS principal d’une zone nommée virtualix.local car au début votre entreprise ne dispose pas de son nom de domaine propre. L’extension .local ne portera pas à confusion vis-à-vis des serveurs DNS racines.
Ce service DNS se substituera au DNS externe que vous aviez utilisé par VMware ou par une configuration personnelle.
a. Installation du paquetage et fichier de configuration générale
⇒ Installez le paquetage DNS ou BIND sous Ubuntu et ses dépendances par aptitude :
[root]# aptitude install bind9
Le service DNS démarre automatiquement à la fin de l’installation et d’après une configuration de base située dans les fichiers :
/etc/bind/named.conf : fichier général (incluant les deux fichiers suivants).
Ce fichier contient quatre zones particulières faisant référence à la zone de la boucle locale suivant la spécification RFC 1912 et dont l’utilité est de traiter les requêtes accidentelles (ou usurpées) pour le broadcast ou les adresses locales. Il contient également le fichier des serveurs racines (db.root) car n’oubliez pas que le service s’intègre dans une hiérarchie.
/etc/bind/named.conf.options : fichier contenant les options de BIND9.
/etc/bind/named.conf.local : fichier contenant votre zone (vide pour l’instant).
je vous conseille fortement de sauvegarder ces trois fichiers afin de pallier toute mauvaise manipulation :
[root]# cd /etc/bind/
[root]# cp named.conf named.conf.sauv
[root]# cp named.conf.options named.conf.options.sauv
[root]# cp named.conf.local named.conf.local.sauv
Remplissez le fichier /etc/bind/named.conf.local avec vos zones :
Fichier /etc/bind/named.conf.local
// Les zones
zone "virtualix.local" IN {
type master;
file "db.virtualix.local";
allow-update { none; };
};
zone "4.168.192.in-addr.arpa" IN {
type master;
file "rev.virtualix.local";
allow-update { none; };
};
Explications
L’emplacement de tous les fichiers de zones se détermine à partir du répertoire de référence donné comme option : /var/cache/bind, avec la directive directory dans le fichier named.conf.options.
Pour information et par défaut sous BIND9, la directive auth-nxdomain à yes dans le fichier named.conf.options ne s’utilise qu’avec de vieux clients (directive supplémentaire has-old-clients).
BIND9 utilise rndc pour pouvoir administrer en ligne de commande le démon bind9 à partir du serveur lui-même ou d’un hôte distant. Cet outil se base sur une clé secrète partagée et accordant des privilèges aux hôtes (ici en local par controls). Vous la retrouverez plus tard dans le chapitre orienté sur la sécurité.
L’instruction allow-update { none; } n’autorise pas de mise à jour dynamique du DNS par d’autres machines.
b. Construction des fichiers de zones
Vous trouverez dans les fichiers ci-dessous une référence à l’arobase soit @. Ce symbole indique un raccourci pour désigner le nom de la zone actuelle spécifié dans l’instruction zone du fichier /etc/bind/named.conf. Pour plus d’explications sur les informations portées, reportez-vous à une documentation spécifique au DNS (cf http://www.afnic.fr/ext/dns/html/seq4892.html). Il serait trop long (et pas en rapport avec le but de l’activité) d’expliquer tous les arcanes du DNS.
⇒ Créez le fichier pour la zone directe pour vos machines :
Fichier /var/cache/bind/db.virtualix.local
; Fichier pour la résolution directe
$TTL 86400
@ IN SOA srvlan.virtualix.local. root.virtualix.local. (
2009060101
1w
1d
4w
1w )
@ IN NS srvlan.virtualix.local.
srvlan IN A 192.168.4.254
cliwin IN A 192.168.4.10
clitux IN A 192.168.4.20
⇒ Créez ensuite le fichier pour la zone inverse :
Fichier /var/cache/bind/rev.virtualix.local
; Fichier pour la résolution inverse
$TTL 86400
@ IN SOA srvlan.virtualix.local. root.virtualix.local. (
2009060101
1w
1d
4w
1w )
@ IN NS srvlan.virtualix.local.
254 IN PTR srvlan.virtualix.local.
10 IN PTR cliwin.virtualix.local.
20 IN PTR clitux.virtualix.local.
Notez que le numéro de série se compose de la date du jour du fichier lors de la rédaction de ces lignes, à “l’envers” et accolée à un numéro d’index de départ. Ce numéro d’index sert pour les échanges avec un serveur secondaire.
Info(s) :
A verifier :
$TTL, permet de définir, en secondes et dans un intervalle qui va de 0 à 2147483647, soit, si je ne me trompe pas dans mes calculs, près d'une dizaine d'années, le délai maximum pendant lequel un enregistrement pourra être gardé en cache. Avec 86400, le cache sera vidé, et les fichiers relus, toutes les 24 heures.
1w 1d 4w 1w
1w ; Refresh
1d ; Retry
4w ; Expire
1w ; Minimum
Refresh — This is the number of seconds between update requests from secondary and slave name servers.
Retry — This is the number of seconds the secondary or slave will wait before retrying when the last attempt has failed.
Expire — This is the number of seconds a master or slave will wait before considering the data stale if it cannot reach the primary name server.
Minimum — Previously used to determine the minimum TTL, this is used for negative caching. This is the default TTL if the domain does not specify a TTL.
⇒ Attribuez (vérifiez aussi la même appartenance du groupe pour le répertoire par ls -ld /etc/bind) ces deux fichiers de zones au groupe bind afin de les rendre accessibles au démon par :
[root]# chgrp bind /var/cache/bind/*
[root]# chmod 664 /var/cache/bind/*
c. Démarrage et tests du service
⇒ Vérifiez le fichier /etc/hosts qui ne doit contenir (laissez en plus les lignes pour IPv6) que la référence à la boucle locale et le nom de l’hôte pleinement qualifié (ou FQDN pour Fully Qualified Domain Name) pour le serveur :
127.0.0.1 localhost.localdomain localhost
192.168.4.254 srvlan.virtualix.local srvlan
⇒ Modifiez le fichier /etc/resolv.conf pour qu’il contienne les lignes suivantes :
domain virtualix.local
search virtualix.local
nameserver 192.168.4.254
Rappel : la directive domain fixe le domaine courant, search fait ajouter le domaine virtualix.local par défaut aux demandes avec un nom d’hôte non entièrement qualifié. Ensuite votre serveur DNS sera interrogé.
⇒ Lancez l’utilitaire de vérification named-checkconf (si c’est bon il ne retourne rien) qui vérifie par défaut le fichier /etc/bind/named.conf.
⇒ Lancez le deuxième utilitaire de vérification named-checkzone sur vos fichiers de zone, exemple :
[root]# cd /var/cache/bind/
[root]# named-checkzone -d virtualix.local db.virtualix.local
Cette commande retourne normalement :
loading "virtualix.local" from "db.virtualix.local" class IN
zone virtualix.local/IN: loaded serial 2009060101
OK
⇒ Ouvrez sur une autre console par la combinaison [Alt] [F2], connectez-vous en tant que root et lancez la commande permettant de voir en temps réel le fichier de logs général :
[root]# tail -f /var/log/syslog
⇒ Revenez sur la première console cette fois par [Alt] [F1] et relancez (vérifiez par sysvconfig son démarrage automatique au démarrage du serveur) le service bind9 par :
[root]# /etc/init.d/bind9 restart
Déjà vous devez voir sur la première console si le service a démarré (Stopping puis Starting domain name service) ou s’il indique des erreurs : examiner dans ce cas les lignes incriminées (on oublie souvent les points…). Autre possibilité : voir sur la deuxième console les lignes concernant le service BIND9 et notamment celle contenant le mot-clé running, mais ce n’est pas forcément un gage de réussite…
Feb 27 04:05:27 srvlan named[5495]: zone 0.in-addr.arpa/IN: loaded serial 1
Feb 27 04:05:27 srvlan named[5495]: zone 127.in-addr.arpa/IN: loaded serial 1
Feb 27 04:05:27 srvlan named[5495]: zone 4.168.192.in-addr.arpa/IN: loaded serial 2009060101
Feb 27 04:05:27 srvlan named[5495]: zone 255.in-addr.arpa/IN: loaded serial 1
Feb 27 04:05:27 srvlan named[5495]: zone virtualix.local/IN: loaded serial 2009060101
Feb 27 04:05:27 srvlan named[5495]: zone localhost/IN: loaded serial 2
Feb 27 04:05:27 srvlan named[5495]: managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found
Feb 27 04:05:27 srvlan named[5495]: managed-keys-zone ./IN: loaded serial 0
Feb 27 04:05:27 srvlan named[5495]: running
d. Vérification plus approfondie
Un bon administrateur ouvre toujours une deuxième console afin d’y surveiller les journaux de logs, donc gardez la numéro deux ouverte. Sur le serveur vous allez utiliser deux outils de vérification du service DNS : host et dig. Ces deux outils s’installent par le paquetage logiciel dnsutils. Pour les “Linuxiens” avertis, nous avons volontairement passé sous silence l’outil nslookup, plus ancien et moins souple que dig (domain information groper). Ce choix peut ne pas être le vôtre…
⇒Tapez les commandes :
[root]# aptitude install dnsutils
[root]# host -v srvlan.virtualix.local
La sortie écran est assez longue : elle doit vous montrer les différentes questions (QUESTION SECTION) au service DNS et les bonnes réponses pour les enregistrements conformes à vos fichiers de configuration.
⇒ Tapez la commande
[root]# dig SOA virtualix.local.
; <<>> DiG 9.7.2-P3 <<>> SOA virtualix.local.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55539
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;virtualix.local. IN SOA
;; ANSWER SECTION:
virtualix.local. 86400 IN SOA srvlan.virtualix.local. root.virtualix.local. 2010022701 604800 86400 2419200 604800
;; AUTHORITY SECTION:
virtualix.local. 86400 IN NS srvlan.virtualix.local.
;; ADDITIONAL SECTION:
srvlan.virtualix.local. 86400 IN A 192.168.4.254
;; Query time: 8 msec
;; SERVER: 192.168.4.254#53(192.168.4.254)
;; WHEN: Sun Feb 27 04:15:23 2011
;; MSG SIZE rcvd: 111
⇒ Vérifiez enfin la résolution DNS interne et externe avec :
votre zone par un ping sur srvlan.virtualix.local ;
votre client par un ping sur cliwin.virtualix.local (pensez à désactiver le pare-feu sur le client Windows !) et sur clitux.virtualix.local ;
l’extérieur par un ping sur www.google.fr par exemple.
Que faire en cas d’erreur ?
L’erreur la plus fréquente est que vous n’arrivez pas à contacter le serveur DNS pour une raison X, dans ce cas le message de retour peut être :
;;connection time out; no servers could be reached
Pas de panique ! Il est rare de réussir une configuration DNS du premier coup… Dans ce cas, reprenez depuis le début l’activité en contrôlant plus soigneusement la présence, les noms et les droits des fichiers de configuration. Neuf fois sur dix le problème se situe au niveau de la syntaxe des fichiers : un point-virgule manquant, etc.
e. S’appuyer sur un DNS externe
Votre DNS fonctionne mais vous allez le rendre plus performant. Actuellement, il s’occupe des résolutions de la zone virtualix.local mais aussi des résolutions externes pour les machines de votre réseau et construit donc son cache. Notez que pour tout ce qui concerne les demandes de résolutions externes (par le biais de la récursivité comme par exemple google.fr), la tâche est dévolue aux serveurs racines (fichier /etc/bind/db.root) ce qui n’est pas a priori leur travail… De façon à réduire la charge de travail de votre DNS (et surtout des autres), vous pouvez faire en sorte que cette seconde tâche soit dévolue au serveur DNS “au-dessus de lui”.
⇒ Commentez les lignes ayant trait aux serveurs racines dans le fichier /etc/bind/named.conf (##komo## sur Debian c'est dans le fichier /etc/bind/named.conf.default-zones) de façon à ce qu’il ne puisse plus les “importuner” :
// Référence aux serveurs racines
//zone "." {
// type hint;
// file "/etc/binc/db.root";
//};
⇒ Modifiez les lignes suivantes dans le fichier /etc/bind/named.conf.options :
options {
directory "/var/cache/bind";
forward only;
forwarders { 192.168.254.2; };
auth-nxdomain no;
allow-recursion { localnets; };
listen-on-v6 { any; };
};
Ceci demande quelques explications :
La résolution d’une adresse extérieure pour le serveur et pour les clients s’effectue à l’aide des instructions forward et forwarders (le serveur DNS de VMware ou celui d’un réseau physique).
L’instruction forward only construit son cache et envoie ses requêtes en premier à un transmetteur désigné par l’instruction forwarders. De cette façon, toutes les requêtes ne concernant pas votre zone seront dirigées obligatoirement vers l’extérieur et cela permet de ne pas surcharger le serveur (il est aussi possible d’indiquer forward first).
On autorise la possibilité de récursivité uniquement pour les réseaux locaux (interfaces du serveur) par l’instruction allow-recursion.
Positionnez à no pour l’utilisation de resolvconf (paquet logiciel chargé de gérer les multiples serveurs DNS) dans le fichier /etc/default/bind9 :
Relancez les services réseau et DNS et testez à nouveau une résolution externe à partir du serveur SRVLAN, la résolution devrait être plus rapide…
3. Tests à partir des clients
Client Windows
⇒ Démarrez le client Windows et changez le DNS dans la connexion au réseau local par 192.168.4.254, soit l’adresse de la passerelle et maintenant serveur DNS pour le réseau local.
⇒ Entrez un ipconfig /all dans une console DOS (menu Démarrer, ligne Exécuter, tapez cmd) pour vérifier.
⇒ Toujours dans la console vous pouvez saisir : nslookup virtualix.local, ce qui vous retourne le nom du serveur qui vous a répondu, c’est-à-dire srvlan (sous Windows on utilise nslookup…).
⇒ Dans une console DOS, faites un ping sur srvlan.virtualix.local.
⇒ Lancez Internet Explorer et vérifiez la possibilité d’aller sur Internet.
Client Ubuntu
⇒ Démarrez le client Ubuntu et changez de la même façon le DNS dans l’application Network Manager par un clic droit sur l’icône (deux ordinateurs en haut à droite), ligne Modifications des connexions, onglet Filaire, ligne Connexion filaire, bouton Modifier, onglet Paramètres IPv4.
⇒ Installez dnsutils.
⇒ Effectuez par dig la même vérification que celle du serveur.
⇒ Lancez le navigateur Firefox et vérifiez la possibilité d’aller sur Internet.
Simulation de panne
C’est très simple : il suffit d’arrêter le service BIND sur SRVLAN :
[root]# /etc/init.d/bind9 stop
Note(s)
Vous devez aussi redémarrer les clients pour effacer le cache DNS. N’oubliez pas non plus de relancer le service…
E. Service DHCP et DNS dynamique
DHCP constitue la suite logique au DNS dans l’élaboration d’un réseau. Cela ne concerne bien sûr que les ordinateurs sur notre réseau local. La règle étant de pouvoir s’affranchir de toutes les contraintes d’une configuration IP fixe. Le serveur DHCP donne le “la” en transmettant adresse IP, adresse du serveur passerelle, du serveur de temps, etc.
1. Principes de fonctionnement
Historiquement BootP (Boostrap Protocol) a été le premier protocole de configuration complet. Il est devenu la base du protocole DHCP qui fonctionne sur les mêmes ports que BootP : UDP 67 et 68.
Le principe de base consiste à affecter dynamiquement une adresse IP à chaque client avec différents paramètres tels que serveur DNS, passerelle par défaut, etc. Cette allocation possède une durée limitée : le bail, renouvelé suivant un intervalle défini. De son côté, le client libère cette adresse quand la session se termine.
L’inconvénient majeur repose essentiellement sur la surcharge du réseau car le protocole utilise des trames de broadcast (diffusion multiple) pour rechercher le serveur DHCP sur le réseau. En cas de demandes simultanées, comme par exemple tous les PC d’une entreprise s’allumant le matin entre 8h et 9h, le réseau saturera si l’équipement n’a pas été prévu pour (sous-réseau, débit de l’équipement physique…).
a. Détails sur la demande de bail
À partir de la moitié environ de la durée du bail, le client cherchera à renouveler son bail directement auprès du serveur. Ceci entraîne deux choses :
il ne faut pas poser une durée de bail trop courte sous peine de hausse du trafic réseau ;
la plupart du temps le client conserve la même adresse.
Un peu avant la fin (7/8ème de la durée) et en cas d’échec le client renouvelle sa demande mais cette fois-ci sur le réseau.
Vous trouverez plus de renseignements sur l’Internet, comme par exemple à l’adresse : http://www.frameip.com/dhcp/.
b. Explications complémentaires (RFC 1541/2131)
Le message DHCPNAK est émis du serveur au client et indique que la notion d’un client pour les adresses réseau est incorrecte, (par exemple lors du déplacement d’un client sur un nouveau sous-réseau ou en cas d’expiration du bail). Si la requête du client est invalide (toujours par exemple en cas de changement de sous-réseau), les serveurs DEVRAIENT répondre par un message DHCPNAK au client. Les serveurs NE DEVRAIENT PAS répondre si l’exactitude de leurs informations n’est pas garantie. Par exemple, un serveur qui identifie une requête pour une affectation périmée et détenue par un autre serveur NE DEVRAIT PAS répondre avec un DHCPNAK à moins que les serveurs n’utilisent un mécanisme explicite pour maintenir une cohérence entre les serveurs. Comme votre serveur DHCP sera le seul officiel sur votre réseau, on peut le déclarer en serveur autoritaire.
Cette notion de serveur autoritaire répond au problème de plusieurs serveurs DHCP sur le même réseau physique mais avec des configurations logiques différentes.
c. L’agent relais DHCP
Un agent relais DHCP écoute les requêtes d’amorçage DHCP et les transfère à un serveur DHCP. À noter que l’agent relais doit se trouver sur le même segment de réseau que le client DHCP (problème de la requête en adresse de diffusion limitée) mais pas forcément sur celui du serveur car la communication s’établit cette fois avec l’adresse IP. Le relais DHCP s’exécute par la commande dhcrelay. Le paquetage dhcp3-relay installe sur Ubuntu :
le script /etc/init.d/dhcp3-relay ;
le fichier de configuration /etc/default/dhcp3-relay.
Avec pour ce dernier par exemple :
# le serveur relayé, exemple le votre
SERVERS="192.168.4.254"
# écoute les requêtes DHCP sur l’interface du LAN
INTERFACES="eth1"
Dans le réseau Virtualix, vous ne pourrez mettre en œuvre cette configuration, ne disposant pas de structure adaptée c’est-à-dire d’agent relayeur (il faudrait une machine supplémentaire). La mise en place du service ne présente en tout cas pas de difficulté.
2. Installation du service DHCP
Vous allez monter un service DHCP sur le serveur SRVLAN pour les clients du réseau local avec intégration des inscriptions des clients dans le DNS. Cette installation se fera pour et à partir de l’interface eth1, celle branchée sur le LAN (réseau local).
a. Processus d’installation
⇒ Utilisez classiquement aptitude :
[root]#aptitude install dhcp3-server
Vous avez déjà un paquetage DHCP sur votre machine mais il a trait à la notion de client. L’installation provoque une erreur au démarrage du service DHCP car celui-ci n’est pas encore configuré. On peut regretter qu’Ubuntu comme Debian s’obstine à démarrer par défaut les services lors de leur installation…
⇒ Sauvegardez le fichier de configuration par défaut dhcpd.conf :
[root]# cp /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.conf.sauv
Info : Sous Debian
[root]# cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.sauv
⇒ Modifiez le fichier comme suit :
Fichier /etc/dhcp3/dhcpd.conf
ddns-update-style none;
option domain-name "virtualix.local";
option domain-name-servers 192.168.4.254;
# durée du bail par défaut sans demande express du client en secondes
default-lease-time 86400;
# durée du plus long bail possible (7 jours, je vous évite le calcul…)
max-lease-time 604800;
authoritative ;
log-facility local7;
subnet 192.168.4.0 netmask 255.255.255.0 {
# passerelle par défaut soit srvlan
option routers 192.168.4.254;
# masque de sous-réseau
option subnet-mask 255.255.255.0;
# étendue de la plage DHCP
range 192.168.4.11 192.168.4.100;
}
Explications
l’adresse du serveur DNS est passée par adresse IP de préférence (on n’est pas sûr de la résolution à ce stade) ;
l’option domain-name-servers est globale au réseau local et à toutes les étendues, c’est pour cela qu’elle est en “dehors” du subnet; idem pour le nom de domaine ;
l’étendue propose une centaine d’adresses ;
l’instruction log-facility local7 indique un fichier de logs de niveau debug mais toujours dans le gros fichier /var/log/syslog.
⇒ Séparez les logs DHCP de syslog dans un fichier à part nommé dhcpd.log en ajoutant la ligne suivante dans le fichier /etc/syslog.conf (##komo## sous Debian et Ubuntu Desktop c'est dans le fichier /etc/rsyslog.conf) :
local7.* /var/log/dhcpd.log
⇒ Relancez le démon syslog (##komo## sous Debian et Ubuntu Desktop c'est le démon rsyslog) par (la première fois indique une erreur normale sur la non présence du fichier dhcpd.log) :
[root]#/etc/init.d/syslog restart
Info : Sous Debian
[root]#/etc/init.d/rsyslog restart
⇒ Supprimez les lignes d’attribution statique de l’adresse des client 192.168.4.10 et 192.168.4.20 pour le DNS au niveau du fichier db.virtualix.local et rev.virtualix.local (répertoire /var/cache/bind).
⇒ Relancez le service DNS sur SRVLAN
⇒ Éditez le fichier /etc/default/dhcp3-server(##komo## sous Debian c'est le fichier /etc/default/isc-dhcp-server) et modifiez la ligne INTERFACES de façon à indiquer la bonne interface réseau (celle du LAN) :
INTERFACES=“eth1”
⇒ Lancez à nouveau le service DHCP par /etc/init.d/dhcpd3-server start (##komo## sous Debian c'est le fichier /etc/init.d/isc-dhcp-server start).
⇒ Lancez dans une autre console la commande tail -f /var/log/dhcpd.log, vous devez lire les lignes concernant le service.
b. Vérification de l’attribution d’adresse
Sur le client Windows
⇒ Positionnez la Connexion au réseau local en DHCP par les Propriétés, Protocole Internet (TCP/IP), bouton Propriétés :
⇒ Revenez sur SRVLAN dans la deuxième console : les requêtes DHCP doivent s’y trouver pour le client (DHCPDISCOVER ou demande du client, DHCPOFFER ou offre du serveur, DHCPREQUEST ou acceptation du client et DHCPACK ou délivrance du serveur) :
Feb 28 22:49:39 srvlan dhcpd: DHCPDISCOVER from 00:0c:29:5f:a9:29 via eth1
Feb 28 22:49:40 srvlan dhcpd: DHCPOFFER on 192.168.4.11 to 00:0c:29:5f:a9:29 (windows) via eth1
Feb 28 22:49:44 srvlan dhcpd: DHCPDISCOVER from 00:0c:29:5f:a9:29 (windows) via eth1
Feb 28 22:49:44 srvlan dhcpd: DHCPOFFER on 192.168.4.11 to 00:0c:29:5f:a9:29 (windows) via eth1
Feb 28 22:49:53 srvlan dhcpd: DHCPDISCOVER from 00:0c:29:5f:a9:29 (windows) via eth1
Feb 28 22:49:53 srvlan dhcpd: DHCPOFFER on 192.168.4.11 to 00:0c:29:5f:a9:29 (windows) via eth1
Feb 28 22:49:53 srvlan dhcpd: DHCPREQUEST for 192.168.4.11 (192.168.4.254) from 00:0c:29:5f:a9:29 (windows) via eth1
Feb 28 22:49:53 srvlan dhcpd: DHCPACK on 192.168.4.11 to 00:0c:29:5f:a9:29 (windows) via eth1
Feb 28 22:49:55 srvlan dhcpd: DHCPREQUEST for 192.168.4.11 from 00:0c:29:5f:a9:29 (windows) via eth1
Feb 28 22:49:55 srvlan dhcpd: DHCPACK on 192.168.4.11 to 00:0c:29:5f:a9:29 (windows) via eth1
⇒ Sur la console DOS du client, tapez ipconfig /all, l’attribution IP est manifeste ainsi que le bail :
Configuration réseau du client
Vous pouvez à ce stade entrer un ipconfig /release suivi d’un ipconfig /renew pour un renouvellement du bail, qui somme toute fournira la même adresse IP car non attribuée entre-temps. Vérifiez également votre accès à Internet.
Sur le client Linux
⇒ Allez dans l’application Network Manager par un clic droit sur l’icône (deux ordinateurs en haut à droite), ligne Modifications des connexions, onglet Filaire, supprimer la ligne Connexion filaire, il ne doit rester que la ligne Auto eth0.
Tapez la commande ifconfig dans une console pour vérifier l’attribution d’adresse et vérifiez votre connexion Internet.
c. Compléments
Les baux attribués se trouvent sur le serveur dans le fichier /var/lib/dhcp3/dhcpd.leases.
On peut si on le désire réserver une ou plusieurs adresses IP de la plage d’adresses dans le cas par exemple d’un cadre muni d’un portable avec un accès privilégié ou d’un serveur d’imprimante.
Exemple de réservation en fonction de l’adresse MAC (en dehors de la plage d’attribution) :
host le_nom {
hardware ethernet 00:A0:78:8E:9E:AA; # exemple
fixed-address 192.168.4.101; # exemple
}
l’exclusion d’adresses IP n’est pas possible comme sur un serveur Windows ; la seule solution consiste à définir plusieurs directives subnet.
3. DNS dynamique
a. Pour Windows
Microsoft a quand même évolué en changeant son système d’identification des machines sur le réseau, passant de la notion de serveur WINS (Windows Internet Naming Service) à celle de DNS. À partir de Windows 2000, les stations de travail du domaine sous DHCP s’enregistrent également automatiquement sur le serveur DNS… Windows. Mais dans le cas d’un serveur Linux ? Il faut procéder à quelques modifications pour que les clients Windows puissent être enregistrés dynamiquement, sinon la résolution inter-clients ne peut se faire.
⇒ Modifiez le fichier /etc/bind/named.conf.local (dans les deux zones) sur SRVLAN afin qu’il accepte des modifications venant … de lui-même mais par le service DHCP (auparavant à none) :
allow-update { 127.0.0.1; };
Ajoutez ou modifiez les lignes ci-dessous au début du fichier /etc/dhcp3/dhcpd.conf (##komo## Sous Debian /etc/dhcp/dhcpd.conf) :
# méthode dynamique pour la mise à jour
ddns-update-style interim;
# autorisation de la mise à jour
ddns-updates on;
# la mise à jour est faite par le serveur DHCP
ignore client-updates;
# mise à jour même en cas d’IP statiques
update-static-leases on;
# admettre aussi les clients inconnus au niveau de l’adresse MAC
allow-unknow-clients;
Ajoutez en plus cette fois-ci à la fin du même fichier :
# donne précisément quel DNS à mettre à jour
zone virtualix.local. { primary 127.0.0.1; }
zone 4.168.192.in-addr.arpa. { primary 127.0.0.1; }
⇒ Relancez les services DNS et DHCP et démarrez le client sous le système Windows
Vous pouvez ouvrir à fins de vérification, le fichier syslog dans la console numéro deux et le fichier logs spécifique à DHCP (/var/log/dhcpd.log) dans la console numéro trois. Notez qu’en cas d’erreur les sorties écran sont suffisamment explicites pour pouvoir les corriger.
Relancez les services DNS et DHCP et démarrez le client sous le système Windows
⇒ Vérifiez l’existence de l’inscription du client au niveau du fichier de logs, vous devez voir apparaître des mentions comme added new forward map et added reverse map.
⇒ Vérifiez l’inscription DNS par la création de deux fichiers de zones supplémentaires (le répertoire doit donc, comme vous avez dû le faire, appartenir au groupe bind) avec l’extension .jnl dans /var/cache/bind.
Note(s)
Attention ! Ces deux fichiers sont au format binaire et donc non lisibles par un éditeur de texte.
⇒ Dernière vérification : sur le serveur, un ping client.virtualix.local doit répondre (par contre on ne peut pas vérifier la résolution entre les clients parce qu’il n’y en a qu’un !).
b. Pour Linux
TODO (pour komo) :
A vérifier : la configuration suivante n'est plus nécessaire pour les machines clientes linux ?
Plus simple que pour Windows, un ajout suffit sur le client (avec les modifications du serveur) au niveau du fichier de configuration DHCP client. Rappel, nous sommes sur le client avec le “super utilisateur”, donc vous utiliserez la commande sudo.
Exemple pour la première commande : sudo vi /etc/dhcp3/dhclient.conf dans une console.
⇒ Modifiez la ligne sur le client Ubuntu dans le fichier /etc/dhcp3/dhclient.conf :
send host-name “clitux.virtualix.local”; (–komo– send host-name “clitux” semble plus juste ??)
⇒ Relancez sur le serveur et dans l’ordre les services bind9 et dhcp3-server.
⇒ Relancez sur le client le service networking :
[root]# sudo /etc/init.d/networking restart
L’inscription s’effectue à la différence de Windows directement dans les fichiers de zone :
$ORIGIN .
$TTL 86400 ; 1 day
virtualix.local IN SOA srvlan.virtualix.local. root.virtualix.local. (
2010022709 ; serial
604800 ; refresh (1 week)
86400 ; retry (1 day)
2419200 ; expire (4 weeks)
604800 ; minimum (1 week)
)
NS srvlan.virtualix.local.
$ORIGIN virtualix.local.
$TTL 43200 ; 12 hours
clitux (##komo## à vérifier) A 192.168.4.14
TXT "0025ef6ab1725ed70b961822de28fe95ea"
$TTL 86400 ; 1 day
srvlan A 192.168.4.254
$TTL 43200 ; 12 hours
cliwin (##komo## à vérifier) A 192.168.4.11
TXT "31864ebce4d911b1269f55d155c6303627"
ATTENTION
Attention ! Si vous avez fait les configurations l’une à la suite de l’autre, le bail du premier peut être encore valide ce qui a entraîné une attribution différente entre les clients… Dans ce cas la résolution DNS du client pose problème. Il faut réduire la durée du bail ou attendre que celui-ci se termine.
cours/activite2/adminseveur/chap2.txt · Dernière modification: 2014/01/27 14:21 par admin
Haut de page
CC Attribution-Noncommercial-Share Alike 3.0 Unported
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0
A PCRE internal error occured. This might be caused by a faulty plugin
