9.2.

Configuration du rseau sous Linux

La configuration du rseau ncessite donc la configuration du protocole IP et des services TCP, UDP et ICMP (entre autres). Cette opration se fait en dfinissant l'adresse IP le masque de sousrseau et les routes utiliser. Vient ensuite la configuration du nom de la machine locale, de son domaine, des noms de machines qu'elle peut rsoudre elle-mme 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 rseau simplement. Connaissant prsent la signification des termes utiliss dans les rseaux 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 rseau sont souvent appeles dans les scripts de dmarrage de la machine, ou dans les scripts de changement de niveau d'excution. Toutefois, il peut tre utile de connatre ces commandes, ne serait-ce que pour comprendre comment votre systme fonctionne. Cette section a donc pour but de vous prsenter ces commandes, ainsi que les principaux fichiers de configuration du rseau utiliss sous Linux.

9.2.1. Configuration statique des interfaces rseau

La principale commande permettant de configurer le rseau est la commande ifconfig. Comme son nom l'indique ( InterFace CONFiguration ), elle permet de configurer les interfaces rseau de la machine. Il faut savoir qu'il existe plusieurs types d'interfaces rseau. Les plus courants sont les trois types d'interfaces suivants : l'interface loopback, qui reprsente le rseau virtuel de la machine, et qui permet aux applications rseau d'une mme machine de communiquer entre elles mme si l'on ne dispose pas de carte rseau ; les interfaces des cartes rseau (que ce soient des cartes Ethernet, TokenRing ou autres) ; les interfaces ppp, plip ou slip, qui sont des interfaces permettant d'utiliser les connexions srielles, parallles ou tlphoniques comme des rseaux. La configuration d'une interface comprend l'initialisation des pilotes ncessaires son fonctionnement et l'affectation d'une adresse IP cette interface. La syntaxe gnrale que vous devrez utiliser est la suivante :
ifconfig interface adresse netmask masque up

o interface est le nom de l'interface rseau que vous voulez configurer, adresse est l'adresse IP que cette interface grera, et masque est le masque de sous-rseau 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 dsirez configurer l'interface loopback, vous devrez utiliser le nom d'interface lo. Le paramtre up donn ifconfig lui indique que l'interface doit tre active. Cela signifie que ds que la commande ifconfig s'achvera, votre interface rseau sera active et fonctionnelle. On ne peut faire plus simple... Bien entendu, il existe le paramtre inverse : down. Ce paramtre 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 trs 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 supplmentaire devant les nombres qui la constituent. En effet, il existe une convention en informatique qui dit que les nombres prfixs d'un 0 sont cods en octal, c'est--dire en base 8. Il va de soi qu'une adresse IP code en octal n'utilise pas les mmes nombres que lorsqu'elle est exprime en dcimal, aussi prouveriez-vous quelques difficults pour diagnostiquer le non fonctionnement de votre rseau si vous faisiez cette erreur ! Le noyau utilisera par dfaut 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-rseau. Si vous dsirez utiliser une autre adresse (en gnral, l'alternative est de prendre l'adresse du sous-rseau), vous devrez utiliser l'option broadcast adresse dans la commande ifconfig. Cependant, le comportement par dfaut convient la plupart des rseaux. La commande de configuration donne en exemple cidessus 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 rseau. C'est en particulier le cas pour toutes les interfaces rseau classiques, mais bien entendu cela n'est pas ralisable avec les interfaces de type point point comme les interfaces des connexions ppp. Lorsqu'une interface dispose de plusieurs adresses, la premire est considre comme l'adresse principale de l'interface, et les suivantes comme des alias. Ces alias utilisent comme nom le nom de l'interface rseau principale et le numro de l'alias, spars par deux points (caractre ':'). 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 rseau, on utilisera la syntaxe suivante :
ifconfig interface:numro add adresse netmask masque

o interface est toujours le nom de l'interface, numro est le numro de l'alias, adresse est l'adresse IP attribuer cet alias, et masque est le masque de sous-rseau de cette adresse. La commande ifconfig est en gnral appele dans les scripts d'initialisation du systme, qui ont t gnrs par l'utilitaire de configuration rseau de votre distribution. Si vous effectuez un grep sur ifconfig dans le rpertoire /etc/rc.d/ (ou /sbin/init.d/, selon votre distribution), vous trouverez la commande de dmarrage du rseau. Il se peut qu'une variable d'environnement soit utilise 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. Dfinition des rgles de routage

