Page suivante Page précédente Table des matières

5. Informations générales concernant la configuration réseau

Vous devez connaître et bien comprendre les paragraphes suivants avant d'essayer de configurer votre réseau. Ce sont des principes de base qui s'appliquent, indépendamment de la nature du réseau que vous voulez mettre en place.

5.1 De quoi ai-je besoin pour démarrer ?

Avant de commencer à construire ou configurer votre réseau, vous aurez besoin de certaines choses. Les plus importantes sont :

Sources du noyau récentes

Si le noyau que vous utilisez actuellement ne supporte pas les types de réseau ou les cartes que vous voulez utiliser, vous aurez besoin des sources du noyau pour pouvoir le recompiler avec les options adéquates.

Vous pouvez toujours obtenir les sources du dernier noyau sur : ftp.funet.fi. Souvenez-vous que ftp.kernel.org est particulièrement surchargé : il vaut mieux obtenir les sources en cours en téléchargeant les patches au lieu des fichiers archives tar en entier ; de plus, essayez d'abord les miroirs du site principal, comme ftp.funet.fi (NdT : et bien sûr ftp.lip6.fr) ; souvenez-vous aussi que tous les sites Linux possèdent normalement des sources du noyau à jour.

Normalement les sources du noyau doivent être désarchivées dans le répertoire /usr/src/linux. Pour savoir comment appliquer les patches et compiler le noyau, lisez le Kernel-HOWTO. Pour savoir comment configurer les modules du noyau, lisez le ``Modules-mini-HOWTO''. Enfin, le fichier README qui se trouve dans les sources du noyau ainsi que le répertoire Documentation donnent beaucoup de renseignements au lecteur courageux.

Sauf indication contraire, je vous recommande de vous en tenir à une version stable du noyau (celle avec un chiffre pair en seconde place dans le numéro de version). Les versions de développement (avec un chiffre impair en seconde place dans le numéro de version) peuvent avoir une structure ou autre chose qui peut poser problème avec les logiciels de votre système. Si vous n'êtes pas certain de résoudre ce type de problèmes, avec en plus ceux qui existeraient sur d'autres logiciels, ne les utilisez pas.

D'autre part, certaines caractéristiques décrites dans ce document ont été introduites lors du développement des noyaux 2.1.x, vous devez donc choisir : soit vous restez avec la version 2.0 et attendez la version 2.2, avec une distribution mise à jour contenant tous les nouveaux outils, soit vous utilisez la version 2.1 et cherchez les divers programmes qui supportent les nouvelles fonctionnalités. Lorsque j'écris ce paragraphe, en août 1998, la version de développement en cours est la 2.1.115 et la 2.2 va apparaître prochainement.

Outils de réseau récents

Ces outils sont les programmes utilisés pour configurer les fichiers de périphériques réseau. Ils vous permettent d'assigner des adresses aux périphériques et de configurer des routes par exemple.

La plupart des distributions Linux modernes sont fournies avec les outils de réseau, aussi si vous avez fait votre installation à partie d'une distribution et que vous n'avez pas encore installé les outils de réseau, vous devez le faire.

Si vous n'avez pas fait l'installation à partir d'une distribution, vous aurez alors besoin des sources pour les compiler vous-même. Ce n'est pas difficile.

Les outils de réseau sont maintenus par Bernd Eckenfels et se trouvent sur : ftp.inka.de et sont recopiés sur : ftp.linux.uk.org.

Soyez sûrs de choisir la version la mieux appropriée à votre noyau et suivez les instructions incluses dans le paquetage.

