Systèmes et Technologies Objet

Site
Windows
Linux
C++
Logiciel libres
Divers
Support

Retour accueil

YAGIL

Version en ligne

Téléchargement

Liens

Guide d'installation et de configuration de Linux

Précédent Chapitre 9. Configuration du réseau Suivant

9.2. Configuration du réseau sous Linux

​ La configuration du réseau nécessite donc la configuration du protocole IP et des services TCP,
UDP et ICMP (entre autres). Cette opération se fait en définissant l'adresse IP le masque de sous-
réseau et les routes à utiliser. Vient ensuite la configuration du nom de la machine locale, de son
domaine, des noms de machines qu'elle peut résoudre elle-même et des serveurs de DNS qu'elle
doit utiliser pour les autres noms.

​ Il est quasiment certain que votre distribution dispose d'un outil permettant d'effectuer la
configuration du réseau simplement. Connaissant à présent la signification des termes utilisés dans
les réseaux TCP/IP, vous devriez pouvoir parvenir à une configuration valide relativement
simplement. Il est fortement recommandé de consulter la documentation de votre distribution. Les
commandes de configuration du réseau sont souvent appelées dans les scripts de démarrage de la
machine, ou dans les scripts de changement de niveau d'exécution. Toutefois, il peut être utile de
connaître ces commandes, ne serait-ce que pour comprendre comment votre système fonctionne.
Cette section a donc pour but de vous présenter ces commandes, ainsi que les principaux fichiers
de configuration du réseau utilisés sous Linux.

9.2.1. Configuration statique des interfaces réseau

​ La principale commande permettant de configurer le réseau est la commande ifconfig. Comme son
nom l'indique (« InterFace CONFiguration »), elle permet de configurer les interfaces réseau de la
machine. Il faut savoir qu'il existe plusieurs types d'interfaces réseau. Les plus courants sont les
trois types d'interfaces suivants :

​ l'interface loopback, qui représente le réseau virtuel de la machine, et qui permet aux
applications réseau d'une même machine de communiquer entre elles même si l'on ne
dispose pas de carte réseau ;

​ les interfaces des cartes réseau (que ce soient des cartes Ethernet, TokenRing ou autres) ;

​ les interfaces ppp, plip ou slip, qui sont des interfaces permettant d'utiliser les connexions
sérielles, parallèles ou téléphoniques comme des réseaux.

​ La configuration d'une interface comprend l'initialisation des pilotes nécessaires à son

fonctionnement et l'affectation d'une adresse IP à cette interface. La syntaxe générale que vous
devrez utiliser est la suivante :
ifconfig interface adresse netmask masque up

où interface est le nom de l'interface réseau que vous voulez configurer, adresse est l'adresse IP
que cette interface gérera, et masque est le masque de sous-réseau que vous utilisez. Les interfaces
que vous aurez à configurer seront certainement des interfaces Ethernet, auquel cas vous devrez
utiliser les noms eth0, eth1, etc. dans la commande ifconfig. Si vous désirez configurer l'interface
loopback, vous devrez utiliser le nom d'interface lo.

​ Le paramètre up donné à ifconfig lui indique que l'interface doit être activée. Cela signifie que dès
que la commande ifconfig s'achèvera, votre interface réseau sera active et fonctionnelle. On ne
peut faire plus simple... Bien entendu, il existe le paramètre inverse : down. Ce paramètre s'utilise
tout simplement dans la commande ifconfig avec la syntaxe suivante :
ifconfig interface down

où interface est toujours le nom de l'interface.

​ Un exemple de configuration très classique est le suivant :

ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up

Note : Prenez bien garde, lorsque vous écrivez vos adresses IP, à ne pas rajouter de 0
supplémentaire devant les nombres qui la constituent. En effet, il existe une
convention en informatique qui dit que les nombres préfixés d'un 0 sont codés en octal,
c'est-à-dire en base 8. Il va de soi qu'une adresse IP codée en octal n'utilise pas les
mêmes nombres que lorsqu'elle est exprimée en décimal, aussi éprouveriez-vous
quelques difficultés pour diagnostiquer le non fonctionnement de votre réseau si vous
faisiez cette erreur !

​ Le noyau utilisera par défaut le nombre 255 pour les adresses de broadcast dans les composantes
de l'adresse IP qui ne fait pas partie de l'adresse de sous-réseau. Si vous désirez utiliser une autre
adresse (en général, l'alternative est de prendre l'adresse du sous-réseau), vous devrez utiliser
l'option broadcast adresse dans la commande ifconfig. Cependant, le comportement par défaut
convient à la plupart des réseaux. La commande de configuration donnée en exemple ci-dessus sera
alors :
ifconfig eth0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.0 up

​ Enfin, il est possible d'affecter plusieurs adresses IP à certaines interfaces réseau. C'est en
particulier le cas pour toutes les interfaces réseau classiques, mais bien entendu cela n'est pas
réalisable avec les interfaces de type point à point comme les interfaces des connexions ppp.
Lorsqu'une interface dispose de plusieurs adresses, la première est considérée comme l'adresse
principale de l'interface, et les suivantes comme des alias. Ces alias utilisent comme nom le nom
de l'interface réseau principale et le numéro de l'alias, séparés par deux points (caractère ':'). Par
exemple, si l'interface eth0 dispose d'un alias, celui-ci sera nommé eth0:0. Ainsi, pour fixer
l'adresse d'un alias d'une interface réseau, on utilisera la syntaxe suivante :
ifconfig interface:numéro add adresse netmask masque

où interface est toujours le nom de l'interface, numéro est le numéro de l'alias, adresse est
l'adresse IP à attribuer à cet alias, et masque est le masque de sous-réseau de cette adresse.