La deuxime tape dans la configuration du rseau est la dfinition des rgles de routage. Il est possible de dfinir plusieurs rgles de routage actives simultanment. L'ensemble de ces rgles constitue ce qu'on appelle la table de routage. La rgle utilise est slectionne par le noyau en fonction de l'adresse destination du paquet router. Chaque rgle indique donc un critre de slection sur les adresses, et l'interface vers laquelle doivent tre transfrs les paquets dont l'adresse destination vrifie cette rgle. La commande utilise pour dfinir une route est, chose surprenante, la commande systme route. Sa syntaxe est donne ci-dessous :
route opration [-net | -host] adresse netmask masque interface

o opration est l'opration effectuer sur la table de routage. L'opration la plus courante est simplement l'ajout d'une rgle de routage, auquel cas add doit tre utilis. L'option suivante permet d'indiquer si le critre de slection des paquets se fait sur l'adresse du rseau destination ou plus restrictivement sur l'adresse de la machine destination. En gnral, il est courant d'utiliser la slection de toutes les adresses d'un mme rseau et de les router vers une mme interface. Dans tous les cas, adresse est l'adresse IP de la destination, que celle-ci soit un rseau ou une machine. Si la destination est un rseau, il faut indiquer le masque de sous-rseau masque l'aide de l'option netmask. Enfin, interface est l'interface rseau vers laquelle doivent tre envoys les paquets qui vrifient les critres de slection de cette rgle. Par exemple, la rgle de routage utiliser pour l'interface loopback est la suivante :
route add -net 127.0.0.0 netmask 255.0.0.0 lo

Cette rgle signifie que tous les paquets dont l'adresse de destination appartient au sous-rseau de classe A 127.0.0.0 doivent tre transfrs 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 envoys vers l'interface loopback (ils reviendront donc sur la machine locale). Une autre rgle 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 rseau de classe C 192.168.0.0 vers la premire interface Ethernet. C'est typiquement ce genre de rgle qu'il faut utiliser pour faire fonctionner un rseau local. Il n'est normalement pas ncessaire d'ajouter les rgles de routage pour les rseaux auxquel la machine est connecte. En effet, la configuration d'une carte rseau l'aide de la commande ifconfig ajoute automatiquement la table de routage une rgle pour envoyer les paquets destination de ce rseau par l'interface rseau qui y est connecte. Cependant, la commande route devient rellement ncessaire lorsqu'il faut dfinir les passerelles utiliser pour l'envoi des paquets destins une machine laquelle la machine locale ne peut accder directement. Les rgles de routage faisant intervenir une passerelle sont semblables aux rgles de routage vues ci-dessus, ceci prs que l'adresse IP de la passerelle utiliser doit tre fournie. Pour cela, on utilise l'option gw (abrviation de l'anglais Gateway ). La syntaxe utilise 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 vrifient les critres de cette rgle. Les autres paramtres sont les mmes que pour les rgles de routage classique. Par exemple, supposons qu'une machine soit connecte un rseau d'adresse 192.168.0.0, et que sur ce rseau se trouve une passerelle d'adresse 192.168.0.1 permettant d'atteindre un autre rseau, dont l'adresse est 192.168.1.0. Une machine du rseau 192.168.0.0 aura typiquement les rgles 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 premire rgle permet, comme on l'a dj vu, de communiquer avec toutes les machines du rseau local. La deuxime rgle permet d'envoyer la passerelle 192.168.0.1 tous les paquets destination du rseau 192.168.1.0. Inversement, si la passerelle utilise l'adresse 192.168.1.15 sur le rseau 192.168.1.0, les machines de ce rseau qui voudront accder au rseau 192.168.0.0 devront spcifier la rgle 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 ncessaire que toutes les machines des deux rseaux utilisent ces rgles de routage pour que la communication entre les deux rseaux se fasse dans les deux sens. Le problme de ces rgles de routage est qu'elles spcifient l'adresse du rseau destination. Il est videmment hors de question d'utiliser une rgle de routage diffrente pour toutes les adresses de rseaux possibles. Il est donc possible de dfinir ce qu'on appelle une passerelle par dfaut, qui n'est rien d'autre que la passerelle vers laquelle doivent tre envoys tous les paquets qui n'ont pas vrifi les critres des autres rgle de routage. La syntaxe utiliser pour dfinir la passerelle par dfaut est plus simple, puisqu'il n'est plus ncessaire de prciser les critres de slection :
route add default gw passerelle interface

