Serveur DHCP.
Topologie du réseau.
Nous allons prendre une configuration simple, avec une machine Linux qui va cumuler plusieurs fonctions :
- Passerelle entre le réseau local et l'Internet,
- firewall,
- serveur DHCP,
- serveur DNS. (Pourquoi pas, puisqu'on est dans le luxe...)
- Les clients peuvent être de tout type : Windows, Mac OS, Linux...
- dans l'exemple, la passerelle est construite avec Linux Mandrake 9.
Nous allons donc installer sur la passerelle un serveur DHCP. Le DNS est tout à fait optionnel, mais ce serait bien qu'il y soit, il peut même y être déjà, ça n'est absolument pas gênant. S'il n'y est pas encore, vous pourrez le rajouter par la suite.
Les fonctions de passerelle et de firewall ne sont pas non plus fondamentales, nous pourrions nous contenter d'un serveur Linux, non connecté au Net (mais qui peut le plus peut le moins).
Nous pourrions même ajouter un autre serveur au réseau local, chargé du DNS et du DHCP et ne laisser à la passerelle que les fonctions de routage et de firewall.
Installation du serveur DHCP.
Sur Mandrake, ça se fait très simplement en installant les paquetages dhcp-common et dhcp-server. Dans la version 9 de Mandrake, vous disposez de la version 3.0 du serveur. Il y a un seul fichier de configuration : /etc/dhcpd.conf, que vous pourrez configurer avec un éditeur de texte, où à travers l'interface Webmin. Ce que nous aurons à faire est suffisamment simple pour pouvoir le faire à la main.
Configuration du serveur.
Le principe.
Comme nous l'avons vu plus haut, un serveur DHCP, en plus de fournir la configuration IP "de base" (Adresse et masque), peut aussi transmettre un nombre plus ou moins grand de paramètres supplémentaires. Nous aurons donc au moins deux choses à configurer :
- La réserve d'adresses dont le serveur pourra disposer pour les attribuer aux clients,
- les paramètres optionnels à leur communiquer dans la foulée, comme l'adresse d'un DNS et de la passerelle par défaut. Dans le cas d'un réseau domestique; ce sera suffisant, mais il y a beaucoup d'autres options, plus ou moins spécifiques aux divers systèmes d'exploitation.
Nous avons vu qu'un seul serveur DHCP pouvait être utilisé pour plusieurs réseaux logiques interconnectés, pourvu que les interconnexions disposent d'un agent de relais DHCP. Dans un tel cas, le serveur DHCP devra disposer d'au moins une étendue d'adresses IP par réseau logique dont il aura la charge.
En ce qui concerne les options, nous disposons d'une architecture hiérarchique :
- Nous pouvons définir des options globales, qui seront les mêmes pour tous les clients du DHCP, tous sous réseaux confondus,
- nous pouvons définir également des options propres à chaque sous réseau, celles-ci écrasant les options globales, en cas de conflit.
- Si l'on veut aller encore plus loin, sachez que DHCPd peut créer des groupes distincts de machines dans un même sous réseau et même gérer des clients de façon individuelle.
Une configuration basique.
Ce que nous voulons faire.
- Nous avons un seul réseau, avec des IP choisies dans la classe C privée 192.168.0.0, donc avec un masque 255.255.255.0.
- Nous avons donc une passerelle par défaut unique pour tous nos hôtes du réseau, dans l'exemple, ce sera 192.168.0.253.
- Nous disposons enfin d'un DNS, également unique pour tous les hôtes du réseau, il est sur la même machine, à savoir 192.168.0.253. Le "domaine" que nous avons construit sur notre réseau local s'appelle maison.mrs. Il n'a aucune réalité sur le Net, mais ça n'a pas d'importance, puisque c'est un domaine qui ne doit pas être visible depuis le Net.
- Sur la totalité de la classe C disponible, nous allons réserver les
adresses comprises entre 192.168.0.1 et 192.168.0.9 pour les clients du
réseau. Cette plage constituera la réserve d'adresses que le DHCP pourra
fournir aux clients.
Bien entendu, nous aurions pu en mettre plus, mais il faut toujours se garder quelques adresses sous le coude, pour les machines configurées manuellement, comme les serveurs que l'on place sur le réseau. - Un dernier point important, c'est la durée de vie du bail que le DHCP va
attribuer aux clients. L'un des avantages de DHCP, c'est de pouvoir
attribuer une configuration IP qui ne sera valide que dans un laps de temps
donné, à charge pour le client de demander le renouvellement de ce bail
avant chaque expiration. Ce temps de vie pourra aller de quelques minutes à
l'infini, suivant les besoins. Sur un réseau qui évolue peu, le bail peut
être sans problèmes de quelques jours, à quelques semaines, voire
plusieurs mois. Sur un réseau où les hôtes vont et viennent, il sera plus
sage de ne laisser vivre les configurations que quelques heures. Bien
entendu, plus le bail est court, plus le trafic généré par DHCP devient
important et plus la charge du serveur augmente. Ceci dit, ce n'est pas un
argument très significatif sur un réseau ne dépassant pas une dizaine de
clients.
Dans l'exemple, nous utiliserons une heure (3600 secondes).
Note importante.
Le daemon DHCPd écoute par défaut sur toutes les interfaces réseau actives sur le serveur. Ce n'est pas forcément souhaitable, c'est même assez souvent ennuyeux.
Fort heureusement, ce comportement par défaut peut être modifié, mais pas dans le fichier de configuration. Il faut utiliser un paramètre dans la ligne de commande qui va démarrer DHCPd.
Dans le cas de Mandrake, il faut éditer le script /etc/rc.d/init.d/dhcpd. Il est bien documenté et vous trouverez aisément la variable INTERFACES qu'il faut initialiser avec le nom de la ou des interfaces qui doivent êtres écoutées. Dans notre exemple, nous aurons :
INTERFACES="eth0"
Ce que nous écrivons dans dhcpd.conf.
# Les trois lignes qui suivent doivent être présentes # même si pour le moment, elles ne nous servent pas. # Elles concernent la mise à jour dynamique du DNS # que nous verrons plus tard
ddns-domainname "maison.mrs";
ddns-update-style none;
ddns-updates off;
# tous les clients sont acceptés, même si l'on ne connaît pas
# leur adresse MAC.
allow unknown-clients;
# Durée de vie du bail
max-lease-time 3600;
default-lease-time 3600;
# Les options que l'on va refiler aux clients
option domain-name-servers 192.168.0.253;
option domain-name "maison.mrs";
option routers 192.168.0.253;
# La définition du seul "sous-réseau" dont nous disposons
# Avec la plage d'IP à distribuer.
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.1 192.168.0.9;
}
Cette configuration simplissime va suffire à nos besoins, du moins dans un premier temps.
Dans ce fichier, il y a des directives, qui sont obligatoires :
- les directives ddns-xxx serviront plus tard, ce sera la cerise sur le gâteau, pour ceux qui utilisent BIND 9 (le serveur DNS). Elles doivent cependant figurer dans la configuration pour que le démon dhcpd puisse démarrer,
- allow unknown-clients
C'est en principe la configuration par défaut, mais autant le spécifier. Ca veut dire que le DHCP acceptera tous les clients qui feront une requête DHCP. Dans le cas contraire, le serveur ne répondrait qu'aux machines dont il connaît l'adresse MAC. - Il existe une subtile différence entre les directives max-lease-time et default-lease-time, la page "man dhcpd.conf" vous indiquera quelle est cette différence. Contentons nous pour l'instant d'assigner la même valeur aux deux, ici 3600 secondes.
Et des options qui seront dans la pratique, des paramètres de configuration optionnels. Ici :
- domain-name-servers
qui attribuera aux hôtes une adresse de DNS. Dans l'exemple, notre DNS à nous. Si nous n'en avons pas, il faudra ici mettre l'IP du DNS de notre fournisseur d'accès. Eventuellement, nous pouvons spécifier plusieurs DNS. - domain-name
est vraiment optionnel, ça permettra aux clients de savoir dans quel domaine ils sont enregistrés - routers
c'est la passerelle par défaut. Il pourrait y avoir plusieurs routeurs, mais tous les systèmes ne savent pas gérer de façon efficace une information contenant plusieurs passerelles.
Toutes les options qui figurent avant le paragraphe "subnet 192.168.0.0 netmask 255.255.255.0" sont des options globales, il n'y a ici aucune option d'étendue (de sous-réseau) de définie.
Cette configuration doit nous permettre de fonctionner dans notre contexte. Il nous suffit de lancer ou de relancer le serveur :
/etc/init.d/dhcpd restart
Et ça devrait fonctionner.