​ La commande ifconfig est en général appelée dans les scripts d'initialisation du système, qui ont
été générés par l'utilitaire de configuration réseau de votre distribution. Si vous effectuez un grep
sur « ifconfig » dans le répertoire /etc/rc.d/ (ou /sbin/init.d/, selon votre distribution), vous
trouverez la commande de démarrage du réseau. Il se peut qu'une variable d'environnement soit
utilisée à la place de l'adresse IP que vous avez choisie. Quoi qu'il en soit, vous devez sans aucun
doute avoir les lignes suivantes, qui permettent l'initialisation de l'interface loopback :
ifconfig lo 127.0.0.1 netmask 255.0.0.0 up

9.2.2. Définition des règles de routage

​ La deuxième étape dans la configuration du réseau est la définition des règles de routage. Il est
possible de définir plusieurs règles de routage actives simultanément. L'ensemble de ces règles
constitue ce qu'on appelle la table de routage. La règle utilisée est sélectionnée par le noyau en
fonction de l'adresse destination du paquet à router. Chaque règle indique donc un critère de
sélection sur les adresses, et l'interface vers laquelle doivent être transférés les paquets dont
l'adresse destination vérifie cette règle.

​ La commande utilisée pour définir une route est, chose surprenante, la commande système route.
Sa syntaxe est donnée ci-dessous :
route opération [-net | -host] adresse netmask masque interface

où opération est l'opération à effectuer sur la table de routage. L'opération la plus courante est
simplement l'ajout d'une règle de routage, auquel cas add doit être utilisé. L'option suivante permet
d'indiquer si le critère de sélection des paquets se fait sur l'adresse du réseau destination ou plus
restrictivement sur l'adresse de la machine destination. En général, il est courant d'utiliser la
sélection de toutes les adresses d'un même réseau et de les router vers une même interface. Dans
tous les cas, adresse est l'adresse IP de la destination, que celle-ci soit un réseau ou une machine.
Si la destination est un réseau, il faut indiquer le masque de sous-réseau masque à l'aide de l'option
netmask. Enfin, interface est l'interface réseau vers laquelle doivent être envoyés les paquets qui
vérifient les critères de sélection de cette règle.

​ Par exemple, la règle de routage à utiliser pour l'interface loopback est la suivante :
route add -net 127.0.0.0 netmask 255.0.0.0 lo

​ Cette règle signifie que tous les paquets dont l'adresse de destination appartient au sous-réseau de
classe A 127.0.0.0 doivent être transférés vers l'interface loopback. Cela implique en particulier que
les paquets à destination de la machine d'adresse IP 127.0.0.1 (c'est-à-dire la machine locale) seront
envoyés vers l'interface loopback (ils reviendront donc sur la machine locale).

​ Une autre règle de routage classique est la suivante :

route add -net 192.168.0.0 netmask 255.255.255.0 eth0

​ Elle permet d'envoyer tous les paquets à destination du réseau de classe C 192.168.0.0 vers la
première interface Ethernet. C'est typiquement ce genre de règle qu'il faut utiliser pour faire
fonctionner un réseau local.