o la signification des paramtres passerelle et interface est inchange. Ainsi, pour reprendre l'exemple prcdent, supposons que la machine 192.168.0.47 dispose d'une connexion Internet et soit configure pour partager cette connexion avec les machines du rseau local. Pour que toutes les machines du rseau local puisse profiter de cette connexion, il suffit de demander ce que tous les paquets qui ne vrifient aucune autre rgle de routage soient envoys la passerelle 192.168.0.47. Cela se fait avec la rgle de routage suivante :
route add default gw 192.168.0.47 eth0

9.2.3. Dfinition du nom de la machine

La configuration du nom d'un ordinateur n'est pas proprement parler une opration indispensable, mais elle permet de le nommer de manire 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. Appele 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 dtermin automatiquement par le systme partir des informations issues de la configuration de la rsolution des noms de domaine. Nous verrons cela dans le paragraphe suivant. Cette commande est donc trs simple utiliser, et elle est en gnral appele dans les scripts de dmarrage du systme. 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. Rsolution des noms de domaine

La commande hostname ne permet de fixer que le nom de la machine locale. Pour les autres machines du rseau, il faut mettre en place les mcanismes de rsolution de noms de domaine. Comme il l'a dj t indiqu au dbut 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 stocke en local, soit l'interrogation d'un serveur de noms de domaine. Le fichier /etc/host.conf permet de dfinir le comportement du systme lors de la rsolution

d'un nom. Sa structure est trs 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 rsolution doit se faire d'abord localement, puis par appel aux DNS si la recherche prcdente a chou. C'est en gnral le comportement dsir. La deuxime ligne permet de faire en sorte que toutes les adresses correspondant une machine soient renvoyes. Si l'on avait utilis l'option multi off, seule la premire adresse IP trouve aurait t renvoye. La liste de noms locale est stocke dans le fichier /etc/hosts (cela explique le nom hosts utilis pour l'option order dans le fichier /etc/host.conf). Votre ordinateur connatra directement l'adresse IP de toutes les machines rfrences dans ce fichier. Il est bon de placer ici une entre pour les ordinateurs les plus couramment utiliss sur le rseau. Chaque entre commence par une adresse IP, et est suivie de la liste des noms de la machine possdant cette adresse, spars par des espaces. Pour ceux qui ne disposent pas de rseau local, ce fichier doit tre relativement simple : seule la ligne affectant l'adresse 127.0.0.1 la machine locale (appele localhost ) doit s'y trouver.
127.0.0.1 localhost

De la mme manire, le fichier /etc/networks contient les adresses des rseaux. Ce fichier est utilis par la commande route pour donner un nom aux diffrents rseaux. Chaque entre est constitue du nom du rseau, suivi de son adresse IP. Encore une fois, ce fichier se rduit sa plus simple expression pour ceux qui n'ont pas de rseau local, puisqu'il ne contiendra tout au plus qu'une entre pour le rseau loopback , sur lequel se trouve l'adresse de retour 127.0.0.1. Cette entre aura donc la forme suivante :
loopback 127.0.0.0

La configuration des serveurs de noms est en revanche une opration ncessaire si l'on dsire accder des machines dont on ne connat que le nom. Le fichier de configuration utilis est cette fois le fichier /etc/resolv.conf. Sa structure est encore une fois trs 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 spcifier une liste de noms de domaines ajouter par dfaut aux noms de machines non compltement qualifis. Les lments de cette liste doivent tre spars 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 indiqus ici, jusqu' ce que la rsolution du nom en adresse IP russisse. Cette recherche commence bien entendu par le nom de domaine local, s'il a t dfini. 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 requte au DNS se fera avec le nom compltement qualifi krypton.andromede.galaxie . Vous tes bien entendu libre d'ajouter d'autres noms de domaines pour le cas o la rsolution 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 adresses les requtes de rsolution 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 rsolution 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

