Réseau sous Linux (anciennement NET-3-HOWTO).: Informations générales concernant la configuration réseau
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 (Optionnel).
À noter:
La majorité des distributions actuelles sont livrées avec l'option réseau
activée, en sorte que vous n'avez pas besoin de recompiler le noyau. Si vous
utilisez du matériel bien connu, tout ira bien. Par exemple: cartes 3COM,
cartes NE2000 ou cartes Intel. Cependant si vous devez recompiler le noyau,
voyez les informations qui suivent.
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.
Pour les utilisateurs des principales distributions comme RedHat, Caldera,
Debian ou Suse, ce n'est plus vrai. Tant que vous restez avec un matériel
de grande diffusion, il n'est pas nécessaire de recompiler le noyau, à moins que
vous n'ayez une exigence très spécifique.
Vous pouvez toujours obtenir les sources du dernier noyau sur :
ftp.cdrom.com.
Ce n'est pas le site officiel mais ils ont BEAUCOUP de bande passante et
BEAUCOUP d'utilisateurs peuvent se connecter en même temps. Le site officiel
est kernel.org, mais dans la mesure du possible, utilisez s'il vous plaît celui
que je viens de donner.
Souvenez-vous que ftp.kernel.org est particulièrement surchargé. Utilisez un
miroir.:
(NdT : et bien sûr
ftp.lip6.fr) .
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.
Vous pouvez également obtenir les derniers paquetages RedHat sur
net-tools-1.51-3.i386.rpm 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 :
Ou avec les paquetages Redhat:
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 et ont été remplacées par ipchains dans la version 2.2 du noyau.
ipfwadm ne s'applique donc qu'aux versions 2.0 du noyau. Ce qui
suit ne s'applique donc qu'aux distributions ayant la version 2.0 ou antérieure.
Pour installer et configurer la version existante au moment de l'écriture de
ce document, vous devez lire le document howto IPchains situé sur
Le projet de Documentation Linux.
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. Si
vous désirez plus d'informations détaillées sur ipchains, référez-vous au document mentionné ci-dessus.
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.
Adresses et explications.
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 :
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 :
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 :
- Adresse hôte;
- Adresse réseau;
- Adresse de diffusion;
- Masque de réseau;
- Adresse de routage;
- Adresse du serveur de noms de domaine (DNS).
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 :
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 :
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 :
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.
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 :
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 :
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.
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).
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 :
ou bien en utilisant l'une des commandes suivantes :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
- 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. C'est la cas par exemple
lorsque vous envisagez d'utiliser IP masquerade.
- Le démon de routage dynamique modifiera automatiquement votre
table de routage pour tenir compte des changements
survenus dans votre réseau.
- 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
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 .
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
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.
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 :
Le fichier /etc/protocols fourni avec la distribution
Debian est le suivant :
/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 :
Un exemple :
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/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) :
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 :
liste des servicesc'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ôtesc'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.
commandec'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.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 :
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.
[22 février 2002, JDNet]
|