​ Il n'est normalement pas nécessaire d'ajouter les règles de routage pour les réseaux auxquel la
machine est connectée. En effet, la configuration d'une carte réseau à l'aide de la commande
ifconfig ajoute automatiquement à la table de routage une règle pour envoyer les paquets à
destination de ce réseau par l'interface réseau qui y est connectée. Cependant, la commande route
devient réellement nécessaire lorsqu'il faut définir les passerelles à utiliser pour l'envoi des paquets
destinés à une machine à laquelle la machine locale ne peut accéder directement. Les règles de
routage faisant intervenir une passerelle sont semblables aux règles de routage vues ci-dessus, à
ceci près que l'adresse IP de la passerelle à utiliser doit être fournie. Pour cela, on utilise l'option gw
(abréviation de l'anglais « Gateway »). La syntaxe utilisée est donc la suivante :
route add [-net | -host] adresse netmask masque gw passerelle interface

où passerelle est l'adresse IP de la passerelle à utiliser pour router les paquets qui vérifient les
critères de cette règle. Les autres paramètres sont les mêmes que pour les règles de routage
classique.

​ Par exemple, supposons qu'une machine soit connectée à un réseau d'adresse 192.168.0.0, et que
sur ce réseau se trouve une passerelle d'adresse 192.168.0.1 permettant d'atteindre un autre réseau,
dont l'adresse est 192.168.1.0. Une machine du réseau 192.168.0.0 aura typiquement les règles de
routage suivantes :
route add -net 192.168.0.0 netmask 255.255.255.0 eth0
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.1 eth0

​ La première règle permet, comme on l'a déjà vu, de communiquer avec toutes les machines du
réseau local. La deuxième règle permet d'envoyer à la passerelle 192.168.0.1 tous les paquets à
destination du réseau 192.168.1.0.
​ Inversement, si la passerelle utilise l'adresse 192.168.1.15 sur le réseau 192.168.1.0, les machines
de ce réseau qui voudront accéder au réseau 192.168.0.0 devront spécifier la règle de routage
suivante :
route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.1.15 eth0

​ Bien entendu, il est nécessaire que toutes les machines des deux réseaux utilisent ces règles de
routage pour que la communication entre les deux réseaux se fasse dans les deux sens.

​ Le problème de ces règles de routage est qu'elles spécifient l'adresse du réseau destination. Il est
évidemment hors de question d'utiliser une règle de routage différente pour toutes les adresses de
réseaux possibles. Il est donc possible de définir ce qu'on appelle une passerelle par défaut, qui
n'est rien d'autre que la passerelle vers laquelle doivent être envoyés tous les paquets qui n'ont pas
vérifié les critères des autres règle de routage. La syntaxe à utiliser pour définir la passerelle par
défaut est plus simple, puisqu'il n'est plus nécessaire de préciser les critères de sélection :
route add default gw passerelle interface

où la signification des paramètres passerelle et interface est inchangée.

​ Ainsi, pour reprendre l'exemple précédent, supposons que la machine 192.168.0.47 dispose d'une
connexion à Internet et soit configurée pour partager cette connexion avec les machines du réseau
local. Pour que toutes les machines du réseau local puisse profiter de cette connexion, il suffit de
demander à ce que tous les paquets qui ne vérifient aucune autre règle de routage soient envoyés à
la passerelle 192.168.0.47. Cela se fait avec la règle de routage suivante :
route add default gw 192.168.0.47 eth0

9.2.3. Définition du nom de la machine

​ La configuration du nom d'un ordinateur n'est pas à proprement parler une opération
indispensable, mais elle permet de le nommer de manière plus conviviale qu'en utilisant son
adresse IP. La commande de base permettant de manipuler le nom de la machine locale est la
commande hostname. Appelée telle quelle, elle renvoie le nom actuel de la machine :
hostname

​ Cette commande permet également de modifier ce nom, simplement avec la syntaxe suivante :
hostname nom

où nom est le nom à utiliser. Il est d'usage de n'utiliser que le nom de la machine, sans son domaine.
Le nom de domaine est déterminé automatiquement par le système à partir des informations issues
de la configuration de la résolution des noms de domaine. Nous verrons cela dans le paragraphe
suivant.

​ Cette commande est donc très simple à utiliser, et elle est en général appelée dans les scripts de
démarrage du système. La plupart des distributions utilisent le fichier /etc/HOSTNAME pour stocker
le nom de la machine. Vous êtes bien entendu libre de choisir le nom que vous voulez pour votre
ordinateur, mais vous devez vous assurer que ce nom est unique dans votre domaine !

9.2.4. Résolution des noms de domaine

​ La commande hostname ne permet de fixer que le nom de la machine locale. Pour les autres
machines du réseau, il faut mettre en place les mécanismes de résolution de noms de domaine.
Comme il l'a déjà été indiqué au début de ce chapitre, il existe deux solutions pour trouver l'adresse
IP d'une machine à partir de son nom : la consultation d'une liste de noms stockée en local, soit
l'interrogation d'un serveur de noms de domaine.

​ Le fichier /etc/host.conf permet de définir le comportement du système lors de la résolution

d'un nom. Sa structure est très simple, puisqu'il y a une option de recherche par ligne. Dans la
plupart des cas, les lignes suivantes sont suffisantes :
order hosts,bind
multi on

​ Elles permettent d'indiquer que la recherche des noms pour leur résolution doit se faire d'abord
localement, puis par appel aux DNS si la recherche précédente a échoué. C'est en général le
comportement désiré. La deuxième ligne permet de faire en sorte que toutes les adresses
correspondant à une machine soient renvoyées. Si l'on avait utilisé l'option multi off, seule la
première adresse IP trouvée aurait été renvoyée.

​ La liste de noms locale est stockée dans le fichier /etc/hosts (cela explique le nom hosts utilisé
pour l'option order dans le fichier /etc/host.conf). Votre ordinateur connaîtra directement
l'adresse IP de toutes les machines référencées dans ce fichier. Il est bon de placer ici une entrée
pour les ordinateurs les plus couramment utilisés sur le réseau. Chaque entrée commence par une
adresse IP, et est suivie de la liste des noms de la machine possédant cette adresse, séparés par des
espaces. Pour ceux qui ne disposent pas de réseau local, ce fichier doit être relativement simple :
seule la ligne affectant l'adresse 127.0.0.1 à la machine locale (appelée « localhost ») doit s'y
trouver.
127.0.0.1 localhost

​ De la même manière, le fichier /etc/networks contient les adresses des réseaux. Ce fichier est
utilisé par la commande route pour donner un nom aux différents réseaux. Chaque entrée est
constituée du nom du réseau, suivi de son adresse IP. Encore une fois, ce fichier se réduit à sa plus
simple expression pour ceux qui n'ont pas de réseau local, puisqu'il ne contiendra tout au plus
qu'une entrée pour le réseau « loopback », sur lequel se trouve l'adresse de retour 127.0.0.1. Cette
entrée aura donc la forme suivante :
loopback 127.0.0.0

​ La configuration des serveurs de noms est en revanche une opération nécessaire si l'on désire
accéder à des machines dont on ne connaît que le nom. Le fichier de configuration utilisé est cette
fois le fichier /etc/resolv.conf. Sa structure est encore une fois très simple, avec une option par
ligne, chaque option étant introduite par un mot clé.
​ Le mot clé domain permet d'indiquer le nom du domaine dont fait partie votre machine. Par
exemple, si votre nom de domaine est « andromede.galaxie », vous devrez utiliser la ligne
suivante :
domain andromede.galaxie

​ Le mot clé search permet quant à lui de spécifier une liste de noms de domaines à ajouter par
défaut aux noms de machines non complètement qualifiés. Les éléments de cette liste doivent être
séparés par des espaces. La recherche d'une machine dont le nom ne comprend pas la partie de nom
de domaine s'effectue en ajoutant au nom de la machine les noms des domaines indiqués ici,
jusqu'à ce que la résolution du nom en adresse IP réussisse. Cette recherche commence bien
entendu par le nom de domaine local, s'il a été défini. Il est donc recommandé d'indiquer votre nom
de domaine dans cette liste de noms de domaines. Par exemple, si votre machine fait partie du
domaine « andromede.galaxie », vous devrez utiliser la ligne suivante :
search andromede.galaxie

​ Ainsi, si vous recherchez l'adresse de la machine « krypton », la requête au DNS se fera avec le
nom complètement qualifié « krypton.andromede.galaxie ». Vous êtes bien entendu libre d'ajouter
d'autres noms de domaines pour le cas où la résolution de nom échouerait sur ce domaine.

​ Enfin, l'option nameserver est essentielle, puisqu'elle permet de donner les adresses IP des
serveurs de DNS auxquels doivent être adressées les requêtes de résolution de noms. Par exemple,
si vous disposez de deux serveurs DNS, un primaire, d'adresse 192.168.0.10, et un secondaire,
d'adresse 192.168.0.15, vous utiliserez la ligne suivante :
nameserver 192.168.0.10 192.168.0.15

​ Cette ligne est évidemment obligatoire, faute de quoi la résolution des noms de machines en
adresse IP échouera pour toute machine qui ne se trouve pas dans votre fichier /etc/hosts.

9.2.5. Utilisation des protocoles DHCP et BOOTP

​ Généralement, la gestion des adresses IP des machines devient rapidement une tâche difficile sur
les grands réseaux, pour trois raisons. Premièrement, il faut toujours s'assurer que chaque machine
dispose bien d'une adresse qui lui est propre, ce qui peut être difficile si l'on ne s'organise pas en
conséquence. Deuxièmement, il faut que les fichiers /etc/hosts de toutes les machines soient à
jour, ce qui nécessite un travail proportionnel au nombre de machines administrées. Enfin, le
nombre d'adresses IP disponibles peut se réduire, ce qui peut devenir gênant à terme.

​ Afin de résoudre ces problèmes de configuration réseau, le protocole DHCP (abréviation de

l'anglais « Dynamic Host Configuration Protocol ») a été défini. Il s'agit d'un protocole qui permet
aux machines connectées sur un réseau d'interroger un « serveur d'adresses » du réseau capable de
gérer une liste d'adresses et de les affecter dynamiquement aux machines du réseau. En fait, ce
protocole permet de fournir plus d'informations que les simples adresses IP, comme par exemple la
route par défaut que les machines doivent utiliser, ainsi que les adresses des serveurs de noms du
réseau.
​ Un autre protocole semblable à DHCP a également été développé dans le but de permettre la
configuration réseau des machines dès leur démarrage : le protocole BOOTP (abréviation de
l'anglais « BOOTstrap Protocol »). Ce protocole est évidemment plus léger que DHCP, mais
permet aux machines d'obtenir dynamiquement leur configuration réseau dès leur démarrage, avant
même que ne soient montés les systèmes de fichiers. Ce protocole est donc particulièrement utile
pour faire démarrer des machines sans disque, pour lesquelles le système de fichiers racine est
monté en NFS.

​ La manière la plus simple de configurer les protocoles DHCP et BOOTP sur un poste client est
d'utiliser les fonctionnalités d'auto-configuration du noyau. Cependant, il est également possible
d'effectuer cette configuration au niveau utilisateur à l'aide de programmes complémentaires. Les
deux sections suivantes décrivent ces deux techniques.

9.2.5.1. Autoconfiguration des clients DHCP et BOOTP

​ La configuration des protocoles DHCP et BOOTP ne comporte aucune difficulté particulière

lorsque l'on utilise les fonctionnalités d'autoconfiguration du noyau. Ces fonctionnalités étant prises
en charge au niveau du noyau, il va vous falloir recompiler un nouveau noyau pour en bénéficier.
Cette opération en revanche est relativement technique, et doit être faite avec soin. La manière de
procéder a été décrite en détail dans la Section 7.3.

​ L'option à activer pour permettre l'utilisation du protocole BOOTP est l'option « IP: kernel
level autoconfiguration » du menu « Networking options ». Cette option vous permettra de
sélectionner le protocole d'auto-configuration réseau que le noyau devra utiliser lors de son
amorçage. Vous devrez alors choisir l'option « IP: DHCP support (NEW) » ou l'option « IP:
BOOTP support (NEW) » pour activer respectivement les protocoles DHCP et BOOTP.

Note : Vous remarquerez qu'il existe également un autre protocole d'auto-

configuration du réseau au démarrage : le protocole RARP. Ce protocole fournit les
mêmes services que le protocole BOOTP, mais est plus ancien. Il n'est donc plus
conseillé de l'utiliser, sauf vous vous trouvez sur un réseau pour lequel seul le
protocole RARP est disponible.

​ Une fois ces options sélectionnées, vous pourrez recompiler votre noyau, l'installer et redémarrer
la machine. Lors du démarrage, le noyau doit chercher un serveur DHCP ou un serveur BOOTP sur
le réseau local pour effectuer la configuration réseau de votre carte réseau.

Note : Vous devrez peut-être également activer les options « NFS file system
support » et « Root file system on NFS » du menu « Network File Systems » si
vous désirez faire démarrer votre machine sur un système de fichiers racine monté en
NFS lors du démarrage.

9.2.5.2. Configuration d'un client DHCP au niveau utilisateur

​ Il est également possible de configurer les clients DHCP au niveau utilisateur, à l'aide de
programmes complémentaires. Comme sur la plupart des machines Unix, le programme à utiliser
est le programme dhclient. Ce programme est généralement lancé dans les scripts de démarrage
des machines, et envoie des paquets de demande de configuration sur le réseau à l'adresse de
diffusion générale 255.255.255.255. Ces paquets sont donc susceptibles d'être captées par toutes les
machines du réseau, mais seuls les serveurs DHCP y répondent. Les réponses obtenues sont alors
analysés par dhclient, qui configure en conséquence l'interface réseau et passe ensuite en arrière-
plan.

​ Les informations envoyées par les serveurs DHCP peuvent être plus ou moins complètes, la base
étant bien sûr l'adresse IP de la machine et son masque de sous-réseau. Il est toutefois possible de
donner plus d'informations, comme par exemple les adresses des serveurs de noms, des routes par
défaut et des passerelles à utiliser.

​ Les adresses IP attribuées aux clients ne sont pas permanentes, car le protocole DHCP est avant
tout destiné à la configuration automatique des postes itinérants ou susceptibles de redémarrer
souvent. Par conséquent, ces adresses sont fournies dans le cadre d'un bail, dont la durée maximum
est fixée par le serveur. Dès que le bail obtenu par un client expire, celui-ci doit chercher à le
renouveler. C'est encore le programme dhclient qui s'en charge. C'est la raison pour laquelle celui-
ci passe en arrière-plan après avoir configuré l'interface pour la première fois : il attend la fin des
baux de la machine sur laquelle il tourne et cherche à les renouveler. Si un client ne renouvelle pas
ce bail (parce qu'il est arrêté par exemple), le serveur DHCP peut réutiliser son adresse IP et
l'affecter à une autre machine. Bien que les serveurs DHCP s'efforcent généralement de conserver
les adresses IP des clients à chaque bail, un client configuré par DHCP ne peut donc pas considérer
que son adresse IP restera toujours la même. C'est la contrepartie de la flexibilité.

​ Si aucun serveur DHCP ne peut être contacté lors du démarrage, dhclient abandonne
temporairement et réessaie au bout d'un temps aléatoire. Au bout d'un certain nombre d'essais non
fructueux, il peut décider de configurer les interfaces réseau avec les adresses IP des anciens baux
obtenus par la machine. Pour cela, il mémorise dans le fichier de configuration
/var/db/dhclient.lease les adresses IP de ces anciens baux. Ce fichier est périodiquement
réécrit avec la liste des adresses des baux valides afin d'éviter qu'il ne se remplisse ad vitam
eternam.

​ Bien entendu, les postes clients ne peuvent pas choisir leurs adresses IP sans vérification d'unicité.
Dans le cas de l'absence de serveur DHCP (et donc d'autorité centrale), les clients qui démarrent
interrogent les machines déjà présentes sur le réseau pour déterminer si l'adresse qu'ils envisagent
de prendre est bien libre. Dans le cas contraire, une autre adresse est essayée, et ainsi de suite.
Ainsi, même en cas de panne de tous les serveurs DHCP d'un réseau, les postes clients peuvent
toujours travailler ensemble sans conflit d'adresses IP.

​ Comme vous pouvez le constater, le comportement de dhclient est relativement complexe et

dépend de nombre de paramètres. Tous ces paramètres peuvent être définis dans le fichier de
configuration /etc/dhclient.conf. Ce fichier contient en particulier les différentes durées
intervenant dans le choix des adresses IP, comme par exemple la durée minimale d'un bail, les
durées entre chaque tentatives de configuration, les informations qui doivent être récupérées des
serveurs DHCP, ainsi que les valeurs par défaut pour ces informations lorsque les serveurs ne les
fournissent pas. Le fichier de configuration dhclient.conf est donc relativement complexe.
Heureusement, dhclient utilise des options par défaut qui conviennent dans la plupart des cas,
aussi est-il fortement probable que votre fichier dhclient.conf soit vide. Si toutefois vous désirez
en savoir plus, vous pouvez consulter la page de manuel dhclient.conf.

​ La configuration DHCP pour les postes clients se réduit donc à l'essentiel : le lancement de
dhclient. Celui-ci s'utilise avec la syntaxe suivante :
dhclient interface0 [interface1 [...]]

où interface0, interface1, etc., sont les interfaces réseau qui doivent être configurées par
DHCP. On ne peut donc pas faire plus simple...

Note : Sous Linux, le programme dhclient utilise les fonctionnalité d'accès direct aux
cartes réseau et de filtrage des paquets. Ces deux fonctionnalités peuvent être activées
dans la configuration du noyau à l'aide des options « Packet socket », « Packet
socket: mmapped IO » et « Socket Filtering » du menu « Networking options ».
L'option « IP: multicasting » de la liste des options du protocole IP devra
également être activée. Le détail de la configuration et de la compilation du noyau a
été vu dans la Section 7.3.

​ Le programme dhclient est assez facétieux depuis quelques versions. S'il refuse
obstinément de fonctionner, vous devrez sans doute vous rabattre vers le programme
dhcpcd, beaucoup plus simple, mais également beaucoup plus fiable. La plupart des
distributions utilisent de dernier en lieu et place de dhclient. Consultez la
documentation de votre distribution pour déterminer la solution qu'elle utilise.

9.2.6. Définition des protocoles de haut niveau

​ Comme nous l'avons vu plus haut, le protocole IP fournit les mécanismes de base pour la
transmission des paquets. Plusieurs protocoles de plus haut niveau ont été définis pour fournir des
services à valeur ajoutée, qui satisfont donc plus aux besoins des applications. Tous ces protocoles
sont encapsulés dans le protocole IP, ce qui signifie que leurs informations sont transmises en tant
que données dans les paquets IP.

​ En réalité, les paquets du protocole IP contiennent un champ permettant de signaler le type de

protocole de haut niveau dont ils transportent les informations. À chaque protocole est donc
attribué un identificateur numérique qui lui est propre, et qui permet aux services réseau
d'interpréter les données des paquets.

​ Tout comme les adresses IP, ces numéros identifiant les protocoles ne sont pas très intéressants
pour les humains, qui leur préfère évidemment le nom du protocole. Certains programmes réseau
utilisent donc ces noms pour identifier les protocoles. Pour leur permettre de faire l'association
entre ces noms et les identificateurs numériques, le fichier /etc/protocols est utilisé.

​ Le format de ce fichier est très simple. Il contient une ligne pour chaque protocole, constituée du
nom du protocole, de la valeur de son identificateur, et des autres noms que ce protocole peut avoir
(c'est-à-dire ses alias). Parmi ces protocoles, les plus importants sont les suivants :

Nom Numéro Alias

ip 0 IP
icmp 1 ICMP
tcp 6 TCP
udp 17 UDP

​ Comme on le voit, le protocole IP dispose lui-même d'un identificateur de protocole (qui vaut 0 en
l'occurrence). Cet identificateur est un identificateur de « pseudo protocole », parce qu'IP est en fait
le protocole de base. ICMP est identifié par le numéro 1, TCP par le numéro 6 et UDP par le
numéro 17. Il existe beaucoup d'autres protocoles, qui ne seront pas décrits ici. Bien entendu, le
fichier /etc/protocols fourni avec votre distribution doit déjà contenir la définition de la plupart
des protocoles.

​ De la même manière, la plupart des ports TCP et UDP sont affectés à des services bien définis, et
certains programmes réseau peuvent chercher à faire la correspondance entre les noms de ces
services et les numéros de ports. Cette correspondance est stockée dans le fichier de configuration
/etc/services.

​ Les informations concernant les services sont données à raison d'une ligne par service. Chaque
ligne suit la syntaxe suivante :
nom port/protocole alias

où nom est le nom du service décrit par cette ligne, port est le numéro du port utilisé par ce service,
protocole est le nom du protocole utilisé par ce service (ce peut être « tcp » ou « udp »), et alias
la liste des autres noms sous lesquels ce service est également connu.

​ Vous trouverez les principaux services dans l'extrait donné ci-dessous :

Service Port/Protocole
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp
pop3 110/tcp
irc 194/tcp
irc 194/udp

​ Comme vous pouvez le constater, ces services n'ont pas d'alias. Ces informations sont données
uniquement à titre d'exemple. Il va de soi que le fichier /etc/services fourni avec votre
distribution contient la définition d'un grand nombre de services, et vous n'aurez en général pas à y
toucher.

9.2.7. Les super-démons inetd et xinetd

​ La plupart des services réseau sont gérés par des programmes qui s'exécutent en permanence et qui
attendent des connexions sur un port TCP ou UDP. Ces programmes consomment relativement peu
de ressources car ils passent la plupart de leur temps à attendre ces connexions. Ils ne se réveillent
que lorsqu'un client se connecte effectivement et leur envoie une requête.

​ Cependant, ils peuvent être relativement nombreux, et si tous les services sont lancés
simultanément, ils peuvent finir par consommer une part non négligeable des ressources système.
C'est pour cette raison que les super-démons inetd (de l'anglais « InterNET Daemon ») et xinetd
(de l'anglais « eXtended INETD ») ont été créés. Ces démons sont à l'écoute des demandes de
connexion des clients pour les autres services réseau, et ne lancent ceux-ci que lorsqu'un client se
connecte sur leurs ports. Une fois lancés, les véritables démons reprennent la main et
communiquent directement avec leurs clients. Ainsi, inetd et xinetd écoutent les ports pour tout le
monde, et sont la plupart du temps les seuls à fonctionner. Les ressources système sont donc
économisées et les services réseau sont démarrés et arrêtés à la demande.

​ Le super-démon xinetd est appelé à remplacer inetd, qui lui est beaucoup plus ancien et nettement
moins souple. En pratique, un seul de ces super-démons doit être démarré sur une machine (il est
inutile de les lancer tous les deux, car les clients ne peuvent se connecter qu'à un seul d'entre-eux
de toutes manières). Les deux sections suivantes décrivent la configuration de ces super-démons.

9.2.7.1. Le super-démon inetd

​ Le super-démon inetd laisse de plus en plus la main au nouveau super-démon xinetd qui est
beaucoup plus puissant, mais reste toutefois très utilisé sur de nombreuses machines. Sa description
n'est donc pas inutile, car toutes les distributions n'utilisent pas encore xinetd.

​ Le super-démon inetd utilise le fichier de configuration /etc/inetd.conf pour déterminer les

ports sur lesquels il doit attendre des connexions de la part des clients, et pour trouver le service
réseau qu'il doit lancer lorsqu'une telle connexion arrive. Ce fichier est structuré en lignes, dont
chacune décrit un des services que le démon inetd prend en charge. Les informations données sur
ces lignes sont les suivantes :

​ le nom du service (tel qu'il est défini dans la première colonne du fichier /etc/services)
dont inetd doit surveiller les requêtes ;

​ le type de canal de communication réseau utilisé, en général « stream » (pour les

communications en mode connecté, donc en général celles qui utilisent le protocole TCP) ou
« dgram » (pour les communications basées sur les datagrammes, donc typiquement les
communications utilisant le protocole UDP) ;

​ le protocole réseau utilisé (« tcp » ou «udp ») par ce service ;

​ l'un des mots clés wait ou nowait, qui permettent d'indiquer si inetd doit attendre la fin de
l'exécution du démon gérant le service ou s'il peut attendre de nouvelles requêtes de la part
des clients ;
 ​ le nom de l'utilisateur au nom duquel le démon gérant ce service doit fonctionner (en
général, c'est l'utilisateur root) ;

​ le chemin sur le fichier exécutable de ce démon ;

​ les éventuels paramètres en ligne de commande pour ce démon, en commençant par

l'argument 0, qui doit toujours être le nom du fichier exécutable du programme lui-même.

​ Par exemple, la ligne suivante permet de lancer le démon telnetd sur toute requête via le protocole
TCP pour le service telnet :
telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd

​ Il est supposé ici que le démon en charge de ce service peut être lancé avec le programme
/usr/sbin/in.telnetd.

​ Le démon inetd est capable de fournir lui-même un certain nombre de services de base, et il n'est
pas nécessaire de fournir un démon pour ces services. Dans ce cas, il faut utiliser le mot clé
internal à la place du nom du fichier exécutable du démon de ce service. Les paramètres doivent
également être remplacés par le mot clé internal.

​ En fait, il est fort peu probable que votre fichier de configuration /etc/inetd.conf définisse les
services comme indiqué dans cette section. En effet, un programme intermédiaire en charge
d'assurer des contrôles de sécurité est souvent intercalé entre inetd et les démons gérant les
services. Nous verrons ce que fait exactement ce programme dans une prochaine section.

9.2.7.2. Le super-démon xinetd

​ Le super-démon xinetd utilise un autre fichier de configuration que celui du super-démon inetd.
Pour xinetd, la définition des services mis à disposition des clients se fait dans le fichier de
configuration /etc/xinetd.conf. Toutefois, contrairement au fichier inetd.conf, le fichier
xinetd.conf peut inclure d'autres fichiers de configuration et référencer des répertoires contenant
les fichiers de configuration spécifiques aux services. Ainsi, la configuration des services est
beaucoup plus modulaire et se fait plus facilement.

​ En pratique, il est d'usage de définir les options par défaut pour tous les services dans le fichier de
configuration /etc/xinetd.conf, et de décrire les différents services dans des fichiers
complémentaires stockés dans le répertoire /etc/xinetd.d/. Ce répertoire est alors inclus
directement dans le fichier xinetd.conf à l'aide de la directive includedir dédiée à cet usage.

​ Les fichiers de configuration de xinetd sont constitués de sections permettant de décrire les
services pris en charge, ou tout simplement les options par défaut applicables à tous les services. La
forme générale de ces sections est la suivante :
service
{
option opérateur valeur [valeur [...]]
option opérateur valeur [valeur [...]]
...
}

où service est le nom du service (ou defaults pour les options par défaut), option est un mot-clé
identifiant une des options de ce service, et opérateur est l'un des opérateurs '=' (pour la définition
de la valeur d'une option ou l'écrasement de sa valeur précédente), '+=' (pour compléter la liste de
valeurs d'une option) ou '-= (pour supprimer une valeur de la liste de valeurs d'une option). Les
valeurs des options peuvent être multiples, et leur nature dépend des options utilisées.

​ Les principales options utilisables dans ces sections sont les suivantes :

Option Signification

​ Identificateur du service, pour le cas où plusieurs sections devraient être définies

pour un même service. Cette possibilité est utilisée lorsque l'on désire fournir des
id options différentes pour un même service. L'entrée choisie (et donc le jeu
d'options choisi) dépend dans ce cas de critères définis par exemple sur
l'interface réseau ou sur les adresses des clients.

​ Permet d'indiquer la nature du service décrit par cette section. Généralement,

cette option n'a pas à être donnée, sauf lorsque l'on veut forcer la méthode
type d'implémentation d'un service. Par exemple, il est possible de donner la valeur
INTERNAL à cette option pour utiliser l'un des services implémentés par xinetd en
interne.

​ Permet de donner le chemin sur l'exécutable du démon prenant en charge le

server
service décrit.

​ Permet de donner les paramètres en ligne de commande du démon prenant en

charge le service. Notez que, contrairement à ce qui se fait avec inetd, il ne faut
server_args généralement pas donner le nom de l'exécutable en premier argument dans cette
option. Cette règle peut toutefois être rendue fausse en ajoutant la valeur
NAMEINARGS dans l'option flags décrite ci-dessous.

​ Le type de canal de communication utilisé (« stream » ou « dgram », comme

socket_type
pour inetd).

​ Le protocole réseau utilisé par le service (« tcp » ou « udp », comme pour

protocol
inetd).

​ Le port sur lequel le service peut être trouvé. Cette option est facultative. Si elle
port
n'est pas indiquée, le numéro de port utilisé sera celui indiqué dans le fichier de
 configuration /etc/services pour le service en cours de configuration.

​ L'indicateur de capacité du démon à gérer plusieurs connexions simultanément.

Les valeurs que l'on peut donner à cette option sont « yes » et « no »,
respectivement pour indiquer que le démon peut gérer plusieurs connexions
wait simultanément ou non. Dans ce dernier cas, le démon xinetd lancera plusieurs
instances du démon gérant le service si plusieurs clients cherchent à se connecter
simultanément. Le nombre maximum d'instance peut toutefois être contrôlé à
l'aide des options instances et per_source décrites ci-dessous.

​ Les paramètres permettant de contrôler différents aspects du service. Les options

les plus courantes sont « IDONLY », qui permet de n'autoriser que les connexions
provenant de machines disposant d'un serveur d'identification des clients,
flags « NORETRY », qui permet d'éviter de réessayer de lancer le démon du service si le
lancement précédent a échoué, et « NAMEINARGS», qui permet d'indiquer que le
nom de l'exécutable doit être spécifié en premier paramètre dans l'option
server_args.

​ Le compte utilisateur dans lequel le démon prenant en charge le service doit être
user lancé. Cette option ne peut bien entendu pas être utilisée pour les services gérés
en interne par xinetd.

​ L'interface à laquelle le service est attaché. Cette option permet de définir

plusieurs configurations pour un même service et d'affecter ces différentes
interface configurations à des interfaces réseau distinctes. Pour l'heure, seul l'adresse IP de
l'interface réseau peut être spécifiée grâce à cette option, ce qui impose d'avoir
des adresses IP fixes.

​ La liste des adresses des machines autorisées à se connecter. Il est possible de

spécifier les adresses IP explicitement ou à l'aide d'une adresse et d'un masque de
sous-réseau. Les noms de domaines peuvent également être utilisés. Dans ce cas,
le nom n'est pas transformé en adresse IP. Au contraire, c'est l'adresse du client
only_from qui est retransformée en nom de machine pour vérifier s'il a le droit de se
connecter. Notez que l'absence de ce champ indique que, par défaut, l'accès est
accordé à toutes les machines (sauf celles explicitement interdites de connexion
par l'option no_access décrite ci-dessous). En revanche, la présence de ce champ
mais sans valeur permet d'interdire l'accès à toutes les machines.

​ La liste des adresses des machines qui n'ont pas le droit de se connecter. Les
adresses peuvent être spécifiées de la même manière que pour l'option
no_access
 only_from. Si une adresse vérifie les critères des deux options only_from et
no_access, c'est l'option dont le critère est le plus précis qui est choisie.

​ La période pendant laquelle le service est accessible. Cette période peut être
access_times exprimée sous la forme d'une liste d'intervalles « heure:minute-
heure:minute ».

​ Permet d'indiquer le nombre maximum d'instances d'un même démon que

instances xinetd peut lancer. Cette option permet donc de spécifier un nombre de
connexions maximum pour chaque service.

​ Permet d'indiquer le nombre maximum d'instances d'un même démon que

xinetd peut lancer pour un même client (identifié par son adresse IP). Cette
per_source
option permet donc de limiter le nombre de connexions d'un client, de manière
indépendante du nombre de connexions total donné par l'option instances.

​ Permet de limiter dans le temps le nombre de connexions entrantes pour un

service, afin d'éviter les attaques par déni de service. Cette option prend deux
cps paramètres, le premier étant le nombre maximum de demandes de connexion par
seconde que xinetd peut accepter. Si ce nombre est dépassé le service est
désactivé pendant le nombre de secondes indiqué par le deuxième paramètre.

​ Permet de désactiver globalement des services, en indiquant leurs noms en

paramètre. Par défaut, aucun service n'est désactivé. Cette option ne peut être
disabled
utilisée que dans la section defaults, car elle permet de désactiver globalement
et rapidement un ensemble de services.

​ Permet de donner la liste des services pris en charge. Cette option fonctionne de
manière similaire à l'option disabled, à ceci près qu'elle fonctionne en logique
inverse. L'absence de cette option implique l'activation de tous les services, sauf
enabled
ceux qui sont listés dans l'option disabled. En revanche, dès que cette option est
définie, seuls les services listés sont démarrés. Tout comme l'option disabled,
cette option ne peut être utilisée que dans la section globale defaults.

​ Permet de désactiver les services de manière unitaire. Cette option est utilisée
dans les sections des services, afin d'indiquer de manière plus fine qu'avec les
options enabled et disabled s'ils doivent être activés ou non. Cette option peut
disable prendre deux valeurs : « yes » ou « no ». La première permet de désactiver le
service et la deuxième de le garder fonctionnel. Notez que les options enabled et
disabled ont priorité l'option disable. Ainsi, un service désactivé par l'une de
 ces options ne peut pas être réactivé en attribuant la valeur no à l'option disable.

​ Méthode d'enregistrement des événements du démon xinetd. Il est possible

d'utiliser le démon syslog pour enregistrer les événements de connexion et de
déconnexion des utilisateurs, ou directement un fichier texte. Dans le premier
cas, il faut utiliser la valeur SYSLOG suivie de la classe d'enregistrement
log_type
(généralement daemon) et du niveau de trace (généralement info). Dans le
deuxième cas, il faut spécifier la valeur FILE et indiquer les limites basse et haute
de la taille du fichier au delà desquelles un avertissement est généré, puis les
traces sont arrêtées.

​ Informations enregistrées lors de l'acceptation d'une connexion. xinetd peut

enregistrer différentes informations lorsqu'une nouvelle connexion est acceptée.
Ces informations sont indiquées grâce à la liste des mots-clés spécifiés par cette
option. Les mots-clés utilisables sont « PID », pour enregistrer l'identifiant de
log_on_success processus du démon qui traitera la requête, « HOST », pour enregistrer le nom de
la machine cliente, « USERID », pour enregistrer le nom de l'utilisateur (si celui-ci
peut être obtenu par le service d'identification de sa machine), « EXIT », pour
enregistrer la terminaison du démon qui traite la requête, et « DURATION », pour
enregistrer la durée de la connexion.

​ Informations enregistrées lors d'un refus de connexion. Les informations

enregistrées lors d'un refus de connexion peuvent être spécifiées à l'aide de cette
option, de la même manière que les informations de connexion peuvent être
enregistrées à l'aide de l'option log_on_success. Les mots-clés utilisables avec
log_on_failure
cette option sont « ATTEMPT », pour signaler simplement que la tentative a
échoué, « HOST », pour enregistrer le nom de la machine depuis laquelle la
tentative a été effectuée, et « USERID », pour enregistrer le nom de l'utilisateur tel
qu'indiqué par le service d'identification de sa machine.

​ Toutes les options disponibles ne sont pas décrites dans le tableau précédent. Vous pourrez obtenir
de plus amples renseignements en consultant la page de manuel xinetd.conf.

​ La section « defaults » permet de définir les options par défaut applicables à tous les services.
Les options qui y sont définies peuvent toutefois être redéfinies ou précisées à l'aide des opérateurs
=, += et -= dans les sections des différents services. Les options utilisables dans la section
defaults et que l'on a vu ci-dessus sont les options bind, log_type, log_on_success,
log_on_failure, instances, per_source, only_from, no_access, disabled et enabled.

​ Généralement, le fichier /etc/xinetd.conf ne contient que la section default et une ligne

d'inclusion du répertoire /etc/xinetd.d/, dans lequel se trouvent les fichiers de configuration des
différents services. L'exemple suivant présente donc un fichier xinetd.conf typique :
# Définition des options par défaut :
defaults
{
# On interdit la connexion à tout le monde par défaut :
only_from =

# On désactive les services internes :

disabled = echo time daytime chargen discard

# On désactive les services d'administration de xinetd :

disabled += servers services xadmin

# On limite le nombre d'instances total des services :

instances = 15

# On définit les règles de suivi des connexions :

log_type = FILE /var/log/servicelog
log_on_success = HOST PID USERID DURATION EXIT
log_on_failure = HOST USERID RECORD
}

# Inclusion des fichiers de configuration des services :

includedir /etc/xinetd.d

​ L'exemple suivant présente la définition du service telnet située dans le fichier de configuration
/etc/xinetd.d/telnet :

service telnet
{
socket_type = stream
# Le numéro de port et le protocole utilisés peuvent être omis
# car ils sont déjà définis dans /etc/services.

server = /usr/sbin/in.telnetd
user = root
wait = no
only_from = localhost
disable = no
}

Note : xinetd n'inclue pas les fichiers contenant un point (caractère '.') ni ceux
finissant par un tilde (caractère '~'). En particulier, on évitera de mettre une extension
aux fichiers de configuration des services, puisque dans ce cas ils contiendraient un
point et ne seraient pas lus.

Précédent Sommaire Suivant

Configuration du réseau Niveau supérieur Configuration de la connexion à
Internet