Gnralement, la gestion des adresses IP des machines devient rapidement une tche difficile sur les grands rseaux, pour trois raisons. Premirement, 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 consquence. Deuximement, il faut que les fichiers /etc/hosts de toutes les machines soient jour, ce qui ncessite un travail proportionnel au nombre de machines administres. Enfin, le nombre d'adresses IP disponibles peut se rduire, ce qui peut devenir gnant terme. Afin de rsoudre ces problmes de configuration rseau, le protocole DHCP (abrviation de l'anglais Dynamic Host Configuration Protocol ) a t dfini. Il s'agit d'un protocole qui permet aux machines connectes sur un rseau d'interroger un serveur d'adresses du rseau capable de grer une liste d'adresses et de les affecter dynamiquement aux machines du rseau. En fait, ce protocole permet de fournir plus d'informations que les simples adresses IP, comme par exemple la route par dfaut que les machines doivent utiliser, ainsi que les adresses des serveurs de noms du rseau. Un autre protocole semblable DHCP a galement t dvelopp dans le but de permettre la configuration rseau des machines ds leur dmarrage : le protocole BOOTP (abrviation de l'anglais BOOTstrap Protocol ). Ce protocole est videmment plus lger que DHCP, mais permet aux machines d'obtenir dynamiquement leur configuration rseau ds leur dmarrage, avant mme que ne soient monts les systmes de fichiers. Ce protocole est donc particulirement utile pour faire dmarrer des machines sans disque, pour lesquelles le systme de fichiers racine est mont en NFS. La manire la plus simple de configurer les protocoles DHCP et BOOTP sur un poste client est d'utiliser les fonctionnalits d'auto-configuration du noyau. Cependant, il est galement possible d'effectuer cette configuration au niveau utilisateur l'aide de programmes complmentaires. Les deux sections suivantes dcrivent ces deux techniques.

9.2.5.1. Autoconfiguration des clients DHCP et BOOTP

La configuration des protocoles DHCP et BOOTP ne comporte aucune difficult particulire lorsque l'on utilise les fonctionnalits d'autoconfiguration du noyau. Ces fonctionnalits tant prises en charge au niveau du noyau, il va vous falloir recompiler un nouveau noyau pour en bnficier. Cette opration en revanche est relativement technique, et doit tre faite avec soin. La manire de procder a t dcrite en dtail 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 slectionner le protocole d'auto-configuration rseau que le noyau devra utiliser lors de son amorage. 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 rseau au dmarrage : le protocole RARP. Ce protocole fournit les mmes services

que le protocole BOOTP, mais est plus ancien. Il n'est donc plus conseill de l'utiliser, sauf vous vous trouvez sur un rseau pour lequel seul le protocole RARP est disponible. Une fois ces options slectionnes, vous pourrez recompiler votre noyau, l'installer et redmarrer la machine. Lors du dmarrage, le noyau doit chercher un serveur DHCP ou un serveur BOOTP sur le rseau local pour effectuer la configuration rseau de votre carte rseau. 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 dsirez faire dmarrer votre machine sur un systme de fichiers racine mont en NFS lors du dmarrage.

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 complmentaires. Comme sur la plupart des machines Unix, le programme utiliser est le programme dhclient. Ce programme est gnralement lanc dans les scripts de dmarrage des machines, et envoie des paquets de demande de configuration sur le rseau l'adresse de diffusion gnrale 255.255.255.255. Ces paquets sont donc susceptibles d'tre captes par toutes les machines du rseau, mais seuls les serveurs DHCP y rpondent. Les rponses obtenues sont alors analyss par dhclient, qui configure en consquence l'interface rseau et passe ensuite en arrire-plan. Les informations envoyes par les serveurs DHCP peuvent tre plus ou moins compltes, la base tant bien sr l'adresse IP de la machine et son masque de sous-rseau. Il est toutefois possible de donner plus d'informations, comme par exemple les adresses des serveurs de noms, des routes par dfaut et des passerelles utiliser. Les adresses IP attribues aux clients ne sont pas permanentes, car le protocole DHCP est avant tout destin la configuration automatique des postes itinrants ou susceptibles de redmarrer souvent. Par consquent, ces adresses sont fournies dans le cadre d'un bail, dont la dure maximum est fixe par le serveur. Ds 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 arrire-plan aprs avoir configur l'interface pour la premire 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 arrt par exemple), le serveur DHCP peut rutiliser son adresse IP et l'affecter une autre machine. Bien que les serveurs DHCP s'efforcent gnralement de conserver les adresses IP des clients chaque bail, un client configur par DHCP ne peut donc pas considrer que son adresse IP restera toujours la mme. C'est la contrepartie de la flexibilit. Si aucun serveur DHCP ne peut tre contact lors du dmarrage, dhclient abandonne temporairement et ressaie au bout d'un temps alatoire. Au bout d'un certain nombre d'essais non fructueux, il peut dcider de configurer les interfaces rseau avec les adresses IP des anciens baux obtenus par la machine. Pour cela, il mmorise dans le fichier de configuration /var/db/dhclient.lease les adresses IP de ces anciens baux. Ce fichier est priodiquement rcrit 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 vrification d'unicit. Dans le cas de l'absence de serveur DHCP (et donc d'autorit centrale), les clients qui dmarrent interrogent les machines dj prsentes sur le rseau pour dterminer si l'adresse qu'ils envisagent de prendre est bien libre. Dans le cas contraire, une autre adresse est essaye, et ainsi de suite. Ainsi, mme en cas de panne de tous les serveurs DHCP d'un rseau, 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