Pour installer et configurer la version actuelle (au moment où j'écris), vous devrez faire :

user% tar xvfz net-tools-1.33.tar.gz
user% cd net-tools-1.33
user% make config
user% make
root# make install
De plus, si vous voulez configurer une protection pare-feu ou utiliser le masquage IP vous aurez besoin de la commande ipfwadm. La dernière version peut-être obtenue sur : ftp.xos.nl. Encore une fois, de nombreuses versions existent. Soyez sûrs de prendre celle qui s'adapte le mieux à votre noyau. Notez que les fonctionnalités pour pare-feu de Linux ont changé pendant le développement de la version 2.1. Ceci ne s'applique donc qu'aux noyaux version 2.0.

Pour installer et configurer la version qui a cours en ce moment, vous devrez faire :

user% tar xvfz ipfwadm-2.3.0.tar.gz
user% cd ipfwadm-2.3.0
user% make
root# make install

Notez que si vous avez la version 2.2 (ou l'ancienne 2.1) du noyau, ipfwadm n'est pas le bon outil pour configurer le pare-feu. Cette version de NET-3-HOWTO n'est pas en accord avec les nouveaux réglages du pare-feu.

Applications réseau

Les programmes d'application réseau sont des programmes tels que telnet et ftp et leurs serveurs respectifs. David Holland s'occupe maintenant d'une distribution très répandue, qui est maintenant maintenue par netbug@ftp.uk.linux.org. Vous pouvez obtenir cette distribution sur : ftp.uk.linux.org.

En mars 1997 le paquetage a été scindé en plusieurs paquetages plus petits, mais en mai 1997 la plupart des programmes de base ont été fusionnés en un seul paquetage nommé netkit-base-0.10. Vous pourriez avoir besoin de récupérer le paquetage de base et/ou les paquetages supplémentaires.

Pour installer et configurer la version qui existe à l'heure actuelle vous devrez faire :

user% tar xvfz netkit-base-0.10.tar.gz
user% cd netkit-base-0.10
user% more README
user% vi MCONFIG
user% make
root# make install

Adresses

Les adresses de protocole Internet (IP) sont composées de quatre octets. La convention d'écriture est appelée `notation décimale pointée'. Sous cette forme chaque octet est converti en un nombre décimal (0-255), en omettant les zéros de tête (à moins que ce nombre ne soit lui-même un zéro) et chaque octet est séparé par le caractère `.'. Par convention, chaque interface d'un hôte ou routeur possède une adresse IP. Il est permis, dans certaines circonstances, que la même adresse IP soit utilisée sur différentes interfaces d'une même machine, mais, en général, chaque interface possède sa propre adresse.

Les réseaux IP (Protocole Internet) sont des séquences contiguës d'adresses IP. Toutes les adresses d'un même réseau ont des chiffres en commun. La partie d'adresse commune à toutes les adresses d'un réseau s'appelle la `partie réseau' de l'adresse. Les chiffres restants s'appellent `partie hôte'. Le nombre de bits qui sont partagés par toutes les adresses d'un même réseau est appelé masque de réseau (netmask) et c'est le rôle du masque de réseau de déterminer quelles adresses appartiennent à `son' réseau et celles qui ne sont pas concernées. Par exemple :

----------------------------------------     ----------------
Adresse hôte (host address)                  192.168.110.23
Masque de réseau (network mask)              255.255.255.0
Partie réseau (network portion)              192.168.110.
Partie hôte (host portion)                              .23
----------------------------------------     ----------------
Adresse réseau (network address)             192.168.110.0
Adresse de diffusion (broadcast address)     192.168.110.255
----------------------------------------     ----------------

Toute adresse qui est `ANDÉE bit à bit' avec son masque de réseau révèlera l'adresse du réseau auquel elle appartient. L'adresse du réseau est par conséquent l'adresse de plus petit nombre dans l'ensemble des adresses et a toujours la partie hôte codée avec des zéros.

L'adresse de diffusion est une adresse spéciale que chaque hôte du réseau écoute en même temps que son adresse personnelle. Cette adresse est celle à laquelle les datagrammes sont envoyés si tous les hôtes du réseau sont en mesure de les recevoir. Certains types de données telles que les informations de routage et les messages d'alerte sont transmis vers l'adresse de diffusion de telle sorte que tous les hôtes du réseau peuvent les recevoir en même temps. Il y a deux standards utilisés de manière courante pour définir ce que doit être l'adresse de diffusion. Le plus largement utilisé est de prendre l'adresse la plus haute possible du réseau comme adresse de diffusion. Dans l'exemple ci-dessus ce serait 192.168.110.255. Pour d'autres raisons, certains sites ont adopté la convention d'utiliser l'adresse de réseau comme adresse de diffusion. En pratique cela n'a pas beaucoup d'importance, mais vous devez être sûrs que tous les hôtes du réseau sont configurés avec la même adresse de diffusion.

Pour des raisons d'administration, il y a quelque temps, lors du développement du protocole IP, des ensembles d'adresses ont été organisés en réseaux et ces réseaux ont été regroupés en ce que l'on a appellé classes. Ces classes donnent un certain nombre de réseaux de tailles standards auxquels on peut assigner des adresses. Ces classes sont :

----------------------------------------------------------
|Classe de |Masque de     | Adresses de réseau           |
| réseau   |  réseau      |                              |
----------------------------------------------------------
|    A    | 255.0.0.0     | 0.0.0.0    - 127.255.255.255 |
|    B    | 255.255.0.0   | 128.0.0.0  - 191.255.255.255 |
|    C    | 255.255.255.0 | 192.0.0.0  - 223.255.255.255 |
|Multicast| 240.0.0.0     | 224.0.0.0  - 239.255.255.255 |
----------------------------------------------------------

Le type d'adresse que vous devez utiliser dépend de ce que vous voulez faire exactement. Vous pouvez utiliser une combinaison des actions suivantes pour obtenir l'ensemble des adresses dont vous aurez besoin :

Installer une machine Linux sur un réseau IP existant

Vous devez alors contacter un des administrateurs du réseau et lui demander les informations suivantes :

Vous configurerez alors votre réseau Linux à l'aide de ces données. Vous ne pouvez pas les inventer vous-même et espérer que votre configuration fonctionne.
Construire un réseau tout neuf non connecté à l'Internet

Si vous construisez un réseau privé et que vous n'ayez pas l'intention de vous connecter à l'Internet, vous pouvez alors choisir n'importe quelle adresse. Cependant, pour des raisons de sécurité et de fiabilité, il y a quelques adresses de réseau IP réservées à cet usage. Elles sont spécifiées dans la RFC 1597 et sont les suivantes :

-----------------------------------------------------------
|         ALLOCATIONS POUR RÉSEAUX PRIVÉS                 |
-----------------------------------------------------------
| Classe  | Masque de     | Adresses de réseau            |
| réseau  |  réseau       |                               |
-----------------------------------------------------------
|    A    | 255.0.0.0     | 10.0.0.0    - 10.255.255.255  |
|    B    | 255.255.0.0   | 172.16.0.0  - 172.31.255.255  |
|    C    | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
-----------------------------------------------------------
Vous devez d'abord décider de la dimension de votre réseau et choisir ensuite les adresses dont vous avez besoin.

5.2 Où mettre les commandes de configuration ?

Il y a plusieurs possibilités de procédures de démarrage d'un système Linux. Après le démarrage du noyau, celui-ci exécute toujours un programme appelé `init'. Ce programme lit le fichier de configuration appelé /etc/inittab et commence le processus de démarrage. Il y a quelques variantes de init, bien que maintenant tout le monde se dirige vers la variante System V (cinq), développée par Miguel van Smoorenburg.

Bien que que le programme init soit toujours le même, les réglages du processus de démarrage se font différemment suivant le type de distribution. Habituellement le fichier /etc/inittab contient une entrée telle que :

si::sysinit:/etc/init.d/boot

Cette ligne spécifie le nom du fichier script qui prend en charge réellement la séquence de démarrage. Ce fichier est en quelque sorte équivalent au fichier MS-DOS AUTOEXEC.BAT.

Il y a aussi d'autres scripts appelés par le script de démarrage, et souvent le réseau est configuré dans l'un de ceux-ci.

Le tableau suivant peut être utilisé comme guide suivant le système que vous avez :

-------------------------------------------------------------------------------
Distrib. |Interface Config/Routage           | Initialisation serveur
-------------------------------------------------------------------------------
Debian   | /etc/init.d/network               | /etc/rc2.d/*     
-------------------------------------------------------------------------------
Slackware| /etc/rc.d/rc.inet1                | /etc/rc.d/rc.inet2 
-------------------------------------------------------------------------------
RedHat   | /etc/rc.d/init.d/network          | /etc/rc.d/rc3.d/*
-------------------------------------------------------------------------------

Notez que les distributions Debian et RedHat utilisent tout un répertoire pour les scripts qui mettent en route les services du système (et habituellement l'information ne se situe pas dans ces fichiers, par exemple les systèmes RedHat stockent l'ensemble de la configuration du système sous /etc/sysconfig, où elle est récupérée par les scripts de démarrage). Si vous voulez saisir les détails du processus de démarrage, je vous conseille de vérifier /etc/inittab ainsi que la documentation accompagnant init. Linux Journal va également publier un article sur l'initialisation des systèmes, et nous pointerons sur lui dès qu'il sera disponible sur le réseau.

La plupart des distributions récentes incluent un programme qui permet de configurer de nombreux types d'interfaces réseau. Si vous en possédez une, regardez si ce programme vous convient au lieu de tenter une configuration manuelle.

-----------------------------------------
Distrib   | Programme de configuration réseau
-----------------------------------------
RedHat    | /sbin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------

5.3 Créer vos interfaces réseau

Sur beaucoup de systèmes Unix les périphériques réseau apparaissent dans le répertoire /dev . Il n'en est pas de même avec Linux. Les périphériques réseau sont créés dynamiquement par les logiciels et ne nécessitent donc pas de fichiers de périphériques.

Dans la majorité des cas, le périphérique réseau est créé automatiquement par le pilote de périphérique pendant son initialisation lorsqu'il détecte votre matériel. Par exemple le pilote Ethernet crée les interfaces eth[0..n] une à une quand il détecte votre matériel Ethernet. La première carte Ethernet trouvée devient eth0, la deuxième eth1, etc.

Cependant, dans certains cas, notamment avec SLIP et PPP, les périphériques réseau sont créés par un programme utilisateur. Le même mécanisme séquentiel s'applique sur les périphériques, mais ce n'est pas au moment du démarrage du système. La raison en est que, à l'inverse des dispositifs Ethernet, le nombre de périphériques SLIP ou PPP actifs peut varier dans le temps. Nous y reviendrons plus tard.

5.4 Configurer une interface réseau

Lorsque vous avez tous les programmes requis, votre adresse et les informations réseau, vous pouvez alors configurer vos interfaces. Lorsque nous parlons de la configuration d'interface, nous faisons allusion au processus d'assignation des adresses du périphérique réseau, et au processus de réglage des paramètres configurables. Le programme le plus utilisé pour ce faire est la commande ifconfig (interface configure).

Typiquement vous utilisez une commande comme ci-dessous :

root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up

Dans ce cas je configure l'interface Ethernet `eth0' avec l'adresse IP `192.168.0.1' et un masque de réseau `255.255.255.0'. Le `up' qui termine la commande enjoint à l'interface de devenir active, mais il peut être omis, étant par défaut. Pour clore une interface, vous faites juste ``ifconfig eth0 down''.

Le noyau suppose certaines valeurs par défaut lorsque l'on configure les interfaces. Par exemple, vous pouvez indiquer une adresse de réseau et une adresse de diffusion, mais si vous ne le faites pas comme nous venons de le faire dans l'exemple ci-dessus, alors le noyau fera certaines hypothèses fondées sur le masque de réseau que vous avez fourni, et si vous ne l'avez pas donnée, sur la classe de l'adresse IP configurée. Dans mon exemple, le noyau considérera que c'est un réseau de classe C et configurera une adresse réseau de `192.168.0.0' et une adresse de diffusion de `192.168.0.255'.

Il y a de nombreuses autres options pour la commande ifconfig . Les plus importantes sont :

up

active une interface (est fait par défaut).

down

désactive une interface.

[-]arp

active ou désactive le protocole de résolution d'adresses sur cette interface.

[-]allmulti

active ou désactive la réception de tous les paquets multicast matériel (Ndt : Les adresses multicast sont un genre d'adresses de diffusion limitées à un groupe de machine qui n'ont pas nécessairement besoin de se trouver sur le même sous-réseau). Le multicast matériel permet à des groupes d'hôtes de recevoir des paquets adressés vers des destinations spéciales. Ce peut être important si vous utilisez des applications comme la vidéoconférence, mais la plupart du temps on ne l'utilise pas.

mtu N

ce paramètre permet de régler le MTU (Maximum Transfert Unit) sur le périphérique.

netmask <addr>

ce paramètre permet de fixer le masque de réseau.

irq <addr>

ce paramètre ne fonctionne qu'avec certains types de matériels, mais vous permet d'en fixer l'IRQ.

[-]broadcast [addr]

permet d'activer ou de désactiver l'acceptation de datagrammes destinés à l'adresse de diffusion.

(-)pointopoint [addr]

permet de fixer l'adresse de la machine à l'extrémité d'un lien point-à-point comme pour slip ou ppp.

hw <type> <addr>

permet de fixer l'adresse matérielle de certains périphériques réseau. Ce n'est pas souvent utilisé pour Ethernet, mais utile pour d'autres types de réseau tels que AX.25.

Vous pouvez utiliser la commande ifconfig pour toutes les interfaces réseau. Quelques programmes utilisateurs comme pppd et dip configurent automatiquement les périphériques en même temps qu'ils les créent, dès lors l'utilisation manuelle de ifconfig n'est pas nécessaire.

5.5 Configurer votre solveur de noms

Le `Solveur de Noms' (Name Resolver) fait partie de la bibliothèque standard de Linux. Sa première fonction est de convertir des noms d'hôtes compréhensibles par l'homme, comme `ftp.funet.fi' , en adresses IP compréhensibles par une machine, comme 128.214.248.6.

Qu'y a-t-il dans un nom ?

Vous êtes probablement familiers avec l'aspect des noms d'hôtes Internet, mais vous ne savez pas comment ils sont composés ou décomposés. Les noms de domaine Internet sont hiérarchisés par nature, c'est-à-dire qu'ils ont une structure arborescente. Un `domaine' est une famille, ou un groupe de noms. Un `domaine' peut être subdivisé en `sous-domaines'. Un `domaine de premier niveau' est un domaine qui n'est pas un sous-domaine. Les Domaines de Premier Niveau sont spécifiés dans la RFC-920. Quelques exemples :

COM

Organisations Commerciales

EDU

Organisations ayant rapport avec l'Éducation

GOV

Organisations Gouvernementales (NdT: parfois GOUV en France!)

MIL

Organisations Militaires

ORG

Autres organisations

NET

Organisations ayant un rapport avec l'internet

Nom de Pays

il existe des codes de deux lettres qui représentent un pays donné.

Pour des raisons historiques la plupart des domaines appartenant à des domaines qui ne sont pas basés sur des noms de pays sont pour les organisations situées aux États-Unis, bien que les États-Unis aient aussi le code de pays `.us'. Ce n'est plus vrai pour les domaines .com et .org, qui sont couramment utilisés par des sociétés hors des États-Unis. Chacun de ces domaines de premier niveau possède des sous-domaines. Les domaines de premier niveau fondés sur les noms de pays sont divisés ensuite en sous-domaines basés sur les domaines com, edu, gov, mil et org . Ainsi par exemple, vous finissez par : com.au and gov.au pour des organisations commerciales ou gouvernementales situées en Australie ; notez que ce n'est pas une règle absolue, car les politiques réelles dépendant de l'autorité qui donne les noms pour chaque domaine.

Le niveau de division suivant représente habituellement le nom de l'organisation. Ces sous-domaines sont variables, souvent ils sont fondés sur la structure en départements de l'organisation mais ils peuvent l'être également sur d'autres critères considérés comme rationnels et compréhensibles par les administrateurs réseau de l'organisation.

La partie tout à fait à gauche du nom est toujours le nom unique assigné à la machine hôte et est appelée le nom d'hôte `hostname', la partie de droite du nom est le nom de domaine `domainname' et le nom complet s'appelle le nom de domaine complètement qualifié `Fully Qualified Domain Name' (ou FQDN).

Si l'on examine l'adresse de la machine de Terry par exemple, le nom pleinement qualifié est `perf.no.itg.telstra.com.au'. Cela veut dire que le nom d'hôte est `perf' et le nom de domaine `no.itg.telstra.com.au'. Le nom de domaine est fondé sur un domaine de premier niveau basé sur son pays, l'Australie et comme son adresse électronique appartient à une organisation commerciale nous avons `.com' comme domaine de niveau adjacent. Le nom de la société est (était) `telstra' et notre structure interne de noms est basé sur la structure organisationnelle, dans mon cas, ma machine appartient à l'Information Technology Group, section Network Operations.

Habituellement, les noms sont plutôt plus courts ; par exemple, mon fournisseur d'accès à l'internet est ``systemy.it'' et mon organisation à but non lucratif est ``linux.it'', sans sous-domaine com ou org, aussi mon propre hôte est simplement appelé ``morgana.systemy.it'' et rubini@linux.it est une adresse électronique valide. Notez que le propriétaire d'un domaine a le droit d'enregistrer les noms d'hôtes aussi bien que les noms de sous-domaine ; par exemple le Groupe d'Utilisateur Linux auquel j'appartiens utilise le domaine pluto.linux.it, car les propriétaires de linux.it étaient d'accord pour créer un sous-domaine pour ce groupe.

Les informations nécessaires

Vous devez connaître le domaine auquel votre nom d'hôte appartient. Le solveur de nom effectue la traduction en faisant appel à un `Serveur de Noms de Domaine', aussi vous devez connaître l'adresse IP d'un serveur de nom local que vous pouvez utiliser.

Il y a trois fichiers que vous devez éditer, nous en parlerons chacun à leur tour.

/etc/resolv.conf

Le fichier /etc/resolv.conf est le principal fichier de configuration pour le code de résolution de nom. Son format est très simple. C'est un fichier texte avec un mot-clé par ligne. Il y a trois mots-clés typiquement utilisés, qui sont :

domain

ce mot-clé indique le nom de domaine local.

search

ce mot-clé spécifie une liste d'autres noms de domaine pour rechercher un nom d'hôte.

nameserver

ce mot-clé, qui peut être utilisé plusieurs fois, spécifie l'adresse IP d'un serveur de nom de domaine pour la résolution de noms.

Un exemple de /etc/resolv.conf pourrait ressembler à ceci :
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
Cet exemple spécifie que le nom de domaine par défaut à ajouter aux noms non qualifiés (c'est-à-dire sans domaine) est maths.wu.edu.au, et que si l'hôte n'est pas trouvé dans ce domaine on peut aussi essayer le domaine wu.edu.au directement. Deux entrées de serveurs de noms sont fournies, chacune d'elles pouvant être appelée par le solveur de noms.

/etc/hosts

Le fichier /etc/hosts est l'endroit où vous mettez les noms et les adresses IP des hôtes locaux. Si vous mettez un hôte dans ce fichier, alors vous n'avez pas à interroger le serveur de nom de domaine pour obtenir son adresse IP. L'inconvénient est que vous devez tenir votre fichier à jour si l'adresse de cet hôte a changé. Dans un système bien administré les seuls noms d'hôtes qui apparaissent habituellement sont l'interface loopback, et le nom des hôtes locaux.

# /etc/hosts
127.0.0.1      localhost loopback
192.168.0.1    ma.belle.machine
Vous pouvez spécifier plus d'un nom d'hôte, comme montré dans la première entrée (qui est standard pour l'interface loopback).

Faire tourner un serveur de noms

Si vous voulez faire tourner un serveur de nom local, vous pouvez le faire facilement. Voyez le DNS-HOWTO et tous les documents inclus dans votre version de BIND (Berkeley Internet Name Domain).

5.6 Configurer votre interface loopback

L'interface `loopback' est un type spécial d'interface qui permet de vous connecter à vous-même. Il y a plusieurs raisons pour faire cela, par exemple si vous voulez faire des essais de logiciel réseau sans interférer avec quelqu'un d'autre sur votre réseau. Par convention, l'adresse IP `127.0.0.1' lui a été assignée. Aussi quelle que soit la machine où vous êtes, si vous ouvrez une connexion telnet vers 127.0.0.1 vous atteindrez toujours l'hôte local.

Configurer l'interface loopback est simple et vous devez vous assurer de l'avoir fait (mais notez que cette tâche est habituellement effectuée par les scripts standards d'initialisation).

root# ifconfig lo 127.0.0.1
root# route add -host 127.0.0.1 lo
Nous en dirons plus sur la commande route dans le prochain paragraphe.

5.7 Routage

Le routage est un vaste sujet. On peut écrire de grandes quantités de textes sur ce sujet. La plupart d'entre vous ont besoin d'un simple routage, et certains même de rien du tout. Je ne parlerai que des principes du routage. Si vous voulez plus d'informations je vous suggère de vous reporter aux références fournies en début du document.

Commençons par une définition. Qu'est-ce que le routage IP ? Voici celle que j'utilise :

Le routage IP est le processus par lequel un hôte, ayant des connexions réseau multiples, décide du chemin par lequel délivrer les datagrammes IP qu'il a reçus.

Il peut être utile d'illustrer cela par un exemple. Imaginez un routeur dans un bureau : il peut avoir un lien PPP sur l'Internet, un certain nombre de segments Ethernet alimentant les stations de travail et un second lien PPP vers un autre bureau. Lorsque le routeur reçoit un datagramme de l'une de ses connexions, le routage est le mécanisme utilisé pour déterminer vers quelle interface il doit renvoyer ce datagramme. De simples hôtes ont besoin aussi de routage, tous les hôtes Internet ayant deux périphériques réseau, l'un étant l'interface loopback décrite auparavant et l'autre est celui qui est utilisé pour parler avec le reste du monde, soit un lien Ethernet, soit une interface série PPP ou SLIP.

Ok, alors comment marche le routage ? Chaque hôte possède une liste spéciale de règles de routage, appelée une table de routage. Cette table contient des colonnes qui contiennent au moins trois champs, le premier étant une adresse de destination, le deuxième étant le nom de l'interface vers lequel le datagramme doit être routé et le troisième, qui est optionnel, l'adresse IP d'une autre machine qui transportera le datagramme vers sa prochaine destination sur le réseau passerelle. Sur Linux vous pouvez voir cette table en utilisant la commande suivante :

user% cat /proc/net/route
ou bien en utilisant l'une des commandes suivantes :
user% /sbin/route -n
user% /sbin/netstat -r

Le processus de routage est plutôt simple : un datagramme entrant est reçu, l'adresse de destination est examinée et comparée avec chaque entrée de la table. L'entrée qui correspond le mieux à cette adresse est choisie, et le datagramme est renvoyé vers l'interface spécifiée. Si le champ passerelle est rempli, alors le datagramme est renvoyé vers cet hôte via l'interface spécifiée, sinon l'adresse de destination est supposée comme étant sur le réseau supporté par l'interface.

Pour manipuler ce tableau, une commande spéciale est utilisée. Cette commande prend des arguments et les convertit en appels système pour demander au noyau d'ajouter, supprimer ou modifier des entrées dans la table de routage. Cette commande s'appelle `route'.

Un exemple simple. Imaginez que vous ayez un réseau Ethernet. On vous a dit que c'est un réseau classe C avec une adresse de 192.168.1.0. On vous fournit une adresse IP 192.168.1.10 pour votre usage et on vous a dit que 192.168.1.1 est un routeur connecté à l'Internet.

La première étape est de configurer l'interface comme indiqué plus haut. Vous utiliserez la commande :

root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
Maintenant vous avez besoin d'ajouter une entrée dans la table de routage pour indiquer au noyau que les datagrammes destinés aux hôtes dont les adresses correspondent à 192.168.1.* doivent être dirigés vers le périphérique Ethernet. Vous utiliserez une commande comme ceci :
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
Notez l'utilisation de l'argument `-net' pour indiquer au programme route que cette entrée est une route réseau. Un autre choix peut être `-host' qui est une route spécifique d'une adresse IP.

Cette route vous permettra d'établir des connexions IP avec tous les hôtes sur votre segment Ethernet. Mais qu'en est-il des hôtes IP qui n'y sont pas ?

Ce serait compliqué d'ajouter des routes pour chaque réseau destinataire, aussi il y a une astuce utilisée pour simplifier la tâche. L'astuce est appelée route par `default'. La route par defaut s'adapte à toutes les destinations possibles, mais pas très bien, de telle sorte que si il y a une entrée qui correspond à l'adresse requise elle sera utilisée à la place de la route par defaut. L'idée de la route par defaut est simplement de pouvoir dire `et tout le reste va ici'. Dans l'exemple que j'ai inventé, on utilisera une entrée telle que :

root# route add default gw 192.168.1.1 eth0
L'argument `gw' indique à la commande route que le prochain argument est l'adresse IP, ou le nom, d'une passerelle (gateway) ou d'une machine routeur vers qui tous les datagrammes correspondant à cette entrée seront dirigés pour routage ultérieur.

Ainsi votre configuration complète sera :

root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add default gw 192.168.1.1 eth0
Si vous regardez bien vos fichiers `rc' concernant le réseau vous en trouverez au moins un très semblable à celui-ci. C'est une configuration courante.

Examinons maintenant une configuration un peu plus compliquée. Imaginons que nous configurions le routeur examiné auparavant, celui qui avait un lien PPP vers l'Internet et des segments LAN alimentant des stations de travail dans le bureau. Supposons que ce routeur ait 3 segments Ethernet et un lien PPP. Notre configuration de routage ressemblerait à ceci :

root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
root# route add default ppp0
Chacune des stations de travail utilisera le format plus simple décrit ci-dessus, seul le routeur aura besoin d'indiquer les routes réseau séparément car pour les stations de travail le mécanisme de routage par defaut les capturera toutes, laissant au routeur le soin de les séparer de manière appropriée. Vous pouvez vous demander pourquoi la route par défaut n'utilise pas `gw'. La raison en est très simple : les protocoles de lien série comme PPP et SLIP ont seulement deux hôtes sur leur réseau, un à chaque bout. Spécifier à l'hôte que l'autre bout de la liaison est une passerelle est sans objet et redondant, car il n'a pas d'autre choix, aussi vous n'avez pas à indiquer de passerelle pour ce type de connexions réseau. Les autres types comme Ethernet, arcnet ou token ring ont besoin que l'on indique une passerelle car ces réseaux supportent un grand nombre d'hôtes.

Alors, que fait le programme routed ?

La configuration de routage décrite ci-dessus est bien adaptée aux réseaux simples où il n'y a que des chemins uniques entre les destinations. Lorsque vous avez un réseau plus complexe les choses deviennent plus compliquées. Heureusement pour la plupart d'entre vous, ce ne sera pas le cas.

Le gros problème est qu'avec le `routage manuel' ou `routage statique' comme décrit ci-dessus, si une machine ou un lien tombe en panne dans le réseau, alors la seule façon de diriger vos datagrammes vers un autre chemin, s'il existe, est d'intervenir manuellement et d'exécuter les commandes adéquates. Naturellement c'est lourd, lent, peu pratique et source de risques. Des techniques variées ont été développées pour régler automatiquement les tables de routage dans le cas d'incidents sur un réseau où il y a plusieurs routes possibles, toutes ces techniques étant regroupées sous le nom de `protocoles de routage dynamique'.

Vous avez peut-être entendu parler des plus courants. Ce sont RIP (Routing Information Protocol) et OSPF (Open Shortest Path First Protocol). RIP est très souvent utilisé sur les petits ou moyens réseaux d'entreprise. L'OPSF est plus moderne et plus apte à gérer de grands réseaux et mieux adapté dans le cas où il y a un grand nombre de chemins possibles à travers le réseau. Les implémentations usuelles de ces protocoles sont : `routed' - RIP, et `gated' - RIP, OSPF et autres. Le programme `routed' est normalement fourni avec votre distribution Linux ou est inclus dans la paquetage `NetKit' décrit auparavant.

Un exemple pour vous montrer comment et où vous pouvez utiliser un protocole de routage dynamique ressemblerait à ceci :

    192.168.1.0 /                         192.168.2.0 /
       255.255.255.0                         255.255.255.0
     -                                     -
     |                                     |
     |   /-----\                 /-----\   |
     |   |     |ppp0   //    ppp0|     |   |
eth0 |---|  A  |------//---------|  B  |---| eth0
     |   |     |     //          |     |   |
     |   \-----/                 \-----/   |
     |      \ ppp1             ppp1 /      |
     -       \                     /       -
              \                   /
               \                 /
                \               /
                 \             /
                  \           /
                   \         /
                    \       /
                     \     /
                  ppp0\   /ppp1
                     /-----\
                     |     |
                     |  C  |
                     |     |
                     \-----/
                        |eth0
                        |
                   |---------|
                   192.168.3.0 /
                      255.255.255.0
Nous avons trois routeurs A, B et C. Chacun supporte un segment Ethernet avec un réseau IP de classe C (masque de réseau 255.255.255.0). Chaque routeur a également une liaison PPP vers chacun des autres routeurs. Ce réseau forme un triangle.

Il est évident que la table de routage sur le routeur A ressemble à ceci :

root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
Cela fonctionnera bien jusqu'à ce que le lien entre A et B tombe en panne. Si cette liaison est défaillante, alors l'entrée de routage montre que les hôtes sur le segment A ne peuvent pas atteindre les hôtes sur le segment B car leurs datagrammes seront dirigés sur le lien ppp0 du routeur A qui est rompu. Ils pourront encore continuer à parler aux hôtes du segment C, et les hôtes du segment C pourront toujours parler à ceux du segment B car la liaison reste intacte.

Mais.., si A peut parler à C et si C peut toujours parler à B, pourquoi A ne routerait-il pas ses datagrammes pour B via C, et laisser ensuite C les envoyer à B ? C'est exactement le type de problèmes que les protocoles de routage dynamique comme RIP sont en mesure de résoudre. Si chacun des routeurs A, B et C utilisent un démon de routage (NdT: démon est une francisation familière du vocable informatique anglais daemon, qui signifie Disk And Extension MONitor, c'est à dire qui n'est pas invoqué manuellement mais attend en tâche de fond que quelque chose se passe, que quelque condition se produise. Ce terme fut introduit au départ sous CTSS (Compatible Time Sharing System), un ancêtre du système MULTICS, lui-même parent d'UNIX (voir la traduction de René Cougnenc de `Le système Linux' de M. Welsh et L. Kaufman chez O'Reilly International Thomson), alors leurs tables de routage seront automatiquement réglées pour refléter le nouvel état du réseau même si l'une des liaisons est défectueuse. Configurer un tel réseau est simple, sur chaque routeur vous devez seulement faire deux choses. Dans ce cas, pour le routeur A :

root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# /usr/sbin/routed
Le démon de routage `routed' trouve automatiquement tous les ports actifs vers le réseau quand il démarre et écoute tous les messages sur chacun des périphériques réseau ce qui lui permet de déterminer et de mettre à jour sa table de routage.

C'était une très brève explication du routage dynamique et de son utilisation. Si vous voulez d'avantage d'explications reportez-vous aux références listées en début de document.

Les points importants relatifs au routage dynamique sont :

  1. Vous n'avez besoin d'utiliser un démon de routage dynamique que quand votre machine Linux peut choisir entre plusieurs routes pour une destination donnée.
  2. Le démon de routage dynamique modifiera automatiquement votre table de routage pour tenir compte des changements survenus dans votre réseau.
  3. RIP est adapté aux réseaux de petite et moyenne taille.

5.8 Configurer vos serveurs réseau et les services.

Les serveurs de réseau et les services sont des programmes qui permettent à un utilisateur distant de devenir utilisateur de votre machine Linux. Les programmes serveurs sont à l'écoute des ports réseau. Les ports réseau permettent die demander un service particulier à un hôte particulier et de faire la différence entre une connexion telnet entrante et une connexion ftp entrante. L'utilisateur distant établit une connexion réseau avec votre machine puis le programme serveur, ou démon de réseau, à l'écoute du port, accepte la connexion et s'exécute. Il y a deux façons d'opérer pour les démons de réseau. Les deux sont couramment utilisés en pratique. Ce sont :

autonome

le programme démon écoute le port réseau désigné et lorsqu'il y a une connexion, il prend lui-même la connexion en charge pour fournir le service.

esclave du serveur inetd

le serveur inetd est un programme démon spécial spécialisé dans la conduite des connexions réseau. Il possède un fichier de configuration qui indique quel programme doit être utilisé lorsqu'une connexion entrante est reçue. Chacun des ports service doit être configuré soit avec le protocole tcp, soit avec le protocole udp. Les ports sont décrits dans un autre fichier dont nous parlerons plus tard.

Il y deux fichiers importants que vous devez configurer. Ce sont /etc/services qui assigne des noms aux numéros de port et /etc/inetd.conf qui sert pour la configuration du démon de réseau inetd .

/etc/services

Le fichier /etc/services est une simple base de données qui associe des noms compréhensibles par l'homme à des ports service compréhensibles par la machine. Son format est tout à fait simple. Le fichier est un fichier texte dont chaque ligne représente une entrée de la base de données. Chaque entrée comprend trois champs séparés par des caractères espace ou tabulation. Ces champs sont :

nom      port/protocole        alias     # commentaire
nom

un simple mot qui représente le service décrit.

port/protocole

ce champ est divisé en deux.

port

un nombre qui spécifie le numéro de port où le service désigné sera disponible. La plupart des services ont des numéros assignés. Ils sont décrits dans la RFC-1340.

protocole

c'est soit tcp soit udp.

Il est important de noter qu'une entrée comme 18/tcp est très différente de 18/udp et qu'il n'y a pas de raisons techniques que le même service existe sur les deux. Normalement le bon sens prévaut et c'est vraiment pour un service particulier disponible à la fois sur tcp et udp que vous verrez une entrée pour les deux..
alias

autre nom qui peut être utilisé pour désigner ce service.

Tout texte apparaissant après le caractère `#' est ignoré et traité comme commentaire.

Exemple de fichier /etc/services.

Toutes les distributions récentes de Linux fournissent un bon fichier /etc/services. Juste au cas où vous construiriez tout depuis le départ, voici une copie du fichier /etc/services fourni avec l'ancienne distribution Debian .

# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# Network services, Internet style
#
# Notez que c'est la politique actuelle de l'IANA d'assigner un seul numéro
# de port à la fois pour TCP et UDP; ainsi, la plupart des ports ont deux
#entrées même si le protocole ne supporte pas UDP.
# Mis à jour d'après la RFC 1340, ``Assigned Numbers'' (Juillet 1992). 
# Il n'y a pas tous les ports, seulement les plus courants.

tcpmux          1/tcp                           # TCP port service multiplexer
echo            7/tcp
echo            7/udp
discard         9/tcp           sink null
discard         9/udp           sink null
systat          11/tcp          users
daytime         13/tcp
daytime         13/udp
netstat         15/tcp
qotd            17/tcp          quote
msp             18/tcp                          # message send protocol
msp             18/udp                          # message send protocol
chargen         19/tcp          ttytst source
chargen         19/udp          ttytst source
ftp-data        20/tcp
ftp             21/tcp
ssh             22/tcp                          # SSH Remote Login Protocol
ssh             22/udp                          # SSH Remote Login Protocol
telnet          23/tcp
# 24 - private
smtp            25/tcp          mail
# 26 - non assigné
time            37/tcp          timserver
time            37/udp          timserver
rlp             39/udp          resource        # resource location
nameserver      42/tcp          name            # IEN 116
whois           43/tcp          nicname
re-mail-ck      50/tcp                          # Remote Mail Checking Protocol
re-mail-ck      50/udp                          # Remote Mail Checking Protocol
domain          53/tcp          nameserver      # name-domain server
domain          53/udp          nameserver
mtp             57/tcp                          # deprecated
bootps          67/tcp                          # BOOTP server
bootps          67/udp
bootpc          68/tcp                          # BOOTP client
bootpc          68/udp
tftp            69/udp
gopher          70/tcp                          # Internet Gopher
gopher          70/udp
rje             77/tcp          netrjs
finger          79/tcp
www             80/tcp          http            # WorldWideWeb HTTP
www             80/udp                          # HyperText Transfer Protocol
link            87/tcp          ttylink
kerberos        88/tcp          kerberos5 krb5  # Kerberos v5
kerberos        88/udp          kerberos5 krb5  # Kerberos v5
supdup          95/tcp
# 100 - reserve
hostnames       101/tcp         hostname        # usually from sri-nic
iso-tsap        102/tcp         tsap            # part of ISODE.
csnet-ns        105/tcp         cso-ns          # also used by CSO name server
csnet-ns        105/udp         cso-ns
rtelnet         107/tcp                         # Remote Telnet
rtelnet         107/udp
pop-2           109/tcp         postoffice      # POP version 2
pop-2           109/udp
pop-3           110/tcp                         # POP version 3
pop-3           110/udp
sunrpc          111/tcp         portmapper      # RPC 4.0 portmapper TCP
sunrpc          111/udp         portmapper      # RPC 4.0 portmapper UDP
auth            113/tcp         authentication tap ident
sftp            115/tcp
uucp-path       117/tcp
nntp            119/tcp         readnews untp   # USENET News Transfer Protocol
ntp             123/tcp
ntp             123/udp                         # Network Time Protocol
netbios-ns      137/tcp                         # NETBIOS Name Service
netbios-ns      137/udp
netbios-dgm     138/tcp                         # NETBIOS Datagram Service
netbios-dgm     138/udp
netbios-ssn     139/tcp                         # NETBIOS session service
netbios-ssn     139/udp
imap2           143/tcp                         # Interim Mail Access Proto v2
imap2           143/udp
snmp            161/udp                         # Simple Net Mgmt Proto
snmp-trap       162/udp         snmptrap        # Traps for SNMP
cmip-man        163/tcp                         # ISO mgmt over IP (CMOT)
cmip-man        163/udp
cmip-agent      164/tcp
cmip-agent      164/udp
xdmcp           177/tcp                         # X Display Mgr. Control Proto
xdmcp           177/udp
nextstep        178/tcp         NeXTStep NextStep       # NeXTStep window
nextstep        178/udp         NeXTStep NextStep       # server
bgp             179/tcp                         # Border Gateway Proto.
bgp             179/udp
prospero        191/tcp                         # Cliff Neuman's Prospero
prospero        191/udp
irc             194/tcp                         # Internet Relay Chat
irc             194/udp
smux            199/tcp                         # SNMP Unix Multiplexer
smux            199/udp
at-rtmp         201/tcp                         # AppleTalk routing
at-rtmp         201/udp
at-nbp          202/tcp                         # AppleTalk name binding
at-nbp          202/udp
at-echo         204/tcp                         # AppleTalk echo
at-echo         204/udp
at-zis          206/tcp                         # AppleTalk zone information
at-zis          206/udp
z3950           210/tcp         wais            # NISO Z39.50 database
z3950           210/udp         wais
ipx             213/tcp                         # IPX
ipx             213/udp
imap3           220/tcp                         # Interactive Mail Access
imap3           220/udp                         # Protocol v3
ulistserv       372/tcp                         # UNIX Listserv
ulistserv       372/udp
#
# services spécifiques à UNIX
#
exec            512/tcp
biff            512/udp         comsat
login           513/tcp
who             513/udp         whod
shell           514/tcp         cmd             # no passwords used
syslog          514/udp
printer         515/tcp         spooler         # line printer spooler
talk            517/udp
ntalk           518/udp
route           520/udp         router routed   # RIP
timed           525/udp         timeserver
tempo           526/tcp         newdate
courier         530/tcp         rpc
conference      531/tcp         chat
netnews         532/tcp         readnews
netwall         533/udp                         # -for emergency broadcasts
uucp            540/tcp         uucpd           # uucp daemon
remotefs        556/tcp         rfs_server rfs  # Brunhoff remote filesystem
klogin          543/tcp                         # Kerberized `rlogin' (v5)
kshell          544/tcp         krcmd           # Kerberized `rsh' (v5)
kerberos-adm    749/tcp                         # Kerberos `kadmin' (v5)
#
webster         765/tcp                         # Network dictionary
webster         765/udp
#
# D'après ``Assigned Numbers'' :
#
#> Les Ports Enregistrés ne sont pas contrôlés par l'IANA et peuvent être
#> utilisés sur la plupart des systèmes par des processus ordinaires
#> ou des programmes exécutés par des utilisateurs ordinaires.
#
#> Les ports sont utilisés dans le TCP [45,106] pour nommer les extrémités
#> des connexions logiques qui transportent les conversations de longue
#> durée. Pour offrir des services à des utilisateurs non connus, un port 
#> de service pour contact a été défini. Cette liste spécifie le port utilisé
#> par le processus serveur ainsi que son port de contact. Comme l'IANA ne peut
#> contrôler l'usage de ces ports, on donne ici une liste d'utilisation
#> de ces ports pour être agréable à la communauté.
#
ingreslock      1524/tcp
ingreslock      1524/udp
prospero-np     1525/tcp                # Prospero non-privileged
prospero-np     1525/udp
rfe             5002/tcp                # Radio Free Ethernet
rfe             5002/udp                # Actually uses UDP only
bbs             7000/tcp                # BBS service
#
#
# services Kerberos (Project Athena/MIT) 
# Notez que ceux-ci sont pour Kerberos v4, et ne sont pas officiels. Les sites
# tournant sous v4 doivent utiliser ceux-ci et annuler les entrées v5 ci-dessus.
#
kerberos4       750/udp         kdc     # Kerberos (server) udp
kerberos4       750/tcp         kdc     # Kerberos (server) tcp
kerberos_master 751/udp                 # Kerberos authentication
kerberos_master 751/tcp                 # Kerberos authentication
passwd_server   752/udp                 # Kerberos passwd server
krb_prop        754/tcp                 # Kerberos slave propagation
krbupdate       760/tcp         kreg    # Kerberos registration
kpasswd         761/tcp         kpwd    # Kerberos "passwd"
kpop            1109/tcp                # Pop with Kerberos
knetd           2053/tcp                # Kerberos de-multiplexor
zephyr-srv      2102/udp                # Zephyr server
zephyr-clt      2103/udp                # Zephyr serv-hm connection
zephyr-hm       2104/udp                # Zephyr hostmanager
eklogin         2105/tcp                # Kerberos encrypted rlogin
#
# Services non officiels mais nécessaires (pour NetBSD) 
#
supfilesrv      871/tcp                 # SUP server
supfiledbg      1127/tcp                # SUP debugging
#
# Services protocole de délivrance de datagrammes
#
rtmp            1/ddp                   # Routing Table Maintenance Protocol
nbp             2/ddp                   # Name Binding Protocol
echo            4/ddp                   # AppleTalk Echo Protocol
zip             6/ddp                   # Zone Information Protocol
#
# Services Debian GNU/Linux
rmtcfg          1236/tcp                # Gracilis Packeten remote config server
xtel            1313/tcp                # french minitel
cfinger         2003/tcp                # GNU Finger
postgres        4321/tcp                # POSTGRES
mandelspawn     9359/udp        mandelbrot      # network mandelbrot

# Services locaux

Dans la réalité, le fichier augmente toujours en taille au fur et à mesure que de nouveaux services apparaissent. Si vous craignez que votre copie soit incomplète, je vous suggère de copier un nouveau fichier /etc/services provenant d'une distribution récente.

/etc/inetd.conf

Le fichier /etc/inetd.conf est le fichier de configuration du serveur démon inetd . Il sert à dire à inetd ce qu'il doit faire lorsqu'il reçoit une demande de connexion pour un service particulier. Pour les services où vous acceptez une connexion vous devez dire à inetd quel démon serveur de réseau doit tourner, et comment.

Son format est aussi très simple. C'est un fichier texte dont chaque ligne décrit un service que vous voulez fournir. Tout texte suivant un `#' est ignoré et considéré comme commentaire. Chaque ligne contient sept champs séparés par un nombre quelconque d'espaces (espace ou tabulation). Le format général est comme suit :

service  type_de_socket  protocole  drapeaux  utilisateur  chemin  arguments
service

est le nom de service applicable à cette configuration, pris dans le fichier /etc/services.

type_de_socket

ce champ décrit le type de socket que cette entrée considère comme pertinent, les valeurs permises sont : stream, dgram, raw, rdm, ou seqpacket. C'est un peu technique par nature, mais par expérience, presque tous les services basés sur tcp utilisent stream et presque tous les services basés sur udp utilisent dgram. Il n'y a que quelques types de serveurs démons spéciaux utilisant d'autres valeurs.

protocole

le protocole considéré comme valide pour cette entrée. Il doit correspondre à l'entrée appropriée dans le fichier /etc/services et sera donc soit tcp soit udp. Les serveurs basés sur Sun RPC (Remote Procedure Call) utilisent rpc/tcp ou rpc/udp.

drapeaux

il n'y a en fait que deux valeurs pour ce champ. Celles-ci disent à inetd si le programme serveur réseau libère le socket aprés démarrage, et donc si inetd peut prendre en compte une des prochaines demandes de connexion, ou bien si inetd doit attendre qu'un autre démon serveur tournant déjà prenne en charge la nouvelle demande de connexion. C'est encore compliqué, mais en pratique tous les serveurs tcp doivent avoir cette entrée positionnée sur nowait et la plupart des serveurs udp ont cette entrée positionnée sur wait. Attention il y a quelques exceptions notables, laissez vous guider par l'exemple suivant si vous n'êtes pas sûrs.

utilisateur

ce champ décrit quel compte utilisateur extrait de /etc/passwd sera considéré comme propriétaire du démon réseau lorsqu'il est lancé. C'est très utile lorsque vous voulez vous protéger contre les trous de sécurité. Vous pouvez mettre nobody comme utilisateur pour une entrée si bien que dans le cas où le réseau comporte une brèche, les dommages éventuels seront minimisés. Cependant habituellement ce champ est réglé sur root, car beaucoup de serveurs ont besoin des privilèges de root pour tourner correctement.

chemin_de_serveur

ce champ est le chemin réel du programme à exécuter pour cette entrée.

arguments

ce champ correspond au reste de la ligne et est optionnel. Il sert à indiquer les arguments de commande que vous voulez passer au programme serveur au lancement.

Exemple de fichier /etc/inetd.conf

Comme pour le fichier /etc/services, toutes les distributions modernes incluent un bon fichier /etc/inetd.conf pour pouvoir travailler. Ici, pour être complet , vous trouverez le fichier /etc/inetd.conf de la distribution Debian.

# /etc/inetd.conf:  voir inetd(8) pour d'autres informations.
#
# Base de données pour la configuration d'un serveur Internet 
#
#
# Modifié pour Debian par Peter Tobias <tobias@et-inf.fho-emden.de>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Services internes
#
#echo           stream  tcp     nowait  root    internal
#echo           dgram   udp     wait    root    internal
discard         stream  tcp     nowait  root    internal
discard         dgram   udp     wait    root    internal
daytime         stream  tcp     nowait  root    internal
daytime         dgram   udp     wait    root    internal
#chargen        stream  tcp     nowait  root    internal
#chargen        dgram   udp     wait    root    internal
time            stream  tcp     nowait  root    internal
time            dgram   udp     wait    root    internal
#
# Services standards.
#
telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.telnetd
ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.ftpd
#fsp    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.fspd
#
# Shell, login, exec et talk sont des protocoles BSD.
#
shell   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd
login   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind
#exec   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rexecd
talk    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.talkd
ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.ntalkd
#
# Services Mail, news et uucp.
#
smtp    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.smtpd  
#nntp   stream  tcp     nowait  news    /usr/sbin/tcpd  /usr/sbin/in.nntpd
#uucp   stream  tcp     nowait  uucp    /usr/sbin/tcpd  /usr/lib/uucp/uucico
#comsat dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.comsat
#
# Pop et autres
#
#pop-2  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop2d
#pop-3  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop3d
#
# `cfinger' est le serveur finger GNU de Debian.  (NOTE : L'implémentation
# habituelle du démon `finger' permet de le faire tourner avec `root'.)
#
#cfinger stream tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.cfingerd
#finger stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.fingerd
#netstat        stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/netstat
#systat stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/ps -auwwx
#
# Le service tftp est fourni principalement pour démarrer. La plupart des sites
# l'utilisent seulement sur les machines servant de `serveurs de boot'.
#
#tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd
#tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd /boot
#bootps dgram   udp     wait    root    /usr/sbin/bootpd        bootpd -i -t 120
#
# Services Kerberos (ils doivent probablement être corrigés)
#
#klogin         stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k
#eklogin        stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k -x
#kshell         stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd -k
#
# Services tournant UNIQUEMENT sur Kerberos (doivent être probablement corrigés)
#
#krbupdate      stream tcp      nowait  root    /usr/sbin/tcpd  /usr/sbin/registerd
#kpasswd        stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/kpasswdd
#
# Services RPC
#
#mountd/1       dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.mountd
#rstatd/1-3     dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rstatd
#rusersd/2-3    dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rusersd
#walld/1        dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rwalld
#
# Fin de inetd.conf.
ident           stream  tcp     nowait  nobody  /usr/sbin/identd       identd -i

5.9 Autres fichiers de configuration ayant un rapport avec le réseau

Il y a beaucoup de fichiers relatifs à la configuration réseau sous Linux susceptibles de vous intéresser. Vous n'aurez jamais à modifier ces fichiers, mais il est utile de les décrire pour que vous sachiez ce qu'ils contiennent et quelle est leur utilité.

/etc/protocols

Le fichier /etc/protocols est une base de données qui donne la relation des numéros id de protocole avec leurs noms. Il est utilisé par les programmeurs pour leur permettre de spécifier les protocoles par leur nom dans les programmes et aussi par quelques programmes tels que tcpdump pour pouvoir afficher en sortie des noms au lieu de chiffres. La syntaxe générale de ce fichier est :

nom du protocole     numéro    alias

Le fichier /etc/protocols fourni avec la distribution Debian est le suivant :

# /etc/protocols:
# $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# Protocoles Internet (IP) 
#
#       d'après: @(#)protocols   5.1 (Berkeley) 4/17/89
#
# Mise à jour pour NetBSD basee sur la RFC 1340, Assigned Numbers (July 1992).

ip      0       IP              # internet protocol, pseudo protocol number
icmp    1       ICMP            # internet control message protocol
igmp    2       IGMP            # Internet Group Management
ggp     3       GGP             # gateway-gateway protocol
ipencap 4       IP-ENCAP        # IP encapsulated in IP (officially ``IP'')
st      5       ST              # ST datagram mode
tcp     6       TCP             # transmission control protocol
egp     8       EGP             # exterior gateway protocol
pup     12      PUP             # PARC universal packet protocol
udp     17      UDP             # user datagram protocol
hmp     20      HMP             # host monitoring protocol
xns-idp 22      XNS-IDP         # Xerox NS IDP
rdp     27      RDP             # "reliable datagram" protocol
iso-tp4 29      ISO-TP4         # ISO Transport Protocol class 4
xtp     36      XTP             # Xpress Tranfer Protocol
ddp     37      DDP             # Datagram Delivery Protocol
idpr-cmtp       39      IDPR-CMTP       # IDPR Control Message Transport
rspf    73      RSPF            # Radio Shortest Path First.
vmtp    81      VMTP            # Versatile Message Transport
ospf    89      OSPFIGP         # Open Shortest Path First IGP
ipip    94      IPIP            # Yet Another IP encapsulation
encap   98      ENCAP           # Yet Another IP encapsulation

/etc/networks

Le fichier /etc/networks a une fonction similaire au fichier /etc/hosts. Il fournit une simple base de données de noms de réseau avec des adresses. Son format diffère en ce qu'il n'y a que deux champs par ligne, et que ces champs sont codés comme ceci :

 Nom du réseau   adresse de réseau
Un exemple :
loopnet    127.0.0.0
localnet   192.168.0.0
amprnet    44.0.0.0

Lorsque vous utilisez une commande comme route, si une destination est un réseau, et que ce réseau a une entrée dans le fichier /etc/networks la commande affichera alors le nom du réseau en lieu et place de son adresse.

5.10 Sécurité réseau et contrôle d'accès

Laissez-moi débuter ce paragraphe en vous mettant en garde que la sécurisation de votre machine et du réseau contre les attaques pernicieuses est un art complexe. Je ne me considère pas du tout comme un expert dans ce domaine et bien que les mécanismes que je vais décrire puissent vous aider, si vous êtes préoccupés par la sécurité, alors je vous recommande d'effectuer vous-même des recherches sur le sujet. Il existe beaucoup de bonnes références sur l'Internet qui traitent du sujet, y compris Security-HOWTO

Une importante règle pratique est : `N'utilisez pas de serveurs dont vous n'avez pas l'utilité'. Beaucoup de distributions arrivent avec plein de services configurés et démarrant automatiquement. Pour assurer quand même un minimum de sécurité vous devriez aller dans votre fichier /etc/inetd.conf et retirez (placez un `#' au début de la ligne) toute entrée que vous ne comptez pas utiliser. De bons candidats sont : shell, login, exec, uucp, ftp, et les services informatifs tels que finger, netstat and systat.

Il y a plein de sortes de sécurité et de mécanismes de contrôle d'accès ; je vais décrire les plus élémentaires.

/etc/ftpusers

Le fichier /etc/ftpusers est un mécanisme simple qui vous permet d'interdire l'accès de votre machine à certains utilisateurs de ftp. Il est lu par le programme démon (ftpd) lorsqu'une connexion ftp est reçue. Le fichier est une simple liste d'utilisateurs qui ne peuvent pas se connecter. Il ressemble à :

# /etc/ftpusers - utilisateurs ne pouvant pas se connecter par ftp
root
uucp
bin
mail

/etc/securetty

Le fichier /etc/securetty vous permet de spécifier sur quels fichiers de périphériques tty root a le droit de se connecter. Le fichier /etc/securetty est lu par le programme de connexion (habituellement /bin/login). Son format est une liste de fichiers de périphériques tty autorisés (sur tous les autres root ne peut se connecter) :

# /etc/securetty - consoles ou root peut se connecter
tty1
tty2
tty3
tty4

Le mécanisme de contrôle d'accès des hôtes tcpd.

Le programme tcpd que vous avez vu dans le fichier /etc/inetd.conf fournit les mécanismes de contrôle d'accès et de connexion aux services qu'il a pour but de protéger.

Lorsqu'il est invoqué par le programme inetd, il lit deux fichiers contenant les règles d'accès et il autorise ou interdit l'accès au serveur qu'il protège.

Il cherche dans ces deux fichiers jusqu'à ce qu'il trouve une correspondance. S'il n'en trouve pas il suppose que l'accès est autorisé. Il recherche dans l'ordre suivant : /etc/hosts.allow, /etc/hosts.deny. Je décrirai chacun d'eux plus tard. Pour une description complète référez-vous aux pages de manuel appropriées (hosts_access(5) est un bon point de départ).

/etc/hosts.allow

Le fichier /etc/hosts.allow est un fichier de configuration du programme /usr/sbin/tcpd. Il contient les hôtes dont l'accès est autorisé (allowed) et qui peuvent donc utiliser un service de votre machine.

Le format du fichier est très simple :

# /etc/hosts.allow
#
# <liste des services>: <liste des hôtes> [: commande]
liste des services

c'est une liste de serveurs, séparés par des virgules, auxquels les règles d'accès s'appliquent. Exemples de serveur : ftpd, telnetd, et fingerd.

liste des hôtes

c'est une liste de noms d'hôtes, séparés par des virgules (vous pouvez utiliser également des adresses IP). Vous pouvez en plus spécifier des noms d'hôtes ou des adresses IP avec des jokers pour obtenir des groupes d'hôtes. Des exemples : gw.vk2ktj.ampr.org pour un hôte spécifique, .uts.edu.au pour tous les hôtes se terminant par cette chaîne , 44. pour toutes les adresses IP commençant par ces chiffres. Il y a quelques expressions pour simplifier la configuration, parmi lesquelles : ALL pour tous les hôtes, LOCAL pour tout hôte dont le nom ne contient pas de `.' c'est à dire appartenant au même domaine que votre machine, et PARANOID pour tout hôte dont le nom ne correspond pas avec son adresse (tricherie dans le nom). Il y a enfin une expression qui peut être utile. Il s'agit de EXCEPT qui vous permet de fournir une liste avec des exceptions. Nous verrons un exemple plus tard.

commande

c'est un paramètre optionnel. Ce paramètre est le nom complet d'une commande (avec son répertoire) qui sera exécutée chaque fois qu'il y aura correspondance. Ce peut être par exemple une commande qui essaiera d'identifier qui se connecte, ou de générer un message par courrier ou tout message d'alerte pour l'administrateur système avertissant que quelqu'un est en train de se connecter. On peut y inclure des extensions, par exemple : %h donnera le nom de l'hôte qui se connecte ou bien son adresse s'il n'a pas de nom , %d le programme démon appelé.

Un exemple :

# /etc/hosts.allow
#
# Permet a tout le monde d'utiliser le courrier
in.smtpd: ALL
# telnet et ftp pour les hotes de mon domaine et my.host.at.home.
telnetd, ftpd: LOCAL, myhost.athome.org.au
# finger pour tout le monde, mais garde une trace de l'identite.
fingerd: ALL: (finger @%h | mail -s "finger from %h" root)

/etc/hosts.deny

Le fichier /etc/hosts.deny est un fichier de configuration du programme /usr/sbin/tcpd. Ce fichier contient les hôtes qui n'ont pas l'autorisation d'accéder à l'un des services de votre machine.

Un exemple simple ressemblerait à ceci :

# /etc/hosts.deny
#
# Interdit l'acces aux hotes ayant des noms suspects
ALL: PARANOID
#
# Interdit l'acces a tous les hotes
ALL: ALL
L'entrée PARANOID est en fait redondante car l'autre entrée interdit tous les cas. L'une ou l'autre entrée devrait convenir, en fonction de vos besoins particuliers.

Mettre ALL: ALL par défaut dans le fichier /etc/hosts.deny puis autoriser certains services, en liaison avec les hôtes que vous avez choisis, dans le fichier /etc/hosts.allow, est la configuration la plus sûre.

/etc/hosts.equiv

Le fichier hosts.equiv est utilisé pour concéder à certains hôtes des droits d'accès leur permettant d'avoir un compte sur votre machine sans fournir de mot de passe. Cela est utile dans un environnement sécurisé où vous contrôlez toutes les machines, sinon ce peut être très risqué. Votre machine est aussi sûre que le moins sûr de vos hôtes de confiance. Pour augmenter la sécurité, n'utilisez pas cette possiblité et encouragez vos utilisateurs à ne pas utiliser le fichier .rhosts.

Configurer votre démon ftp correctement

Beaucoup de sites sont intéressés à avoir un serveur ftp anonyme pour permettre aux autres de transférer et de récupérer des fichiers sans avoir besoin d'une identification spéciale. Si vous décidez d'offrir ce service soyez certains de configurer votre démon ftp de manière adéquate pour les accès anonymes. La plupart des pages de manuel dédiées à ftpd(8) décrivent tous les détails pour y arriver. Vous devez toujours vous assurer que vous avez bien suivi les instructions. Un règle importante est de ne pas utiliser une copie de votre fichier /etc/passwd dans le répertoire /etc du compte anonyme. Soyez sûrs d'avoir éliminé tous les détails des comptes exceptés ceux qui sont nécessaires, autrement vous serez vulnérables vis à vis de ceux qui maîtrisent les techniques de mise en pièces des mots de passe.

Pare-feu (Firewall) sur le réseau

Ne pas permettre aux datagrammes d'atteindre votre machine ou les serveurs est un excellent moyen de sécurisation. Ceci est abordé en profondeur dans Firewall-HOWTO et (de manière plus concise) plus loin dans ce document.

Autres suggestions

Voici d'autres suggestions, potentiellement religieuses, à prendre en considération :

sendmail

en dépit de sa popularité, le démon sendmail apparaît avec une effrayante régularité dans les mises en garde concernant la sécurité. Faites comme vous voulez, mais j'ai choisi de ne pas l'utiliser.

NFS et autres services Sun RPC

soyez circonspects avec eux. Il y a toutes sortes d'exploits possibles avec ces services. Il est difficile de trouver une option pour les services tels que NFS, mais si vous les configurez, soyez prudents envers ceux à qui vous accordez des droits.


Page suivante Page précédente Table des matières