Serveur DHCP

Nous allons prendre une configuration simple, avec une machine GNU/Linux qui va cumuler plusieurs fonctions :

• Passerelle entre le réseau local et l'internet (notre « box » ne sera ici qu'un simple modem ADSL) ;
• firewall ;
• serveur DHCP ;
• serveur DNS. (Pourquoi pas, puisqu'on est dans le luxe…).

• Les clients peuvent être de tout type : Windows, Mac OS, GNU/Linux…
• dans l'exemple, la passerelle est construite avec Debian Lenny.

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 GNU/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.

Sur Debian, ceci se fait très simplement en installant les paquetages dhcp3-common et dhcp3-server. Dans la version Lenny de Debian, nous disposons de la version 3.1.1 du serveur. Il y a un seul fichier de configuration : /etc/dhcp3/dhcpd.conf, que nous pourrons 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.

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 DHCP3-server 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. C'est un vrai serveur DHCP…

Nous n'allons pas monter une usine à gaz, c'est inutile pour un petit réseau domestique et ça n'apporte rien de plus à la compréhension du protocole :

• 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.252 ;
• 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.252. 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.64 et 192.168.0.127 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 placerait 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 renouvèlement 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. Répétons-le, 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).

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 Debian Lenny, il faut éditer le fichier /etc/default/dhcp3-server. 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"

# La ligne qui suit est nécessaire. Elle est en rapport avec
# la mise à jour dynamique du DNS, que nous n'utiliserons pas
# pour l'instant.
ddns-update-style none;

# Ce serveur fait autorité sur le réseau
authoritative;

# Les options globales
option time-servers 192.168.0.252;
option domain-name "maison.mrs";
max-lease-time 3600;
default-lease-time 3600;
option domain-name-servers 192.168.0.252;
option subnet-mask 255.255.255.0;
option routers 192.168.0.252;

# le réseau 192.168.0.0/24, avec la réserve d'adresses dynamiques
subnet 192.168.0.0 netmask 255.255.255.0 {
	range dynamic-bootp 192.168.0.64 192.168.0.127;
}

Cette configuration simplissime va suffire à nos besoins.

Dans ce fichier, il y a des directives, qui sont obligatoires :

• la directive ddns-update-style servira plus tard, ce sera la cerise sur le gâteau, pour ceux qui utilisent BIND 9 (le serveur DNS). Elle indique pour l'instant que nous ne ferons pas de mise à jour dynamique de DNS ;
• Il existe une subtile différence entre les directives max-lease-time et default-lease-time (DHCP est plein de subtilités, pas toujours nécessaires dans un fonctionnement basique), 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 d'être efficient dans notre contexte. Il nous suffit de lancer ou de relancer le serveur :

/etc/init.d/dhcpd restart

Et ça devrait fonctionner.