dpend de nombre de paramtres. Tous ces paramtres peuvent tre dfinis dans le fichier de configuration /etc/dhclient.conf. Ce fichier contient en particulier les diffrentes dures intervenant dans le choix des adresses IP, comme par exemple la dure minimale d'un bail, les dures entre chaque tentatives de configuration, les informations qui doivent tre rcupres des serveurs DHCP, ainsi que les valeurs par dfaut 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 dfaut qui conviennent dans la plupart des cas, aussi est-il fortement probable que votre fichier dhclient.conf soit vide. Si toutefois vous dsirez en savoir plus, vous pouvez consulter la page de manuel dhclient.conf. La configuration DHCP pour les postes clients se rduit 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 rseau qui doivent tre configures par DHCP. On ne peut donc pas faire plus simple... Note : Sous Linux, le programme dhclient utilise les fonctionnalit d'accs direct aux cartes rseau et de filtrage des paquets. Ces deux fonctionnalits peuvent tre actives 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 active. Le dtail de la configuration et de la compilation du noyau a t vu dans la Section 7.3. Le programme dhclient est assez factieux depuis quelques versions. S'il refuse obstinment 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 dterminer la solution qu'elle utilise.

9.2.6. Dfinition des protocoles de haut niveau

Comme nous l'avons vu plus haut, le protocole IP fournit les mcanismes de base pour la transmission des paquets. Plusieurs protocoles de plus haut niveau ont t dfinis pour fournir des services valeur ajoute, qui satisfont donc plus aux besoins des applications. Tous ces protocoles sont encapsuls dans le protocole IP, ce qui signifie que leurs informations sont transmises en tant que donnes dans les paquets IP. En ralit, 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 numrique qui lui est propre, et qui permet aux services rseau d'interprter les donnes des paquets. Tout comme les adresses IP, ces numros identifiant les protocoles ne sont pas trs intressants pour les humains, qui leur prfre videmment le nom du protocole. Certains programmes rseau utilisent donc ces noms pour identifier les protocoles. Pour leur permettre de faire l'association entre ces noms et les identificateurs numriques, le fichier /etc/protocols est utilis. Le format de ce fichier est trs simple. Il contient une ligne pour chaque protocole, constitue 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

Numro

Alias

ip 0 IP icmp 1 ICMP tcp 6 TCP udp 17 UDP Comme on le voit, le protocole IP dispose lui-mme 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 numro 1, TCP par le numro 6 et UDP par le numro 17. Il existe beaucoup d'autres protocoles, qui ne seront pas dcrits ici. Bien entendu, le fichier /etc/protocols fourni avec votre distribution doit dj contenir la dfinition de la plupart des protocoles. De la mme manire, la plupart des ports TCP et UDP sont affects des services bien dfinis, et certains programmes rseau peuvent chercher faire la correspondance entre les noms de ces services et les numros de ports. Cette correspondance est stocke dans le fichier de configuration /etc/services. Les informations concernant les services sont donnes raison d'une ligne par service. Chaque ligne suit la syntaxe suivante :
nom port/protocole alias

o nom est le nom du service dcrit par cette ligne, port est le numro 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 : 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 donnes uniquement titre d'exemple. Il va de soi que le fichier /etc/services fourni avec votre distribution contient la dfinition d'un grand nombre de services, et vous n'aurez en gnral pas y toucher. Service

9.2.7. Les super-dmons inetd et xinetd

La plupart des services rseau sont grs par des programmes qui s'excutent 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 rveillent que lorsqu'un client se connecte effectivement et leur envoie une requte. Cependant, ils peuvent tre relativement nombreux, et si tous les services sont lancs simultanment, ils peuvent finir par consommer une part non ngligeable des ressources systme. C'est pour cette raison que les super-dmons inetd (de l'anglais InterNET Daemon ) et xinetd (de l'anglais eXtended INETD ) ont t crs. Ces dmons sont l'coute des demandes de connexion des clients pour les autres services rseau, et ne lancent ceux-ci que lorsqu'un client se connecte sur leurs ports. Une fois lancs, les vritables dmons 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 systme sont donc conomises et les services rseau sont dmarrs et arrts la demande. Le super-dmon xinetd est appel remplacer inetd, qui lui est beaucoup plus ancien et nettement moins souple. En pratique, un seul de ces super-dmons doit tre dmarr 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 manires). Les deux sections suivantes dcrivent la configuration de ces super-dmons.

9.2.7.1. Le super-dmon inetd

Le super-dmon inetd laisse de plus en plus la main au nouveau super-dmon xinetd qui est beaucoup plus puissant, mais reste toutefois trs utilis sur de nombreuses machines. Sa description n'est donc pas inutile, car toutes les distributions n'utilisent pas encore xinetd. Le super-dmon inetd utilise le fichier de configuration /etc/inetd.conf pour dterminer les ports sur lesquels il doit attendre des connexions de la part des clients, et pour trouver le service rseau qu'il doit lancer lorsqu'une telle connexion arrive. Ce fichier est structur en lignes, dont chacune dcrit un des services que le dmon inetd prend en charge. Les informations donnes sur ces lignes sont les suivantes : le nom du service (tel qu'il est dfini dans la premire colonne du fichier /etc/services) dont inetd doit surveiller les requtes ; le type de canal de communication rseau utilis, en gnral stream (pour les communications en mode connect, donc en gnral celles qui utilisent le protocole TCP) ou dgram (pour les communications bases sur les datagrammes, donc typiquement les communications utilisant le protocole UDP) ; le protocole rseau utilis ( tcp ou udp ) par ce service ; l'un des mots cls wait ou nowait, qui permettent d'indiquer si inetd doit attendre la fin de l'excution du dmon grant le service ou s'il peut attendre de nouvelles requtes de la part des clients ; le nom de l'utilisateur au nom duquel le dmon grant ce service doit fonctionner (en gnral, c'est l'utilisateur root) ; le chemin sur le fichier excutable de ce dmon ; les ventuels paramtres en ligne de commande pour ce dmon, en commenant par l'argument 0, qui doit toujours tre le nom du fichier excutable du programme lui-mme. Par exemple, la ligne suivante permet de lancer le dmon telnetd sur toute requte 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 dmon en charge de ce service peut tre lanc avec le programme /usr/sbin/in.telnetd. Le dmon inetd est capable de fournir lui-mme un certain nombre de services de base, et il n'est pas ncessaire de fournir un dmon pour ces services. Dans ce cas, il faut utiliser le mot cl internal la place du nom du fichier excutable du dmon de ce service. Les paramtres doivent galement tre remplacs par le mot cl internal. En fait, il est fort peu probable que votre fichier de configuration /etc/inetd.conf dfinisse les services comme indiqu dans cette section. En effet, un programme intermdiaire en charge d'assurer des contrles de scurit est souvent intercal entre inetd et les dmons grant les services.

Nous verrons ce que fait exactement ce programme dans une prochaine section.

9.2.7.2. Le super-dmon xinetd

Le super-dmon xinetd utilise un autre fichier de configuration que celui du super-dmon inetd. Pour xinetd, la dfinition 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 rfrencer des rpertoires contenant les fichiers de configuration spcifiques aux services. Ainsi, la configuration des services est beaucoup plus modulaire et se fait plus facilement. En pratique, il est d'usage de dfinir les options par dfaut pour tous les services dans le fichier de configuration /etc/xinetd.conf, et de dcrire les diffrents services dans des fichiers complmentaires stocks dans le rpertoire /etc/xinetd.d/. Ce rpertoire est alors inclus directement dans le fichier xinetd.conf l'aide de la directive includedir ddie cet usage. Les fichiers de configuration de xinetd sont constitus de sections permettant de dcrire les services pris en charge, ou tout simplement les options par dfaut applicables tous les services. La forme gnrale de ces sections est la suivante :
service { option oprateur valeur [valeur [...]] option oprateur valeur [valeur [...]] ... }

o service est le nom du service (ou defaults pour les options par dfaut), option est un mot-cl identifiant une des options de ce service, et oprateur est l'un des oprateurs '=' (pour la dfinition de la valeur d'une option ou l'crasement de sa valeur prcdente), '+=' (pour complter 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 dpend des options utilises. Les principales options utilisables dans ces sections sont les suivantes : Option Signification Identificateur du service, pour le cas o plusieurs sections devraient tre dfinies pour un mme service. Cette possibilit est utilise lorsque l'on dsire fournir des options diffrentes pour un mme service. L'entre choisie (et donc le jeu d'options choisi) dpend dans ce cas de critres dfinis par exemple sur l'interface rseau ou sur les adresses des clients. Permet d'indiquer la nature du service dcrit par cette section. Gnralement, cette option n'a pas tre donne, sauf lorsque l'on veut forcer la mthode d'implmentation d'un service. Par exemple, il est possible de donner la valeur INTERNAL cette option pour utiliser l'un des services implments

id

type

Option

Signification par xinetd en interne. Permet de donner le chemin sur l'excutable du dmon prenant en charge le service dcrit.

server

Permet de donner les paramtres en ligne de commande du dmon prenant en charge le service. Notez que, contrairement ce qui se fait avec inetd, il ne faut gnralement pas donner le nom de l'excutable en server_args premier argument dans cette option. Cette rgle peut toutefois tre rendue fausse en ajoutant la valeur NAMEINARGS dans l'option flags dcrite ci-dessous. Le type de canal de communication utilis ( stream ou dgram , comme pour socket_type inetd). Le protocole rseau utilis par le service ( tcp ou udp , comme pour inetd). Le port sur lequel le service peut tre trouv. Cette option est facultative. Si elle n'est pas indique, le numro 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 dmon grer plusieurs connexions simultanment. Les valeurs que l'on peut donner cette option sont yes et no , respectivement pour indiquer que le dmon peut grer plusieurs connexions simultanment ou non. Dans ce dernier cas, le dmon xinetd lancera plusieurs instances du dmon grant le service si plusieurs clients cherchent se connecter simultanment. Le nombre maximum d'instance peut toutefois tre contrl l'aide des options instances et per_source dcrites ci-dessous. Les paramtres permettant de contrler diffrents 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

protocol

port

wait

flags

Option

Signification d'identification des clients, NORETRY , qui permet d'viter de ressayer de lancer le dmon du service si le lancement prcdent a chou, et NAMEINARGS, qui permet d'indiquer que le nom de l'excutable doit tre spcifi en premier paramtre dans l'option server_args. Le compte utilisateur dans lequel le dmon prenant en charge le service doit tre lanc. Cette option ne peut bien entendu pas tre utilise pour les services grs en interne par xinetd. L'interface laquelle le service est attach. Cette option permet de dfinir plusieurs configurations pour un mme service et d'affecter ces diffrentes configurations des interfaces rseau distinctes. Pour l'heure, seul l'adresse IP de l'interface rseau peut tre spcifie grce cette option, ce qui impose d'avoir des adresses IP fixes. La liste des adresses des machines autorises se connecter. Il est possible de spcifier les adresses IP explicitement ou l'aide d'une adresse et d'un masque de sousrseau. Les noms de domaines peuvent galement tre utiliss. Dans ce cas, le nom n'est pas transform en adresse IP. Au contraire, c'est l'adresse du client qui est retransforme en nom de machine pour vrifier s'il a le droit de se connecter. Notez que l'absence de ce champ indique que, par dfaut, l'accs est accord toutes les machines (sauf celles explicitement interdites de connexion par l'option no_access dcrite ci-dessous). En revanche, la prsence de ce champ mais sans valeur permet d'interdire l'accs toutes les machines. La liste des adresses des machines qui n'ont pas le droit de se connecter. Les adresses peuvent tre spcifies de la mme manire que pour l'option only_from. Si une adresse vrifie les critres des deux options only_from et no_access, c'est l'option dont le critre est le plus prcis qui est

user

interface

only_from

no_access

Option choisie.

Signification

La priode pendant laquelle le service est accessible. Cette priode peut tre exprime access_time sous la forme d'une liste d'intervalles s heure:minute-heure:minute . Permet d'indiquer le nombre maximum d'instances d'un mme dmon que xinetd peut lancer. Cette option permet donc de spcifier un nombre de connexions maximum pour chaque service.

instances

Permet d'indiquer le nombre maximum d'instances d'un mme dmon que xinetd peut lancer pour un mme client (identifi par son adresse IP). Cette option permet per_source donc de limiter le nombre de connexions d'un client, de manire indpendante 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 dni de service. Cette option prend deux paramtres, le premier tant le nombre maximum de demandes de connexion par seconde que xinetd peut accepter. Si ce nombre est dpass le service est dsactiv pendant le nombre de secondes indiqu par le deuxime paramtre. Permet de dsactiver globalement des services, en indiquant leurs noms en paramtre. Par dfaut, aucun service n'est dsactiv. Cette option ne peut tre utilise que dans la section defaults, car elle permet de dsactiver globalement et rapidement un ensemble de services. Permet de donner la liste des services pris en charge. Cette option fonctionne de manire similaire l'option disabled, ceci prs qu'elle fonctionne en logique inverse. L'absence de cette option implique l'activation de tous les services, sauf ceux qui sont lists dans l'option disabled. En revanche, ds que cette option est dfinie,

cps

disabled

enabled

Option

Signification seuls les services lists sont dmarrs. Tout comme l'option disabled, cette option ne peut tre utilise que dans la section globale defaults. Permet de dsactiver les services de manire unitaire. Cette option est utilise dans les sections des services, afin d'indiquer de manire plus fine qu'avec les options enabled et disabled s'ils doivent tre activs ou non. Cette option peut prendre deux valeurs : yes ou no . La premire permet de dsactiver le service et la deuxime de le garder fonctionnel. Notez que les options enabled et disabled ont priorit l'option disable. Ainsi, un service dsactiv par l'une de ces options ne peut pas tre ractiv en attribuant la valeur no l'option disable. Mthode d'enregistrement des vnements du dmon xinetd. Il est possible d'utiliser le dmon syslog pour enregistrer les vnements de connexion et de dconnexion des utilisateurs, ou directement un fichier texte. Dans le premier cas, il faut utiliser la valeur SYSLOG suivie de la classe d'enregistrement (gnralement daemon) et du niveau de trace (gnralement info). Dans le deuxime cas, il faut spcifier la valeur FILE et indiquer les limites basse et haute de la taille du fichier au del desquelles un avertissement est gnr, puis les traces sont arrtes.

disable

log_type

log_on_succ Informations enregistres lors de l'acceptation d'une connexion. xinetd peut ess enregistrer diffrentes informations lorsqu'une nouvelle connexion est accepte. Ces informations sont indiques grce la liste des mots-cls spcifis par cette option. Les mots-cls utilisables sont PID , pour enregistrer l'identifiant de processus du dmon qui traitera la requte, 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 dmon qui traite la requte,

Option

Signification et DURATION , pour enregistrer la dure de la connexion.

Informations enregistres lors d'un refus de connexion. Les informations enregistres lors d'un refus de connexion peuvent tre spcifies l'aide de cette option, de la mme manire que les informations de connexion peuvent tre enregistres l'aide de l'option log_on_success. Les motslog_on_fail cls utilisables avec cette option sont ATTEMPT , pour signaler simplement ure que la tentative a chou, HOST , pour enregistrer le nom de la machine depuis laquelle la tentative a t effectue, 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 dcrites dans le tableau prcdent. Vous pourrez obtenir de plus amples renseignements en consultant la page de manuel xinetd.conf. La section defaults permet de dfinir les options par dfaut applicables tous les services. Les options qui y sont dfinies peuvent toutefois tre redfinies ou prcises l'aide des oprateurs =, += et -= dans les sections des diffrents 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. Gnralement, le fichier /etc/xinetd.conf ne contient que la section default et une ligne d'inclusion du rpertoire /etc/xinetd.d/, dans lequel se trouvent les fichiers de configuration des diffrents services. L'exemple suivant prsente donc un fichier xinetd.conf typique :
# Dfinition des options par dfaut : defaults { # On interdit la connexion tout le monde par dfaut : only_from = # On dsactive les services internes : disabled = echo time daytime chargen discard # On dsactive les services d'administration de xinetd : disabled += servers services xadmin # On limite le nombre d'instances total des services : instances = 15 # On dfinit les rgles 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 prsente la dfinition du service telnet situe dans le fichier de configuration /etc/xinetd.d/telnet :
service telnet { socket_type = stream # Le numro de port et le protocole utiliss peuvent tre omis # car ils sont dj dfinis dans /etc/services. server user wait only_from disable = /usr/sbin/in.telnetd = root = no = localhost = no

Note : xinetd n'inclue pas les fichiers contenant un point (caractre '.') ni ceux finissant par un tilde (caractre '~'). 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.