Guide d'installation et de configuration de Linux

Un réseau n'est en général rien d'autre qu'une interconnexion entre plusieurs machines qui leur permet d'échanger des informations. Il existe de nombreux moyens de réaliser cette interconnexion, qui utilisent parfois des supports physiques variés. Les techniques les plus utilisées sont la liaison radio et la liaison par câble. Cette dernière technique comprend diverses variantes, dont les réseaux Ethernet, TokenRing et simplement la liaison téléphonique.

Il est évident que la manière d'envoyer et de recevoir des informations est différente pour ces différents supports physiques, parce qu'elle dépend tout simplement des possibilités techniques offertes par la technologie sous-jacente utilisée. Cependant, il est très courant de découper les informations à échanger en paquets, qui sont ensuite transmis sur le réseau. Ces paquets peuvent être de tailles variées, et contenir des informations utiles à la gestion du réseau. L'information la plus importante est sans doute celle permettant de connaître la machine destinataire du paquet. On l'appelle l'adresse de la machine cible, il s'agit généralement d'un numéro permettant de l'identifier de manière unique sur le réseau. En général, les paquets contiennent également l'adresse de la machine source, afin qu'une réponse puisse lui être envoyée.

Du fait de la diversité des supports physiques de réseau, il n'est pas simple d'écrire une application réseau qui puisse travailler dans des environnements réseau hétérogènes. Cela supposerait de connaître les protocoles de communication pour chaque type de réseau, ce qui compliquerait à l'infini le moindre programme et le rendrait inutilisable avec les nouveaux réseaux. Par conséquent, cette tâche ingrate a été reléguée au plus profond des couches réseau spécifiques au support physique. Les applications quant à elles utilisent un protocole de communication plus évolué, dont le but est d'assurer l'interopérabilité des différents supports physiques. Ce protocole utilise toujours des paquets et une notion d'adresse, mais cette fois ces informations sont standardisées et utilisables par toutes les applications. Les paquets de ce protocole sont stockés dans les paquets des réseaux physiques et transmis tels quels. Ils peuvent éventuellement être découpés en sous-paquets dans le cas où la taille des paquets du réseau serait trop petite pour les contenir. Cette technique s'appelle l'encapsulation d'un protocole dans un autre protocole.

Les machines Unix utilisent toutes le protocole de communication de bas niveau IP (« Internet Protocol »). Ce protocole a été inventé pour permettre l'interconnexion d'un grand nombre de réseaux physiques différents (le nom d'Internet provient d'ailleurs de cette caractéristique : « INTERconnected NETworks »). Il permet de transmettre des informations de manière uniforme sur tous ces réseaux physiques. Ainsi, les programmes qui utilisent IP ne voient pas les spécificités des différents réseaux physiques. Pour eux, il ne semble y avoir qu'un seul réseau physique, dont le protocole de communication de base est IP. Autrement dit, les applications qui utilisent le réseau se contentent d'utiliser le protocole IP, et n'ont plus à se soucier de la manière dont il faut formater et transmettre les informations sur chaque support physique du réseau. Ce genre de détail est laissé aux couches réseau de chaque machine et aux passerelles reliant les divers réseaux physiques.

Comme il l'a déjà été dit ci-dessus, le protocole IP utilise des adresses pour identifier les machines sur les réseaux. Les adresses IP sont codées sur quatre octets (nombres binaires à huit chiffres, permettant de représenter des valeurs allant de 0 à 255), chacun définissant une partie du réseau. Ces adresses sont utilisées un peu comme les numéros de téléphone : le premier octet définit le numéro d'un « super-réseau » dans lequel le correspondant se trouve (ces « super-réseaux » sont appelés les réseaux de classe A), le deuxième octet définit le numéro du sous-réseau dans le super-réseau (ces sous-réseaux sont appelés réseaux de classe B), le troisième octet définit encore un sous-sous-réseau (réseaux dits de classe C) et le quatrième octet donne le numéro de la machine dans ce sous-sous-réseau.

Cette numérotation permet d'affecter des adresses similaires pour les différentes machines d'un réseau, et de simplifier ainsi la gestion de ce dernier. Elle dispose en revanche d'un inconvénient majeur : beaucoup d'adresses sont gaspillées, car il n'y a pas suffisamment de réseaux de classe A d'une part, et qu'on ne peut pas mélanger les machines de deux sous-réseaux dans un même réseau de classe A d'autre part. Si l'on reprend la comparaison avec les numéros de téléphone, il y a énormément d'abonnés dont le numéro commence par 01, mais beaucoup moins dont le numéro commence par 02, et quasiment aucun dont le numéro commence par 08. Si l'on venait à manquer de place dans la liste des numéros commençant par 01, on ne pourrait pas pour autant utiliser les numéros commençant par 02 pour des raisons géographiques. C'est la même chose pour les adresses IP, sauf que les zones géographiques sont remplacées par des sous-réseaux. Le problème est que, malheureusement, on commence à manquer d'adresses disponibles (alors qu'il y en a plein de libres, mais inutilisables parce qu'elles se trouvent dans d'autres sous-réseaux !). Il va donc falloir effectuer une renumérotation d'ici peu, exactement comme il y en a déjà eu dans le monde de la téléphonie…

Note : Le protocole IPv6, qui remplacera le protocole IP classique (encore appelé IPv4), a pour but de résoudre les limitations du protocole IP utilisé actuellement. Les adresses du protocole IPv6 sont codées sur 16 octets, ce qui résoudra définitivement le problème du manque d'adresses. De plus, les services modernes que sont l'authentification de l'émetteur, ainsi que la qualité de service (c'est-à-dire la garantie du délai de transmission des données, garantie nécessaire pour transmettre de façon correcte les flux multimédias tels que le son et la vidéo en temps réel) sont fournis par IPv6. Bien entendu, Linux est déjà capable d'utiliser IPv6 (combien de systèmes peuvent aujourd'hui l'affirmer ?) ! Notez toutefois que pour cela, il faut recompiler le noyau et toutes les applications réseau du système, ce qui est tout de même très lourd. Par conséquent, il vaut mieux se contenter du protocole IP actuel. Malgré ses limitations, ce protocole reste sans doute le meilleur protocole réseau du monde, car il allie souplesse et fonctionnalité. Il est difficilement concevable de créer un réseau aussi grand qu'Internet avec les autres protocoles existant sur le marché…

Les adresses IP sont donc parfaitement définies à l'aide de leurs quatre nombres, que l'on note les uns à la suite des autres et en les séparant d'un point. Comme on l'a vu, les adresses IP sont classées en sous-réseaux, de classe A, B et C. Les adresses des réseaux de classe C ont leurs trois premiers nombres fixés, et seul le quatrième nombre change pour chaque machine du réseau. De la même manière, les réseaux de classe B ont leurs deux premiers nombres fixés, et seuls les deux derniers nombres permettent de distinguer les différentes machines du réseau. Enfin, les réseaux de classe A n'ont de fixé que leur première composante, les autres sont libres. Il est donc clair qu'il existe peu de réseaux de classe A, mais que ce sont de très gros réseaux (ils peuvent contenir jusqu'à 16 millions de machines !). En revanche, il existe beaucoup plus de réseaux de classe C, dont la taille est plus modeste (seulement 256 machines).

Pour un réseau donné, les adresses ont donc toutes la même forme. Les premiers octets des adresses du réseau sont toujours les mêmes (ce peut être le premier octet pour les réseaux de classe A, les deux premiers pour les réseaux de classe B ou les trois premiers pour les réseaux de classe C). On peut donc définir la notion d'adresse de réseau, qui est l'adresse IP d'une machine du réseau dont les parties variables ont pour valeur 0. Par exemple, si une machine d'un réseau de classe C a pour adresse 192.168.1.15, alors l'adresse de son sous-réseau est 192.168.1.0. Cela signifie que toutes les machines de ce réseau auront une adresse de la forme « 192.168.1.xxx ».

Un réseau n'appartient qu'à une et une seule classe. Les adresses IP sont réparties sur les différentes classes de réseaux, selon la valeur des bits de poids fort de leur premier octet. Par exemple, les réseaux de classe A sont identifiables au fait que le bit de poids fort de leur adresse est nul. Les adresses de réseau valides pour les réseaux de ce type sont donc les adresses comprises entre 0.0.0.0 et 127.0.0.0. Il n'existe donc que 128 réseaux de classes A en tout et pour tout. Les autres réseaux ont donc le bit de poids fort de leur adresse fixé à 1, et c'est le deuxième bit de poids fort qui est utilisé pour distinguer les réseaux de classe B des autres. Les réseaux de classe B utilisent toujours la valeur 0 pour ce bit, leurs adresses varient donc entre 128.0.0.0 et 191.255.0.0. De même, les réseaux de classe C utilisent la valeur 1 pour le deuxième bit de leur adresse, et ont nécessairement un troisième bit nul. Leurs adresses vont donc de 192.0.0.0 à 223.255.255.0. Les adresses pour lesquelles le troisième bit (en plus des deux premiers) est à 1 sont réservées (soit pour une utilisation ultérieure, soit pour s'adresser à des groupes d'ordinateurs en multicast) et ne doivent pas être utilisées. Il s'agit des adresses 224.0.0.0 à 255.255.255.255. Cette dernière adresse a une signification spéciale et permet de s'adresser à tous les ordinateurs d'un réseau.

Il est possible de déterminer l'adresse du réseau auquel une machine appartient en utilisant ce qu'on appelle le masque de sous-réseau. Le masque de sous-réseau est une série de quatre nombres ayant le même format que les autres adresses IP, mais dont les composantes ne peuvent prendre que la valeur 0 ou la valeur 255, les 255 devant nécessairement apparaître en premier. Les composantes des adresses IP qui correspondent à la valeur 255 dans le masque de sous-réseau font partie de l'adresse dudit sous-réseau. Les composantes qui correspondent à la valeur 0 dans le masque de sous-réseau n'en font pas partie, et varient pour chaque machine du réseau. Pour reprendre l'exemple précédent, si une machine a pour adresse IP 189.113.1.15 et que son masque de sous-réseau est 255.255.255.0, alors l'adresse de son réseau est 189.113.1.0. Si le masque de sous-réseau avait été 255.255.0.0 (typiquement le masque d'un réseau de classe B), l'adresse du réseau aurait été 189.113.0.0. Comme on le voit, le masque de sous-réseau est utilisé par le système pour déterminer rapidement l'adresse de sous-réseau d'une machine à partir de son adresse IP. On notera que certaines combinaisons d'adresses IP et de masques de sous-réseau sont invalides. Par exemple, les adresses affectées aux réseaux de classe C (comme 192.168.0.1 par exemple) ne peuvent pas avoir de masque de sous-réseau en 255.255.0.0, car cela impliquerait que cette adresse serait une adresse de réseau de classe B.

Les adresses IP ne sont pas attribuées aux machines au hasard. Il est évident que chaque machine doit avoir une adresse unique, et que son adresse doit appartenir à la plage d'adresses utilisée pour le sous-réseau dont elle fait partie. Pour cela, les classes de réseau, ainsi que les adresses qu'ils utilisent, sont attribuées par l'IANA, un organisme de gestion de l'Internet. Le rôle de l'IANA (abréviation de l'anglais « Internet Assigned Numbers Authority ») est essentiellement d'assurer l'unicité des adresses IP sur l'Internet. Cependant, certaines adresses sont librement utilisables pour les réseaux locaux qui ne sont pas connectés directement à l'Internet. Les paquets utilisant ces adresses sont assurés de ne pas être transmis sur Internet. Ces adresses peuvent donc être utilisées par quiconque. Les plages d'adresse réservées sont les suivantes :

Tableau 9-1. Plages d'adresses IP réservées pour un usage personnel

Ainsi, un réseau de classe A (d'adresse 10.0.0.0), 16 réseaux de classe B (les réseaux 172.16.0.0 à 172.31.0.0) et 255 réseaux de classe C (d'adresses 192.168.0.0 à 192.168.255.0) sont disponibles. Vous pouvez donc les utiliser librement.

Il est également possible de configurer les machines pour qu'elles récupèrent leurs adresses IP auprès d'un serveur à l'aide du protocole DHCP (abréviation de l'anglais « Dynamic Host Configuration Protocol »). Cette technique est très intéressante quand on dispose d'un grand nombre de machines qui ne sont pas toujours toutes connectées à un réseau. Il est donc possible de redistribuer les adresses IP d'un stock d'adresses en fonction des machines qui se connectent, et d'économiser ainsi les précieuses adresses. En revanche, elle n'est pas appropriée pour les serveurs qui sont couramment accédés par des postes clients, et qui doivent donc avoir une adresse IP fixe.

Certaines adresses IP ont une signification particulière et ne peuvent pas être attribuées à une machine. Par exemple l'adresse 127.0.0.1 représente, pour une machine, elle-même. Cette adresse est souvent utilisée pour accéder à un programme réseau sur la machine locale. Elle fait partie du sous-réseau de classe A 127.0.0.0, qui ne comprend pas d'autres adresses. De plus, les adresses dont les derniers nombres (c'est-à-dire les nombres qui ne font pas partie de l'adresse du réseau) se terminent par 0 ou 255 sont réservées pour l'envoi des paquets à destination de tout le monde sur le réseau (émission dite « broadcast »). Par exemple, les adresses 192.168.1.0 et 192.168.1.255 ne peuvent pas être affectées à une machine. Ce sont typiquement ces adresses qui sont utilisées par le protocole DHCP pour émettre des requêtes sur le réseau alors que la machine n'a pas encore d'adresse fixe.

Il est important de savoir que, par défaut, une machine ne communiquera qu'avec les machines de son propre réseau. C'est-à-dire que si une machine utilise l'adresse IP 192.168.1.15 et que son masque de sous-réseau est 255.255.255.0, elle ne pourra contacter que des machines dont l'adresse est de la forme 192.168.1.xxx. Elle ne pourra donc pas voir par exemple une machine dont l'adresse IP est 192.168.0.2. Cela ne signifie pas que l'on doive toujours utiliser le masque 0.0.0.0 pour voir toutes les machines du monde, mais plutôt que la machine 192.168.0.2 ne fait pas partie, a priori, du même réseau physique que la machine 192.168.1.15. Il est donc inutile de chercher à la contacter (et mettre le masque de sous-réseau à 0.0.0.0 ne résoudrait évidemment pas le problème). Cependant, si deux réseaux physiques ont nécessairement deux adresses de réseau différentes, rien n'empêche de définir, sur un même réseau, plusieurs réseaux logiques. Ainsi, une même carte réseau peut avoir plusieurs adresses IP. La communication avec les machines des différents réseaux logiques se fait alors par l'intermédiaire de la même interface réseau.

Arrivé à ce stade des explications, je sens venir la question suivante : « ?! Euhhh… Mais alors, comment peut-on voir les machines sur Internet ? Je n'ai pas de réseau, et quand je me connecte à Internet, je peux y accéder ! Et même si j'avais un réseau, elles ne feraient certainement pas partie de mon réseau… ».

Explications :

• premièrement, vous avez un réseau, même si vous ne le savez pas. Toute machine appartient généralement au moins à son propre réseau virtuel, sur laquelle elle est la seule machine, et où elle a l'adresse 127.0.0.1 ;
• deuxièmement, effectivement, les machines qui se trouvent sur Internet n'appartiennent pas à votre réseau, que celui-ci existe effectivement ou soit virtuel ;
• troisièmement, toutes les informations que vous envoyez et recevez transitent par un seul ordinateur, celui de votre fournisseur d'accès à Internet. C'est cet ordinateur qui se charge de faire le transfert de ces informations vers les machines situées sur Internet.

C'est donc ici qu'intervient la notion de passerelle (« Gateway » en anglais).

Une passerelle est une machine qui appartient à deux réseaux physiques distincts, et qui fait le lien entre les machines de ces deux réseaux. Les ordinateurs des deux réseaux peuvent communiquer avec la passerelle de part et d'autre, puisqu'elle appartient aux deux réseaux. Les ordinateurs de chaque réseau transmettent à cette passerelle tous les paquets qui ne sont pas destinés à une machine de leur propre réseau. Celle-ci se charge simplement de transférer ces paquets aux machines de l'autre réseau.

Lorsque vous vous connectez à Internet, vous ne faites rien d'autre que de créer un réseau (dont le support physique est la ligne téléphonique), et vous utilisez l'ordinateur que vous avez appelé comme passerelle par défaut. Tous les paquets destinés à un autre réseau que le vôtre (donc, en pratique, tous les paquets si vous n'avez pas de réseau local) sont donc envoyés sur le réseau constitué de votre connexion à Internet et arrivent donc chez votre fournisseur d'accès, qui se charge ensuite de les transmettre aux autres ordinateurs. Notez que celui-ci peut transmettre ces paquets à une autre passerelle à laquelle il a accès et ainsi de suite, jusqu'à ce que la destination soit atteinte.

Dans le cas d'un particulier, le choix du réseau sur lequel les paquets doivent être transmis est très facile à faire puisqu'en général un paquet est soit à destination de la machine locale, soit à destination d'une machine sur Internet. Pour un paquet destiné à la machine locale, le réseau virtuel local est utilisé. Tous les autres paquets sont envoyés sur la connexion Internet. Cependant, il peut arriver qu'une machine ait le choix entre plusieurs passerelles différentes pour envoyer un paquet dont la destination n'est pas sur son propre réseau. Par exemple, les passerelles d'Internet peuvent être elles-mêmes connectées à différents autres réseaux, qui sont eux-mêmes connectés à d'autres réseaux. Un paquet peut donc être acheminé de plusieurs manières à sa destination, selon la topologie du réseau. L'ensemble des réseaux empruntés par un paquet dans son voyage constitue ce qu'on appelle sa route.

Chaque passerelle contribue donc à déterminer la route des paquets en choisissant, pour chaque paquet, l'interface réseau à utiliser pour transmettre ce paquet. Ce choix est fait en suivant un certain nombre de règles basées sur l'adresse destination des paquets. Par exemple, si une passerelle reçoit un paquet dont l'adresse destination est 129.46.10.15, et qu'elle est elle-même connectée à un réseau possédant cette machine, elle transmettra bien évidemment ce paquet sur ce réseau. Si en revanche elle ne peut localiser la machine cible sur l'un de ses réseaux, elle l'enverra à une autre passerelle à laquelle elle a accès. Le choix de cette passerelle est en général déterminé par des règles de la forme suivante : « Tous les paquets destinés au sous-réseau 129.46.0.0 doivent être envoyés vers la passerelle 193.49.20.1 du réseau 193.49.20.0 ». Notez qu'à chaque étape de la route, seules les passerelles de l'étape suivante peuvent être choisies comme relais.

Ainsi, si la passerelle est connectée à trois réseaux d'adresses respectives 192.168.1.0, 193.49.20.0 et 209.70.105.10, elle transférera le paquet à destination de 129.46.10.15 à la passerelle 193.49.20.1. La transmission effective du paquet à cette passerelle se fera ensuite selon le protocole réseau bas niveau utilisé sur le réseau 193.49.20.0. Autrement dit, une passerelle est une machine qui, contrairement aux machines classiques, accepte de recevoir des paquets qui ne lui sont pas directement adressés, et de les traiter en les réémettant vers leur destination ou vers une autre passerelle, selon les règles de routage qu'elle utilise.

Les règles utilisées par les passerelles sont stockées dans ce qu'on appelle des tables de routage. Les tables de routage peuvent être configurées statiquement dans la configuration des passerelles, c'est-à-dire initialisées dans les fichiers de configuration et ne jamais être modifiées. Cette technique convient parfaitement pour les petits réseaux. Elle se révèle cependant insuffisante sur les passerelles d'Internet. En effet, si les réseaux empruntés par une route sont saturés, voire hors service, il peut être intéressant d'utiliser une autre route. Ces passerelles utilisent donc des tables de routage dynamiques, qui sont automatiquement mises à jour en fonction de l'état du réseau. Bien que Linux puisse parfaitement effectuer ce type de routage, c'est une configuration réservée à un usage spécifique de Linux. Ce document ne traitera donc pas du routage dynamique.

Le problème des adresses IP est qu'elles ne sont pas très parlantes pour les êtres humains : que peut donc signifier 192.147.23.2 ? Pas grand-chose… C'est pour cela qu'on affecte des noms de machines plus humains, par exemple krypton.andromede.galaxie. Ces noms suivent une convention de nommage bien précise. En général, le premier nom est le nom de la machine elle-même, et la suite du nom constitue ce qu'on appelle le domaine dans laquelle la machine se trouve. Ainsi, dans l'exemple précédent, krypton est le nom d'une machine, et andromede.galaxie est le nom de son domaine. En général, il existe plusieurs machines dans un même domaine, on pourrait donc également avoir altair.andromede.galaxie par exemple (malheureusement pour mon exemple, l'étoile Altaïr ne se trouve pas dans la galaxie d'Andromède, mais bon…). Souvent, les noms de domaines sont des noms de sociétés. La dernière partie du nom de domaine permet également de déterminer la nature du domaine, ou sa localisation. Par exemple, l'extension .com indique clairement que le domaine est de nature commerciale (de surcroît, il s'agit sans doute d'une société américaine, l'extension .com étant réservée aux États-Unis). De même, l'extension .gov est utilisée pour les organismes gouvernementaux américains, et l'extension .edu pour les universités ou les écoles américaines. L'extension .org est utilisée pour les organisations non commerciales. Enfin, les noms de domaines des autres pays que les États-Unis utilisent quasiment systématiquement une extension indiquant leurs pays d'origine. Ainsi, .fr représente la France, .uk les Royaumes-Unis, etc. Notez que la notion de domaine est a priori distincte de la notion de réseau.

La question technique qui se pose avec ces conventions de nommage « humaines » est de savoir comment déterminer, à partir d'un nom littéral, l'adresse IP de la machine correspondante. Cette opération n'est pas simple, et en fait elle est effectuée de deux manières :

• soit la machine locale demande à une autre machine qu'elle connaît d'effectuer la recherche de l'adresse du correspondant ;
• soit elle dispose d'une liste de noms et d'adresses lui permettant de déterminer directement les adresses de ses interlocuteurs.

La première solution utilise ce qu'on appelle un serveur de noms (« DNS » en anglais, abréviation de « Domain Name Service »), qui connaît toutes les machines du réseau soit directement, soit indirectement (donc via un autre DNS). L'opération qui consiste à retrouver l'adresse IP d'une machine à partir de son nom s'appelle la résolution de nom de domaine. Il est évident que si le serveur de noms ne peut être contacté, il sera impossible d'utiliser les noms de machines. En revanche, il sera toujours possible d'utiliser leurs adresses IP directement, si on les connaît. La deuxième solution ne souffre pas de ce défaut, elle nécessite cependant de mettre à jour la liste des noms sur tous les postes régulièrement, ce qui est beaucoup plus complexe que la gestion centralisée d'un DNS. On ne l'utilisera donc que pour les petits réseaux.

Nous avons vu que le protocole IP fournit les briques de base de toute la communication réseau sous Unix (et Internet). Ses principales fonctionnalités sont le découpage des informations en paquets de taille suffisamment petite pour pouvoir transiter sur tous les types de réseaux physiques, la gestion des destinations des paquets à l'aide des adresses IP, et le choix de la route permettant d'acheminer les paquets à destination. En revanche, il est incapable d'assurer les services plus évolués comme la gestion de l'ordre d'arrivée des paquets et la gestion de la fiabilité du transfert des informations. C'est donc à des protocoles plus évolués, eux-mêmes encapsulés dans IP, d'effectuer ces tâches. L'un des protocoles les plus importants est le protocole TCP (abréviation de l'anglais « Transfer Control Protocol »). Ce protocole se charge d'établir les connexions entre deux ordinateurs, et assure la fiabilité des informations transmises et l'arrivée des informations dans leur ordre d'envoi. Il existe d'autres protocoles, moins connus que TCP, mais tout aussi importants. On retiendra en particulier les deux protocoles suivants :

• UDP (abréviation de l'anglais « User Datagram Protocol »), qui permet d'émettre des datagrammes sur le réseau, qui sont de simples paquets de données (c'est un protocole semblable à IP, destiné aux applications) ;
• ICMP (abréviation de « Internet Control Message Protocol »), qui est utilisé essentiellement pour transmettre des messages de contrôle du fonctionnement des autres protocoles (il est donc vital).

Les services réseau des machines sont organisés en couches logicielles, qui s'appuient chacune sur la couche inférieure. Ainsi, TCP utilise IP, qui lui-même utilise le pilote qui gère l'interface réseau. Du fait que ces couches s'appuient les unes sur les autres, on appelle souvent l'ensemble de ces couches une pile (« stack » en anglais). Vous avez peut-être déjà entendu parler de la pile TCP/IP. Lorsqu'un service réseau d'une machine n'est plus accessible, il se peut que ce service réseau ait planté. Si tout un ensemble de services réseau ne fonctionne plus, c'est certainement une des couches logicielles qui est plantée. Par exemple, une machine peut répondre à la commande ping (classiquement utilisée pour tester les connexions réseau) et ne plus accepter la plupart des connexions réseau. Cela signifie simplement que la couche TCP ne fonctionne plus, et que la couche ICMP (utilisée par ping) est toujours valide. Évidemment, si la couche IP tombe en panne, la machine ne sera plus accessible du tout, sauf éventuellement avec d'autres protocoles réseau complètement différents (IPX, Appletalk, etc.).

Seuls les mécanismes du protocole TCP seront détaillés dans la suite de ce document. Le protocole TCP est en effet utilisé par un grand nombre de services, ce qui en fait certainement le plus connu.

Le protocole TCP utilise la notion de connexion. Une connexion est un canal de communication établi entre deux processus par TCP. Comme les processus sont susceptibles d'utiliser plusieurs connexions simultanément, TCP fournit la possibilité de les identifier par un numéro unique sur la machine, compris entre 0 et 65535. Chaque numéro identifie ce qu'on appelle un port TCP. Quand un processus désire établir une connexion avec un autre, il utilise un de ses ports et essaie de se connecter sur le port du deuxième processus.

Il faut bien comprendre que les deux numéros de ports utilisés ne sont a priori pas les mêmes pour les deux processus. Évidemment, il est nécessaire que les processus clients connaissent les numéros de port des processus serveurs auxquels ils se connectent. Les numéros de ports sont donc affectés à des services bien définis, et les serveurs qui fournissent ces services doivent bien entendu utiliser ces numéros de ports. Ainsi, il est possible de déterminer de manière unique un programme serveur sur un réseau avec l'adresse IP de la machine sur laquelle il fonctionne et le numéro de port qu'il écoute pour les connexions extérieures. Les clients qui se connectent savent donc parfaitement à quel service ils accèdent lorsqu'ils choisissent le numéro de port destination. Leur propre numéro de port est en général choisi par le système, afin d'éviter tout conflit avec un autre processus de la même machine.

Une fois établie, une connexion TCP permet d'effectuer des communications bidirectionnelles. Cela signifie que le client et le serveur peuvent tous deux utiliser cette connexion pour envoyer des données à l'autre. Le client envoie ses données sur le port destination du serveur, et le serveur peut renvoyer les résultats au client en utilisant le port de celui-ci. Les paquets TCP disposent donc toujours d'un port source (c'est-à-dire le port TCP de l'émetteur), et d'un port destination (le port du récepteur). Ainsi, le récepteur peut renvoyer sa réponse en utilisant le port source comme port de destination du paquet renvoyé, et inversement.

Comme il l'a déjà été dit, le protocole TCP s'assure que les informations transmises arrivent à bon port (c'est le cas de le dire !). Pour cela, il utilise un mécanisme d'accusés réception, qui indiquent à l'émetteur si le destinataire a bien reçu chaque paquet envoyé. Si l'accusé réception n'est pas reçu dans un temps fixé, le paquet est réémis. Un paquet reçu en double à cause d'un retard dans la communication de l'accusé réception est tout simplement ignoré. La fiabilité des informations est également assurée. Cette fiabilité est réalisée par un mécanisme de sommes de contrôle. Si le récepteur constate que la somme de contrôle des données reçues n'est pas celle que l'émetteur a calculée, il rejette le paquet parce qu'il sait que les informations ont été corrompues pendant la transmission. Enfin, TCP s'assure que les informations émises en plusieurs passes sont bien reçues dans leur ordre d'émission. Cette réorganisation se fait grâce à une numérotation des paquets (cette numérotation sert également à détecter les paquets reçus en double). Elle peut paraître inutile, mais la vitesse d'arrivée des paquets est hautement dépendante de la route IP qu'ils prennent pour parvenir à destination. Les paquets qui arrivent en avance sont donc mémorisés jusqu'à ce que tous les paquets qui les précèdent soient reçus.

TCP fournit donc les fonctionnalités requises pour la plupart des services réseau existant. Il est logique que ceux-ci s'appuient sur lui pour effectuer leur travail. Cependant, il ne se charge que de communiquer les informations, rien de plus. Des protocoles de plus haut niveau ont donc été créés. Leur valeur ajoutée provient souvent du formatage et de la structuration des flux de données échangés.

La plupart des services réseau définissent donc un protocole qui leur est propre. Il est d'ailleurs assez courant de confondre le service et le protocole, tellement ils sont intrinsèquement liés. Ainsi, le service FTP utilise le protocole FTP (« File Transfer Protocol », protocole de transfert de fichiers), les serveurs Internet utilisent essentiellement le protocole HTTP (« Hyper Text Transfer Protocol », protocole de transfert d'hypertexte), le service de courrier électronique utilise les protocoles POP (« Post Office Protocol ») pour la réception des courriers et SMTP (« Simple Mail Transfer Protocol ») pour leur envoi. Cette liste de protocoles n'est pas exhaustive, et de nouveaux services apparaissent régulièrement. Les protocoles de haut niveau ne seront donc pas décrits dans ce document.

Les protocoles de haut niveau transmettent, en général, toutes leurs données en clair sur le réseau. Cela comprend non seulement les données applicatives, mais également les noms d'utilisateurs et les mots de passe. Toute personne ayant physiquement accès au réseau ou à une machine par laquelle les paquets passent peut donc, s'il le désire, récupérer tous les mots de passe avec une simplicité extrême (il existe même des programmes spécialisés pour cela). Il est donc inconcevable d'utiliser tous ces protocoles sans prendre de précautions particulières. Heureusement, il est possible d'encapsuler les protocoles dans un réseau virtuel qui, lui, transmet les données sous forme chiffrée. L'outil le plus utilisé de nos jours est ssh (abréviation de l'anglais « Secure SHell »), qui permet de se connecter sur une machine et de travailler à distance en toute sécurité. Il en existe plusieurs implémentations, dont au moins une libre : OpenSSH. Nous verrons comment configurer et utiliser OpenSSH pour améliorer la sécurité du réseau dans la Section 9.5.2.2.

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

• l'interface loopback, qui représente le réseau virtuel de la machine, et qui permet aux applications réseau d'une même machine de communiquer entre elles même si l'on ne dispose pas de carte réseau ;
• les interfaces des cartes réseau (que ce soient des cartes Ethernet, TokenRing ou autres) ;
• les interfaces ppp, plip ou slip, qui sont des interfaces permettant d'utiliser les connexions sérielles, parallèles ou téléphoniques comme des réseaux.

La configuration d'une interface comprend l'initialisation des pilotes nécessaires à son fonctionnement et l'affectation d'une adresse IP à cette interface. La syntaxe générale que vous devrez utiliser est la suivante :

ifconfig interface adresse netmask masque up

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

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

ifconfig interface down

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

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

ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up

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

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

ifconfig eth0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.0 up

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

ifconfig interface:numéro add adresse netmask masque

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

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

ifconfig lo 127.0.0.1 netmask 255.0.0.0 up

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

La commande utilisée pour définir une route est, chose surprenante, la commande système route. Sa syntaxe est donnée ci-dessous :

route opération [-net | -host] adresse netmask masque interface

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

Par exemple, la règle de routage à utiliser pour l'interface loopback est la suivante :

route add -net 127.0.0.0 netmask 255.0.0.0 lo

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

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

route add -net 192.168.0.0 netmask 255.255.255.0 eth0

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

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

route add [-net | -host] adresse netmask masque gw passerelle interface

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

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

route add -net 192.168.0.0 netmask 255.255.255.0 eth0
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.1 eth0

La première règle permet, comme on l'a déjà vu, de communiquer avec toutes les machines du réseau local. La deuxième règle permet d'envoyer à la passerelle 192.168.0.1 tous les paquets à destination du réseau 192.168.1.0.

Inversement, si la passerelle utilise l'adresse 192.168.1.15 sur le réseau 192.168.1.0, les machines de ce réseau qui voudront accéder au réseau 192.168.0.0 devront spécifier la règle de routage suivante :

route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.1.15 eth0

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

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

route add default gw passerelle interface

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

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

route add default gw 192.168.0.47 eth0

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

hostname

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

hostname nom

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

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

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

Le fichier /etc/host.conf permet de définir le comportement du système lors de la résolution d'un nom. Sa structure est très simple, puisqu'il y a une option de recherche par ligne. Dans la plupart des cas, les lignes suivantes sont suffisantes :

order hosts,bind
multi on

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

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

127.0.0.1    localhost

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

loopback    127.0.0.0

La configuration des serveurs de noms est en revanche une opération nécessaire si l'on désire accéder à des machines dont on ne connaît que le nom. Le fichier de configuration utilisé est cette fois le fichier /etc/resolv.conf. Sa structure est encore une fois très simple, avec une option par ligne, chaque option étant introduite par un mot clé.

Le mot clé domain permet d'indiquer le nom du domaine dont fait partie votre machine. Par exemple, si votre nom de domaine est « andromede.galaxie », vous devrez utiliser la ligne suivante :

domain andromede.galaxie

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

search andromede.galaxie

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

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

nameserver 192.168.0.10 192.168.0.15

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

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

Afin de résoudre ces problèmes de configuration réseau, le protocole DHCP (abréviation de l'anglais « Dynamic Host Configuration Protocol ») a été défini. Il s'agit d'un protocole qui permet aux machines connectées sur un réseau d'interroger un « serveur d'adresses » du réseau capable de gérer une liste d'adresses et de les affecter dynamiquement aux machines du réseau. En fait, ce protocole permet de fournir plus d'informations que les simples adresses IP, par exemple la route par défaut que les machines doivent utiliser, ainsi que les adresses des serveurs de noms du réseau.

Un autre protocole semblable à DHCP a également été développé dans le but de permettre la configuration réseau des machines dès leur démarrage : le protocole BOOTP (abréviation de l'anglais « BOOTstrap Protocol »). Ce protocole est évidemment plus léger que DHCP, mais permet aux machines d'obtenir dynamiquement leur configuration réseau dès leur démarrage, avant même que ne soient montés les systèmes de fichiers. Ce protocole est donc particulièrement utile pour faire démarrer des machines sans disque, pour lesquelles le système de fichiers racine est monté en NFS.

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

IX-B-5-a. Autoconfiguration des clients DHCP et BOOTP▲

IX-B-5-b. Configuration d'un client DHCP au niveau utilisateur▲

dhclient interface0 [interface1 […]]

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

En réalité, les paquets du protocole IP contiennent un champ permettant de signaler le type de protocole de haut niveau dont ils transportent les informations. À chaque protocole est donc attribué un identificateur numérique qui lui est propre, et qui permet aux services réseau d'interpréter les données des paquets.

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

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

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

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

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

nom    port/protocole    alias

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

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

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

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

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

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

IX-B-7-a. Le super-démon inetd▲

telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd  in.telnetd

IX-B-7-b. Le super-démon xinetd▲

service
{
    option opérateur valeur [valeur […]]
    option opérateur valeur [valeur […]]
    …
}

# Définition des options par défaut :
defaults
{
    # On interdit la connexion à tout le monde par défaut :
    only_from =

    # On désactive les services internes :
    disabled = echo time daytime chargen discard

    # On désactive les services d'administration de xinetd :
    disabled += servers services xadmin

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

    # On définit les règles de suivi des connexions :
    log_type        = FILE /var/log/servicelog
    log_on_success  = HOST PID USERID DURATION EXIT
    log_on_failure  = HOST USERID RECORD
}

# Inclusion des fichiers de configuration des services :
includedir /etc/xinetd.d

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

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

Les connexions à Internet utilisent le protocole PPP (abréviation de l'anglais « Point to Point Protocol »), qui permet à deux ordinateurs d'échanger des paquets TCP/IP au travers d'un canal de communication simple (donc, en particulier, au travers d'une ligne téléphonique en utilisant un modem). Ce protocole est géré par le noyau et par le démon pppd. Il permet d'effectuer la négociation initiale entre les deux machines, ce qui comprend notamment l'identification, l'authentification et l'attribution des adresses IP.

Le démon pppd ne gère pas le modem directement, car il est supposé être utilisable sur d'autres types de lignes que les lignes téléphoniques. La gestion du modem est donc relayée à un autre programme, qui se nomme chat (il tient son nom du fait qu'il permet de dialoguer directement avec le modem). Le programme chat ne connaît pas les différents types de modems qui existent sur le marché, il se contente d'exécuter des scripts qui décrivent les informations à envoyer au modem et les réponses attendues en retour. Cela permet de reporter la configuration spécifique aux modems dans des scripts de connexion. L'écriture de ces scripts nécessite bien entendu de connaître les commandes que votre modem est capable de comprendre. Notez également qu'il est indispensable ici que votre modem soit un vrai modem (qu'il soit interne ou externe), et non pas un modem logiciel (ces modems sont des modèles bas de gamme qui nécessitent un support logiciel pour interpréter les informations analogiques reçues sur la ligne téléphonique). Renseignez-vous donc bien sur la nature du modem que vous achetez, si vous voulez ne pas avoir de problèmes sous Linux…

La séquence des opérations lors d'une connexion est donc l'initialisation du modem et l'établissement de l'appel téléphonique par le programme chat, puis le démarrage du démon pppd. Celui-ci effectue la connexion sur le serveur du fournisseur d'accès et détermine l'adresse IP, les adresses des DNS, la passerelle et la route à utiliser pour cette connexion. Une fois cela réalisé, toutes les fonctionnalités réseau peuvent être utilisées via Internet, et votre ordinateur fait alors partie du réseau mondial.

L'identification et l'authentification peuvent se faire de différentes manières selon le fournisseur d'accès à Internet utilisé. Un certain nombre de fournisseurs exige l'authentification lors de l'appel téléphonique, avec un mécanisme de login classique. Pour ces fournisseurs, l'authentification est faite par le programme chat, auquel il faut communiquer le nom d'utilisateur et le mot de passe. D'autres fournisseurs utilisent un protocole d'authentification spécifique. Pour ceux-ci, l'authentification est réalisée directement par le démon pppd, une fois que la ligne a été établie. Les deux principaux protocoles d'authentification sont PAP (abréviation de l'anglais « Password Authentification Protocol ») et CHAP (abréviation de « Challenge Handshake Authentification Protocol »). PAP réalise l'authentification comme le mécanisme de login classique : le client envoie son nom et le mot de passe correspondant en clair au serveur. CHAP utilise en revanche la notion de défi. Le serveur envoie une requête contenant son nom, et le client doit s'identifier et authentifier son identité en lui renvoyant une réponse contenant son propre nom et une valeur calculée à partir du mot de passe correspondant. Les deux méthodes seront présentées ci-dessous. Si vous ne parvenez pas à vous connecter à Internet avec la première de ces méthodes, tentez votre chance avec PAP ou CHAP. Sachez que pour utiliser ces protocoles il est nécessaire de connaître, en plus de votre login et de votre mot de passe, le nom du serveur utilisé. Cette information doit vous être communiquée par votre fournisseur d'accès à Internet. Si vous avez le choix, utilisez de préférence le protocole CHAP, car il n'envoie jamais de mot de passe en clair sur la ligne téléphonique.

La configuration de l'accès à Internet pour un fournisseur d'accès requiert donc la configuration du réseau, la configuration de ppp, la configuration de chat et l'écriture des scripts de connexion. Ces étapes seront détaillées ci-dessous. Nous supposerons dans la suite que vos paramètres de connexion sont les suivants :

Note : Les informations données dans le tableau ci-dessus sont fictives et ne servent qu'à donner un exemple. Vous devez bien entendu les remplacer par les valeurs vous concernant en chaque endroit où elles apparaissent dans la suite de ce document. Si par hasard une de ces informations correspondait à un numéro de téléphone, un nom ou une adresse IP valide, ce serait une pure coïncidence.

Certains fournisseurs d'accès refuseront de vous donner toutes ces informations, sous prétexte qu'ils vous fournissent un kit de connexion pour Windows. Ce n'est pas trop grave, car il est possible de leur extorquer ces informations malgré eux. Les seules informations réellement indispensables sont le numéro de téléphone, le nom de login, le mot de passe et le nom de domaine. Les adresses de DNS peuvent être déterminées automatiquement dans le cadre du protocole PPP, et le nom de serveur est arbitraire et ne sert qu'à identifier la connexion.

La première étape dans la création d'une connexion à Internet est avant tout l'ajout des serveurs DNS du fournisseur d'accès à votre configuration réseau. Cela n'est pas toujours nécessaire, car il est possible de configurer le démon pppd pour qu'il demande au fournisseur d'accès les adresses IP des DNS de celui-ci lors de l'établissement de la connexion. Cependant, il est plus facile d'utiliser le mécanisme de connexion à la demande si l'on indique les adresses des DNS du fournisseur d'accès dans la configuration réseau.

Pour l'exemple de connexion utilisé ici, vous devez simplement ajouter les lignes suivantes dans le fichier /etc/resolv.conf :

search monfai.fr
nameserver 192.205.43.1

Si vous ne connaissez pas les adresses de DNS de votre fournisseur d'accès, vous pourrez l'obtenir en regardant dans les traces du noyau lors de l'établissement d'une connexion. Nous verrons cela en détail plus loin.

La deuxième étape est d'écrire un script de numérotation pour le programme chat. Ce script pourra être placé dans le répertoire /etc/ppp/peers/, et pourra être nommé monfai.chat par exemple. Son contenu sera le suivant :

REPORT CONNECT
ABORT ERROR
ABORT BUSY
ABORT VOICE
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
"" ATZ
OK AT&F1
OK ATM0L0DT0836763018
CONNECT ""

Ce script contient le programme que chat doit exécuter pour appeler le fournisseur d'accès à Internet. Il indique toutes les erreurs possibles susceptibles de faire échouer l'opération, puis il envoie les commandes d'initialisation et de numérotation au modem. Vous devrez remplacer le numéro de téléphone utilisé dans la commande DT<numéro> par le numéro de téléphone de votre fournisseur d'accès à Internet.

Note : Dans les scripts pour chat, il est possible d'utiliser indifféremment l'apostrophe simple, l'apostrophe double ou aucune apostrophe si la chaîne attendue de la part du modem ou à lui envoyer ne contient aucun espace.

Si d'aventure ce script ne fonctionne pas, vous serez sans doute obligé de demander au programme chat d'afficher tous les messages envoyés et reçus par le modem. Cela se fait normalement avec les options -v et -s. Vous verrez alors les messages en provenance du modem, ce qui vous permettra de déterminer comment modifier ce script.

Si votre fournisseur d'accès à Internet utilise un mécanisme de login classique, vous devez faire l'identification directement dans le script chat. En général, le serveur du fournisseur d'accès envoie la demande de login dès que la connexion a été établie. Pour cela, il utilise une chaîne de caractères telle que « login: », à laquelle le script chat doit répondre par votre nom d'utilisateur. Le serveur demande alors le mot de passe avec une chaîne telle que « password: », demande à la suite de laquelle le script chat doit envoyer votre mot de passe. Ce n'est que lorsque ces deux informations auront été fournies que la connexion sera réellement établie. Vous pouvez compléter le script chat pour répondre à ces deux questions avec les deux lignes suivantes :

ogin: jdupont
ssword: gh25k;f

Vous devrez bien entendu remplacer le nom du login et le mot de passe par vos propres données dans ce script. Notez qu'il n'est pas nécessaire (ni recommandé) de demander la réception de la chaîne complète « login: », car une erreur de transmission sur la ligne peut encore arriver à ce stade et provoquer la perte des premiers caractères envoyés par l'ordinateur distant. De plus, il se peut que la première lettre soit en majuscule ou en minuscule, selon le fournisseur d'accès à Internet que vous utilisez. Il en va de même pour la demande de mot de passe (« password: »).

Si, en revanche, votre fournisseur d'accès utilise le mécanisme d'authentification PAP ou CHAP, vous ne devez pas ajouter ces lignes, car le serveur n'enverra pas la chaîne de caractères « login: ». Il tentera de communiquer directement avec votre démon pppd pour réaliser l'authentification. Bien entendu, les défis lancés par le serveur sont simplement constitués de la demande du login et de la demande du mot de passe correspondant à ce login. Le démon pppd utilisera alors les « secrets » stockés dans le fichier /etc/ppp/pap-secrets ou le fichier /etc/ppp/chap-secrets pour répondre à ces défis, selon que le protocole utilisé par le serveur du fournisseur d'accès est PAP ou CHAP. C'est donc dans ces fichiers que vous devrez enregistrer votre login et votre mot de passe. Le format de ces fichiers est très simple. Les deux fichiers utilisent la même syntaxe pour les secrets. Vous devez simplement y ajouter une ligne telle que celle-ci :

# Secrets for authentification using PAP/CHAP
# client        server  secret  IP addresses
jdupont serveurfai      gh25k;f

pour que l'identification et l'authentification se fasse correctement. Comme on le voit, le nom du serveur est indiqué dans ce fichier : il permet de déterminer quel login et quel mot de passe doivent être utilisés pour les protocoles PAP et CHAP.

Note : En fait, le protocole PPP ne permet pas d'identifier des utilisateurs, mais des machines. Cependant, pour votre fournisseur, votre machine est identifiée par votre login, et il faut donc indiquer ce nom comme nom de machine cliente dans les fichiers pap-secrets et chap-secrets.

Le nom de serveur n'est pas utilisé pour la connexion. Il ne sert qu'à déterminer quel secret doit être utilisé pour une connexion donnée. Comme la plupart des gens n'ont qu'un seul fournisseur d'accès à Internet, ce nom est purement et simplement facultatif. Dans ce cas, on peut parfaitement remplacer le nom du serveur par une étoile. Ce caractère générique indique simplement que le même secret doit être utilisé pour toutes les connexions.

Pour les connexions à Internet, il est souvent impossible de connaître a priori l'adresse IP que le serveur donnera au client. On peut donc laisser vide la colonne contenant les adresses IP utilisables par les clients.

Lorsque vous aurez écrit le script chat et éventuellement complété les fichiers de secrets de PAP ou de CHAP, vous pourrez écrire le script de connexion à Internet. Ce script est très simple :

#!/bin/sh
# Script de connexion à Internet

# Effectue le ménage :
rm -f /var/spool/uucp/LCK* /var/lock/LCK* /var/run/ppp*.pid

# Établit la connexion :
/usr/sbin/pppd /dev/modem 115200 connect "/usr/sbin/chat -v \
    -f /etc/ppp/peers/monfai.chat" defaultroute usepeerdns \
    ipcp-accept-remote ipcp-accept-local

Prenez garde à écrire la ligne exécutant pppd et la ligne des options en une seule ligne, sans saut de ligne. Notez que le caractère '\' placé en fin de ligne permet d'indiquer que la commande se poursuit sur la ligne suivante. Ce script commence par faire le ménage sur les fichiers éventuellement laissés par les anciennes connexions, et appelle pppd en lui demandant d'utiliser la connexion établie par le programme chat avec la vitesse maximale de connexion indiquée. Lorsque la connexion est établie, le serveur du fournisseur d'accès est enregistré comme passerelle par défaut dans la table de routage du noyau. L'envoi et la réception des paquets IP en direction de l'Internet se feront donc en passant par cette passerelle. Les adresses de DNS du fournisseur d'accès sont également récupérées et ajoutées dans le fichier /etc/ppp/resolv.conf. Vous pourrez les déterminer simplement en consultant les fichiers de log de votre distribution dans le répertoire /var/log/. Les deux dernières options permettent d'autoriser le serveur du fournisseur d'accès à fixer les adresses IP locales et distantes.

Dans ce script de connexion, le programme chat est appelé avec le script de numérotation pour chat que l'on a déjà écrit. Si l'on désire voir exactement ce qui se passe, on peut ajouter l'option -s à la commande d'exécution de chat :

/usr/sbin/chat -v -s -f /etc/ppp/peers/monfai.chat

dans le script de connexion vu ci-dessus. Cela vous permettra de déboguer votre script de numérotation.

Vous remarquerez que le programme pppd utilise le fichier spécial de périphérique /dev/modem pour la communication. Il va de soi que si ce fichier spécial n'existe pas, vous devrez le créer. La solution la plus simple est de faire un lien symbolique vers /dev/ttS0 ou /dev/ttS1, selon que votre modem est connecté sur le premier ou le deuxième port série de votre ordinateur.

La commande de lancement donnée ci-dessus suppose que le script de connexion /etc/ppp/peers/monfai.chat réalise l'identification et l'authentification. Si vous utilisez l'un des protocoles PAP ou CHAP, il faut demander à pppd d'effectuer ces deux opérations lui-même. Pour cela, il faut ajouter des options dans la ligne de commande utilisée pour le lancer dans le script de connexion, afin de préciser le nom du serveur et le nom d'utilisateur pour l'identification. La ligne complète à utiliser pour PAP ou CHAP doit donc être celle-ci :

# Établit la connexion :
/usr/sbin/pppd /dev/modem 115200 connect "/usr/sbin/chat -v \
    -f /etc/ppp/peers/monfai.chat" defaultroute usepeerdns \
    ipcp-accept-remote ipcp-accept-local noauth \
    remotename serveurfai user jdupont

Encore une fois, cette commande doit être écrite sur une seule ligne, ou sur plusieurs lignes séparées par le caractère '\'. L'option noauth signale qu'il n'est pas nécessaire que le serveur du fournisseur d'accès s'authentifie en tant que tel (ce n'est pas nécessaire, car les fournisseurs d'accès ne jouent pas vraiment aux pirates du web), et les deux options suivantes permettent respectivement d'indiquer le nom de ce serveur ainsi que le nom d'utilisateur à utiliser pour le login. Lors de l'authentification, le démon pppd lira le fichier de secret du protocole choisi par le fournisseur d'accès pour trouver le mot de passe à utiliser. Notez encore une fois qu'il est facultatif de préciser le nom du serveur du fournisseur d'accès si vous avez utilisé le caractère générique '*' dans les fichiers de secrets pour PAP et CHAP.

Il est possible de faire en sorte que la connexion à Internet s'établisse automatiquement dès qu'un programme cherche à utiliser une adresse devant passer par la route par défaut. Toute demande à destination d'une machine dont l'adresse est inconnue localement provoque dans ce cas l'établissement de la connexion à Internet. Pour cela, il suffit simplement :

• d'ajouter l'option demand à la ligne de commande de pppd dans le script de connexion ;
• de lancer ce script en arrière-plan dans un des scripts de démarrage du système.

Si vous désirez utiliser cette fonctionnalité, il est recommandé d'activer également la déconnexion automatique, faute de quoi vous risqueriez de rester connecté involontairement. Cela se fait simplement en ajoutant l'option idle n dans la ligne de commande de pppd, où n est le nombre de secondes pendant lequel le lien PPP doit rester inactif avant que la connexion ne se coupe automatiquement. Un choix judicieux est par exemple 600 (ce qui correspond à dix minutes).

Note : L'interface réseau est automatiquement créée lorsqu'on lance le démon pppd avec l'option demand. Par conséquent, le démon pppd définira automatiquement une adresse IP locale pour cette interface et une adresse IP distante pour la passerelle par défaut. Malheureusement, ces adresses peuvent changer d'une connexion à une autre. En effet, la plupart des fournisseurs attribuent les adresses IP en fonction du modem qui répond au client qui appelle et, en général, la connexion ne se fait pas toujours sur le même modem (il peut y avoir plusieurs modems pour un même numéro de téléphone). C'est pour cela qu'il faut ajouter les options ipcp-accept-remote et ipcp-accept-local pour indiquer à pppd de modifier ces adresses lorsqu'il établira la connexion. Le problème, c'est que les connexions TCP/IP utilisant ces adresses seront systématiquement cassées à la suite de ce changement. C'est en particulier le cas pour le programme qui a initié l'établissement de la liaison PPP. C'est pour cette raison qu'il est recommandé de demander une adresse IP fixe à son fournisseur d'accès lorsqu'on veut utiliser la connexion à la demande. Hélas, ce service peut faire l'office d'une facturation supplémentaire.

Même si l'on utilise l'option usepeerdns dans la ligne de commande de PPP, il est recommandé de rajouter les adresses des DNS dans le fichier /etc/resolv.conf. En effet, en l'absence de DNS, les noms de domaine ne seront pas résolus et aucune requête vers l'extérieur ne se fera. Par conséquent, la route par défaut ne sera pas utilisée, et pppd n'établira donc pas la connexion automatiquement. Notez que si vous définissez les DNS dans le fichier /etc/resolv.conf, vous pouvez vous passer de l'option usepeerdns dans la ligne de commande de pppd. Si vous désirez procéder de cette manière, vous devrez vous assurer que l'ordre spécifié pour la résolution des noms dans le fichier /etc/host.conf est bien le fichier /etc/hosts (option hosts) avant le DNS (option bind), faute de quoi votre ordinateur se connectera systématiquement à Internet dès que vous utiliserez un nom de machine local.

La plupart des options passées en ligne de commande peuvent être spécifiées dans le fichier d'options /etc/ppp/options du démon pppd. Cela peut permettre de simplifier les scripts de connexion.

Si l'on n'utilise pas les mécanismes de connexion / déconnexion automatiques, on devra se déconnecter manuellement. Pour cela, rien de plus simple : il suffit de détruire le démon pppd. Cela peut être réalisé automatiquement avec le script suivant :

#!/bin/sh
# Script de terminaison de la connexion PPP
#

# Détermine la connexion à fermer (fournie sur la ligne de commande,
# ppp0 par défaut) :
if [ "$1" = "" ]; then
        DEVICE=ppp0
else
        DEVICE=$1
fi

# Teste si la connexion indiquée est active :
if [ -r /var/run/$DEVICE.pid ]; then

        # Détruit le processus ppp correspondant (son PID est stocké
        # dans /var/run/) :
        kill -INT `cat /var/run/$DEVICE.pid`

        # Effectue le ménage :
        if [ ! "$?" = "0" ]; then
                rm -f /var/run/$DEVICE.pid
                echo "ERREUR: Un fichier de PID résiduel \
a dû être effacé manuellement"
                exit 1
        fi
        rm -f /var/spool/uucp/LCK* /var/lock/LCK*
        echo "La connexion PPP sur $DEVICE a été fermée correctement…"
        echo

        # Termine le script :
        exit 0
fi

# La connexion indiquée n'est pas active :
echo "ERREUR: Il n'y a pas de connexion PPP sur $DEVICE"
exit 1

Les connexions ADSL ne requièrent pas d'appel téléphonique vers un modem du fournisseur d'accès. Elles s'établissent donc d'une manière différente, généralement bien plus simple. Toutefois, la manière de procéder dépend des fournisseurs d'accès et de la nature de votre modem ADSL. Il est donc difficile de décrire de manière générique la manière dont une connexion ADSL se met en place sous Linux. Seules les grandes lignes seront donc indiquées dans ce paragraphe.

Sachez pour commencer qu'il existe trois types de modems ADSL : les modems USB, les modems Ethernet simples, et les modems routeurs. Les premiers sont connectés à votre ordinateur via un câble USB. Les deuxièmes utilisent plutôt un câble réseau Ethernet classique. Les modems routeurs quant à eux sont des modems ADSL couplés d'un switch et, de plus en plus souvent, d'un point d'accès sans fil Wi-Fi. Ces modems sont intéressants, car ils permettent de connecter plusieurs ordinateurs à Internet via la même ligne, et ces ordinateurs peuvent être mis en réseau directement en les câblant au modem routeur à l'aide de câbles Ethernet, et via un réseau sans fil Wi-Fi pour les modems avec point d'accès.

En général, les modems USB requièrent des pilotes de périphériques spécifiques à chaque type de modem. Ce n'est pas le cas des modems Ethernet et des modems routeurs, puisqu'ils se connectent directement à votre carte Ethernet par un câble Ethernet (droit ou croisé selon votre modem). Par conséquent, si votre carte réseau est prise en charge par Linux (ce qui est fort probable), vous n'aurez absolument aucun problème pour vous connecter à Internet avec un modem Ethernet, alors que les pilotes USB pour Linux sont rarement développés avec sérieux par les fabricants de modems (ayant essuyé les plâtres avec le modem Sagem Fast800 fourni par Free à ses clients et participé au débogage de celui-ci, je suis bien placé pour le savoir). De plus, les modems USB ne permettent pas de partager la connexion Internet entre plusieurs ordinateurs, fonctionnalité très intéressante dans le cadre d'un petit réseau familial ou si vous disposez d'un ordinateur fixe et d'un portable. Enfin, les modems Ethernet sont alimentés, alors que les modems USB utilisent l'alimentation du port USB, ce qui dans 50% des cas provoque des instabilités de la connexion Internet, si ce n'est de l'ordinateur lui-même.

Il est donc vivement conseillé de choisir un modem routeur ou, à défaut, un modem Ethernet si vous en achetez un ou si votre fournisseur d'accès à Internet vous en propose. La plupart des modems évolués des offres multiples (téléphone + Internet et éventuellement TV) distribués de nos jours sont généralement des modems routeurs, et disposent souvent d'une possibilité de point d'accès Wi-Fi.

Note : Même si, comme nous le verrons plus loin, Linux est parfaitement capable de réaliser un partage de connexion à Internet, l'achat d'un routeur domestique ou, pour simplifier l'installation, d'un modem routeur prenant tout en charge, reste intéressant. En effet, ces appareils, prenant totalement en charge la connexion à Internet, rendent la configuration de l'accès à Internet triviale au niveau de l'ordinateur. De plus, ils peuvent fournir des services complémentaires, tels que la configuration dynamique des ordinateurs clients par le protocole DHCP, ou encore le relai de serveur de nom avec un mini serveur DNS, accélérant ainsi de manière non négligeable le temps de réponse lors de la navigation.

De plus, et c'est sans doute l'un des plus gros avantages, les modems routeurs peuvent jouer le rôle d'un pare-feu « naturel » dès lors que la fonction de partage de connexion à Internet est activée. En effet, même si un seul ordinateur est connecté au modem routeur, celui-ci doit utiliser un jeu d'adresses IP privées pour votre réseau local, car votre fournisseur ne vous attribuera qu'une seule adresse IP lors de la connexion. Or, les adresses privées utilisées de ce type ne sont pas, par définition, routables sur Internet. Par conséquent, du point de vue d'Internet, seul le modem routeur est visible : aucun de vos ordinateurs n'est accessible ! Il est donc quasiment impossible à un pirate et encore moins à un virus de passer au travers de cet appareil, sauf à le pirater en premier lieu. Dans tous les cas, cela complique sérieusement les choses, et le type de protection fourni par ces appareils est donc extrêmement fiable. Ne serait-ce que pour cet aspect des choses, je vous recommande vivement l'utilisation de ce type d'appareil (surtout si vous avez un ordinateur qui fonctionne sous Windows).

Même si vous utilisez un modem USB, il apparaîtra généralement comme une interface Ethernet dans le système. L'installation des pilotes pour les modems USB étant extrêmement spécifique, cette étape ne sera pas décrite plus en avant ici. La suite du document suppose donc que vous disposiez d'un modem Ethernet, ou que votre modem soit accessible par l'intermédiaire d'une interface Ethernet simulée par le pilote du modem.

Lorsque vous aurez branché votre modem et que vous pourrez y accéder via son interface Ethernet, vous devrez établir la connexion avec votre fournisseur d'accès. Cela dépend encore une fois du fournisseur d'accès, et parfois même, pour un même fournisseur, de la région dans laquelle vous vous trouvez. Généralement, deux méthodes sont utilisées pour établir la connexion :

• soit les communications se font de manière totalement transparente via l'interface Ethernet du modem, auquel cas la connexion s'établit aussi facilement que si vous vous connectiez à un réseau Ethernet classique ;
• soit les communications sont encapsulées dans le protocole de communication PPP, via un protocole du type PPPoE (« PPP over Ethernet ») ou PPPoA (« PPP over ATM »), auquel cas vous devrez utiliser le démon pppd pour établir la connexion.

Dans le premier cas, la configuration est simpliste. Il suffit d'utiliser l'interface Ethernet du modem comme interface de sortie dans la route par défaut, et éventuellement de mettre un client DHCP à l'écoute sur cette interface si le fournisseur d'accès utilise ce protocole pour attribuer les adresses IP de ses clients. La manière de procéder est décrite dans la section traitant de DHCP. Cette technique est celle utilisée par le fournisseur d'accès Free en France en zone dégroupée. Pour ce fournisseur, les adresses IP fournies étant fixes en zone dégroupée, la connexion à Internet se résume donc aux deux commandes suivantes :

ifconfig eth0 adresse up
route add default eth0

où adresse est l'adresse IP que votre fournisseur d'accès vous a attribuée. La connexion à Internet se fait donc dans ce cas comme la configuration d'une simple carte réseau.

Dans le deuxième cas, le plus simple est d'utiliser le protocole d'encapsulation PPPoE. Comme son nom l'indique, ce protocole permet d'encapsuler les paquets de la liaison PPP avec votre fournisseur Ethernet directement dans des trames Ethernet, qui peuvent ensuite être envoyées via l'interface Ethernet du modem. Cette solution peut être mise en place avec l'outil rp-pppoe de la société Roaring Penguin, ou directement avec un gestionnaire PPPoE au niveau du noyau.

La mise en place d'une connexion avec rp-pppoe est réellement très simple. En effet, un fichier d'options pour PPP nommé pppoe.conf et des scripts de connexion et déconnexion adsl-start et adsl-stop, permettant de lancer le démon pppd avec les bonnes options et dans le bon contexte pour établir la connexion, sont fournis. Les seules opérations à faire sont dans ce cas de s'assurer que les identifiants de connexion (login et mot de passe) fournis par votre fournisseur d'accès sont bien enregistrés dans les fichiers pap-secrets et chap-secrets, et que le fichier pppoe.conf y fait bien référence (au niveau de l'option USER). La manière de procéder ayant déjà été décrite ci-dessus, elle ne sera pas détaillée outre mesure.

L'utilisation du gestionnaire PPPoE du noyau est encore plus directe, car il suffit dans ce cas de lancer le démon pppd en lui demandant de travailler avec l'interface réseau du modem. Pour utiliser ce gestionnaire, vous devez activer, outre le support de PPP, l'option « PPP over Ethernet (EXPERIMENTAL) » dans les options de configuration du noyau. Une fois les identifiants de connexion écrits dans les fichiers pap-secrets ou chap-secrets, la connexion à Internet se fera simplement avec la commande suivante :

pppd interface

où interface est le nom de l'interface réseau du modem.

Note : Il est recommandé de limiter la taille des paquets en réception et en émission à 1492 octets, afin de prendre en compte les frais dus à l'encapsulation PPPoE. Pour cela, il suffit de placer les options suivantes dans le fichier d'options de pppd :

mtu 1492
mru 1492

Il est impératif de mettre en place un pare-feu si vous disposez d'une connexion ADSL. La manière de procéder est décrite dans la Section 9.4.

Vous en savez suffisamment à présent pour vous connecter à Internet avec Linux. Les opérations qui ont été décrites ici sont légèrement compliquées, et vous les trouvez sans doute un peu lourdes. Cela est naturel, car elles le sont effectivement. En fait, les opérations décrites ici vous montrent comment vous connecter manuellement, mais elles ne constituent pas la manière de faire la plus facile. En effet, si vous installez XWindow, vous pourrez utiliser des programmes graphiques permettant de vous connecter à Internet, d'envoyer et recevoir des courriers électroniques (« mails »), de naviguer (« surfer ») et de lire les groupes de discussions (« news »). Cependant, l'utilisation de ces outils ne sera pas décrite ici, car il en existe trop pour que l'on puisse tous les présenter. Heureusement, ces outils sont prévus pour être très simples d'emploi et leur configuration ne pose réellement aucun problème.

La résolution des noms de domaines est une opération dont le coût est loin d'être négligeable au niveau du temps de connexion aux serveurs, si ce n'est au niveau de la bande passante utilisée. En effet, il est relativement courant qu'une page Web fasse de multiples références à des machines inconnues et dont les adresses doivent être résolues. De ce fait, la résolution des noms de domaines peut parfois se mesurer en secondes, surtout si les serveurs de noms des fournisseurs d'accès sont surchargés, ce qui arrive très couramment, même pour les clients des offres ADSL à 20 Mbits/s.

De plus, il est courant qu'un internaute reste toujours sur le même site pendant qu'il navigue sur Internet. Il peut donc être très intéressant de disposer d'un cache local pour les requêtes DNS. Un tel cache permet de mémoriser les interrogations faites par les programmes clients (essentiellement les navigateurs Web) et surtout les réponses renvoyées par le serveur de nom du fournisseur d'accès. Ainsi, lorsqu'un client effectue une requête sur un nom de domaine pour lequel il a déjà fait une requête auparavant (par exemple lors de l'accès à la page précédente), la réponse de cette requête set accessible immédiatement, puisqu'elle se trouve dans le cache local. Ce mécanisme permet donc de réduire sensiblement les temps de connexions aux machines situées sur Internet : seule la première connexion prend le temps habituel, et toutes les autres sont accélérées.

Note : Les mécanismes de « caches » sont très souvent utilisés en informatique pour permettre d'obtenir rapidement des informations habituellement difficiles à obtenir, mais qui varient très peu. Du fait de leur quasi-constance, il est en effet possible de les copier dans une mémoire locale. Par exemple, les caches sont utilisés au niveau des disques durs, dans les processeurs pour accéder aux données en mémoire, et au niveau du réseau. Ils permettent d'augmenter considérablement les performances, au détriment d'une plus grande complexité des opérations d'écriture des données, puisque celles-ci invalident les données des caches et doivent forcer leur mise à jour.

En pratique, la mise en place d'un cache de DNS consiste à installer un petit serveur de nom local sur la machine, qui répond à toutes les requêtes des applications clientes. Ce petit serveur est lui-même client des serveurs de noms effectifs qui se trouvent sur Internet. L'idéal est dans ce cas simplement de s'adresser aux serveurs de noms du fournisseur d'accès à Internet, afin de bénéficier de son propre cache et de sa bande passante pour les requêtes intermédiaires. C'est exactement ce que se propose de faire le programme DNSmasq.

La configuration de DNSmasq se fait essentiellement au niveau du fichier de configuration /etc/dnsmasq.conf. Ce fichier est constitué d'une série d'options auxquelles une valeur est affectée, les lignes commençant par un signe dièse étant des commentaires. Le fichier suivant peut vous servir d'exemple, sachant que les options sont toutes commentées dans le fichier fourni par défaut :

# Exemple de fichier de cache de DNS :

# Fichier de définition des serveurs de noms en amont :
# Si on utilise ppp pour se connecter :
#resolv-file=/etc/ppp/resolv.conf

# Si on utilise DHCP directement :
resolv-file=/var/dhcp/resolv.conf

# Adresses des serveurs utilisés par les sociétés et les fournisseurs d'accès
# tordus qui ont mis en place une entrée par défaut pour capter toutes les requêtes
# sur les noms de domaines incorrects et qui redirigent leurs clients vers des sites
# publicitaire au lieu de renvoyer une erreur comme la nétiquette l'impose :

# Verisign (ils se sont calmés récemment) :
bogus-nxdomain=64.94.110.11

# Mon fournisseur débile :
# bogus-nxdomain=adresse.du.site.publicitaire

Ce fichier d'exemple ne montre que les options réellement nécessaires. L'option resolv-file permet d'indiquer au démon dnsmasq où trouver les adresses des serveurs DNS amont (c'est-à-dire ceux du fournisseur d'accès en pratique). Il faut indiquer ici un fichier qui contient les lignes nameserver donnant les adresses de ces serveurs. Comme nous allons le voir ci-dessus, il ne faut pas spécifier ici le fichier /etc/resolv.conf du système, car nous allons le modifier. Au contraire, il faut indiquer un fichier dans lequel les outils de connexion réseau (client DHCP ou démon pppd par exemple) enregistrent les adresses des serveurs de noms du fournisseur d'accès.

Par exemple, lorsqu'une connexion est établie avec le démon ppp, celui-ci enregistre les serveurs DNS primaires et secondaires du fournisseur d'accès dans le fichier /etc/ppp/resolv.conf. Il suffit donc de référencer ce fichier dans l'option resolv-file.

En revanche, si la connexion s'établit directement grâce au protocole DHCP, il faut configurer le client DHCP du système pour qu'il enregistre les adresses des serveurs DNS dans un fichier autre que le fichier /etc/resolv.conf du système. Ici, nous utilisons le fichier /var/dhcp/resolv.conf. Par exemple, si votre distribution utilise le client DHCP dhcpcd, il suffit de lui ajouter l'option -e /var/dhcp pour que ce fichier soit créé dans le répertoire /var/dhcp/ au lieu du répertoire /etc/.

L'option bogus-nxdomain est un palliatif à une tentative de détournement des requêtes DNS que certaines sociétés effectuent pour obtenir un profit publicitaire direct ou des statistiques comportementales sur les internautes. Ces sociétés redirigent en effet toutes les requêtes mal formées ou mal orthographiées vers un de leur serveur Web, ce qui leur permet d'obtenir des informations sur les sites accédés, d'afficher une page de publicité, ou encore faire une redirection directe vers un site supposé intéresser l'internaute.

Bien entendu, ce comportement est pour le moins cavalier, car l'internaute ne comprend pas forcément pourquoi il tombe sur un site inconnu alors qu'il demandait l'adresse d'un autre site. D'autre part, ces redirections perturbent le bon fonctionnement de certains outils qui s'attendent explicitement à trouver une erreur en cas d'échec de résolution de nom.

Il n'y a malheureusement pas grand-chose à faire pour faire revenir à la raison ces sociétés (à part porter plainte, passer à la concurrence, ou plus méchamment bombarder leurs serveurs DNS de requêtes invalides avec un programme, ce que je vous déconseille de faire vivement…). En revanche, dnsmasq peut détecter ces redirections et générer une erreur de résolution de nom classique. Pour cela, il suffit d'identifier l'adresse IP du serveur cible de la redirection, et de l'indiquer à dnsmasq à l'aide de l'option bogus-nxdomain. Ainsi, lorsque dnsmasq reçoit une réponse référençant ces serveurs, il renvoie directement une erreur aux programmes clients.

Une fois que vous aurez configuré et lancé le démon dnsmasq, vous devrez encore indiquer au système qu'il devra interroger ce démon pour effectuer les résolutions des noms de domaines. Comme il l'a déjà été indiqué dans les sections précédentes, cela se fait simplement en ajoutant une ligne nameserver référençant la machine locale dans le fichier de configuration /etc/resolv.conf :

nameserver 127.0.0.1

Note : Le démon dnsmasq ne permet de cacher que les résultats des requêtes DNS. Or, de nombreux fichiers qui ne changent quasiment jamais, comme les images de fond, les logos et les pages statiques, sont récupérés de multiples fois lorsqu'un internaute navigue sur des pages Web. Il est donc très intéressant de mettre également ces fichiers en cache. Nous verrons comment réaliser cela dans la section suivante.

Lors d'une connexion à Internet, bon nombre d'informations sont échangées entre le serveur et le client. En particulier, lorsqu'on navigue, un certain nombre d'images et d'informations plus ou moins lentes à télécharger transitent systématiquement. Or la plupart des gens visitent régulièrement les mêmes sites, dont seulement quelques pages sont modifiées entre deux visites successives. Par conséquent, on peut se demander pourquoi les pages complètes devraient être rechargées à chaque visite, si seulement quelques informations ont été modifiées.

Cette question prend encore plus de sens lorsqu'on réalise un partage de connexion à Internet. Il est tout à fait concevable que plusieurs clients du même réseau demandent plusieurs fois les mêmes informations, ce qui provoque l'engorgement du lien partagé inutilement. C'est pour résoudre ce genre de problème que les programmes que l'on nomme « proxies » ont été développés.

Un proxy n'est rien d'autre qu'un programme qui s'intercale entre des clients et un serveur. Il a pour principale fonction de mémoriser les réponses les plus courantes renvoyées par le serveur, afin de répondre à la fois plus rapidement aux clients et d'éviter de surcharger le serveur. Il existe différents types de proxy, mais nous allons nous intéresser uniquement aux proxies Web, qui permettent donc de stocker des pages Web en local afin de soulager une liaison trop faible.

Le principe de fonctionnement d'un proxy est le suivant. Les navigateurs utilisés par les clients se connectent, en temps normal, directement sur le port 80 des serveurs Web. Leur configuration doit être modifiée pour utiliser le proxy à la place. De leur point de vue, le proxy se comporte comme un serveur Web capable de répondre aux requêtes des clients. Lorsqu'il peut le faire, il renvoie les données qu'il a stockées dans son cache. Sinon, il va les chercher directement sur Internet à la place du client. Le cache est maintenu de telle manière que les données obsolètes ou les données les moins utilisées sont supprimées, afin de laisser la place aux données qui sont le plus souvent demandées et qui changent le moins. Pour utiliser un proxy, il faut donc modifier la configuration des navigateurs des clients, afin de donner l'adresse de la machine sur laquelle le proxy fonctionne, ainsi que le port sur lequel il peut être contacté (généralement, c'est le port 8080).

Note : Il est également possible d'utiliser les mécanismes de translation d'adresse du noyau pour rendre l'utilisation du proxy transparente aux clients. La manière de procéder sera décrite dans la section traitant des mécanismes de filtrage du noyau.

Il existe plusieurs proxies sur le marché, mais le plus utilisé sous Linux est sans doute squid. C'est un logiciel performant, puissant et libre, fourni avec la plupart des distributions modernes. Sa configuration peut être relativement technique, mais nous n'allons pas entrer dans tous les détails. Il s'agit simplement ici de donner un aperçu des fonctionnalités disponibles.

squid utilise le fichier de configuration /etc/squid.conf pour lire ses options de fonctionnement. Ce fichier contient en particulier les informations concernant le réseau, une liste de règles indiquant qui a le droit de lui demander des pages Web, et l'emplacement du cache dans lequel les données du cache seront enregistrées.

L'option la plus importante dans ce fichier de configuration est sans doute cache_dir, qui indique l'emplacement du cache ainsi que sa taille et sa structure. La syntaxe de cette option est la suivante :

cache_dir répertoire taille n m

où répertoire est le répertoire dans lequel le cache sera stocké (usuellement /var/squid/cache/), taille est la taille de ce cache en mégaoctets, et n et m deux nombres donnant la structure de l'arborescence du cache. La signification de ces deux nombres doit être expliquée un peu plus en détail.

Par défaut, squid essaie de répartir tous les objets qu'il place dans le cache de manière uniforme dans plusieurs répertoires, afin d'accélérer les temps de recherche sur ces objets lorsqu'un client les demande. Il utilise à cette fin une fonction de répartition (les programmeurs disent souvent une fonction de hash) qui indique dans quel répertoire se trouve un objet. La recherche dans ce répertoire se fait donc plus rapidement, car, si la fonction de répartition est bien faite (et c'est le cas), les objets sont répartis de manière équilibrée dans tous les répertoires du cache, qui sont donc tous relativement peu peuplés. En fait, squid peut stocker tellement d'objets que le nombre de répertoires peut lui-même devenir très grand. Il utilise donc un découpage à deux niveaux, les répertoires du deuxième niveau étant répartis dans les répertoires du premier niveau. Le premier nombre spécifié dans l'option cache_dir indique le nombre de répertoires du premier niveau, et le deuxième nombre indique le nombre de sous-répertoires dans chacun de ces répertoires. En général, on utilise respectivement les valeurs 16 et 256 :

cache_dir /var/squid/cache 100 16 256

Cette ligne permet de cacher 100 Mo, en répartissant les objets dans 4096 répertoires répartis en 16 groupes de 256 répertoires.

Les options suivantes spécifient les paramètres réseau du cache :

• l'option http_port indique le port TCP que les clients doivent utiliser pour accéder au proxy ;
• l'option ftp_user permet de donner l'adresse email à utiliser comme mot de passe dans les connexions FTP anonymes ;

• l'option cache_peer permet d'intégrer le proxy local dans une hiérarchie de proxies.
  Les proxies peuvent en effet être organisés dans une structure arborescente. Lorsqu'un proxy d'un niveau ne dispose pas d'une donnée demandée par un client, il peut contacter ses frères pour le cas où ceux-ci auraient cette donnée dans leurs caches, ou demander à son proxy père de récupérer cette donnée pour lui. Les proxies communiquent entre eux en utilisant un protocole dédié, le protocole ICP (abréviation de l'anglais « Inter Cache Protocol »).
  En général, les petits réseaux ne disposent que d'un seul proxy, l'option cache_peer est donc souvent utilisée de la manière suivante :

   

  Sélectionnez

  cache_peer père parent port port_icp options

• L'option prefer_direct permet d'indiquer au proxy s'il doit chercher avant tout à récupérer lui-même les données qui lui manquent (valeur on) ou s'il doit contacter d'abord son proxy père (valeur off). Si l'on a spécifié un proxy père à l'aide de l'option cache_peer, on aura intérêt à utiliser la valeur off ;

• L'option dns_children permet de donner le nombre de processus en charge de cacher les requêtes sur les DNS. squid peut en effet lancer des serveurs de cache de DNS permettant d'optimiser les temps d'accès aux pages Web. Plus le réseau local est important, plus il faudra de tels processus, afin que tous les clients puissent obtenir les adresses IP des machines à partir de leur nom. La valeur par défaut est de 5 processus, ce qui devrait convenir dans la plupart des cas.

Les valeurs données par défaut à toutes ces options conviennent dans la plupart des cas. Elles sont parfaitement documentées dans le fichier de configuration squid.conf.

Par défaut, squid n'autorise personne à accéder au cache. Il est donc nécessaire de donner les droits nécessaires pour permettre aux machines de votre réseau d'accéder au cache. La gestion de la sécurité se fait par l'intermédiaire de ce que l'on appelle des ACL (abréviation de l'anglais « Access Control List »).

Une ACL est simplement un critère permettant de classifier les requêtes que le proxy reçoit. Ces critères sont définis à l'aide du mot clé acl, suivi du nom de la liste, suivi lui-même d'un critère que toutes les requêtes concernées par cette ACL devront vérifier. Les critères sont eux-mêmes exprimés à l'aide d'un mot clé qui indique sur quoi porte le critère et des options de ce critère. Les principaux mots clés que vous pourrez utiliser sont les suivants :

• src, qui permet de filtrer les requêtes par les adresses des machines qui les ont émises, en indiquant l'adresse de leur réseau, donnée sous la forme adresse/masque ;
• dst, qui permet de filtrer les requêtes par leurs adresses destination ;
• port, qui permet de sélectionner les requêtes s'adressant sur les ports fournis en paramètres ;
• proto, qui permet de spécifier la liste des protocoles utilisés par les requêtes ;
• method, qui permet de sélectionner les requêtes HTTP par la méthode utilisée dans la requête.

Ce tableau n'est pas exhaustif, mais il permet d'avoir une idée des capacités de filtrage des requêtes dont dispose squid. Vous trouverez ci-dessous quelques exemples pratiques de définitions d'ACL :

# ACL caractérisant toutes les machines :
acl all src 0.0.0.0/0.0.0.0

# ACL définissant la machine locale :
acl localhost src 127.0.0.1/255.255.255.255

# ACL définissant les machines d'un réseau privé local :
acl localnet src 192.168.0.0/255.255.255.0

# ACL caractérisant le proxy lui-même :
acl manager proto cache_object

# ACL spécifiant les ports acceptés par le proxy :
acl safe_ports port 80 21 443 563 70 210 1025-65535

# ACL définissant les requêtes de connexion :
acl connect method CONNECT

La définition des règles de sécurité utilise les ACL de manière séquentielle. Les règles doivent être données les unes après les autres, suivant le format suivant :

ressource politique ACL

où ressource est un mot clé indiquant la ressource sur laquelle la règle de sécurité porte, politique est l'action prise pour les requêtes vérifiant cette règle, et ACL une liste d'ACL permettant de spécifier les requêtes concernées par cette règle. La ressource la plus utilisée est sans doute le protocole HTTP, que l'on peut spécifier à l'aide du mot clé http_access. Les actions peuvent être l'acceptation (mot clé allow) ou le refus (mot clé deny) de la requête. Enfin, les requêtes concernées par une règle sont celles qui appartiennent à toutes les ACL de la liste d'ACL indiquée.

Vous trouverez ci-dessous quelques exemples de règles de sécurité courantes :

# Autorise les accès au gestionnaire de cache local :
http_access allow manager localhost

# Interdit les accès aux gestionnaires de cache étrangers :
http_access deny manager

# Interdit les accès pour toutes les requêtes provenant de ports non autorisés :
http_access deny !safe_ports
http_access deny connect !safe_ports

# Autorise les accès aux clients de la machine locale :
http_access allow localhost

# Autorise les accès aux machines du réseau local :
http_access allow localnet

# Politique par défaut :
http_access deny all

Notez que si une requête ne correspond à aucune règle, la politique par défaut utilisée par squid est de prendre l'action opposée à la dernière règle spécifiée. En pratique, il est plus sage de toujours indiquer une politique par défaut pour toutes les requêtes restantes, par exemple en utilisant l'ACL all définie ci-dessus.

L'exemple de jeu de règles de sécurité donné ci-dessous convient pour un réseau local d'adresses 192.168.0.0. Vous pouvez bien entendu modifier les options de sécurité comme bon vous semble. Encore une fois, rappelons que le fichier de configuration de squid est très bien documenté et que sa lecture est relativement facile. Je ne saurais que trop vous recommander de le consulter si vous désirez en savoir plus.

Linux est capable de filtrer les paquets circulant sur le réseau et d'effectuer des translations d'adresses depuis la version 2.0. Cependant, les techniques utilisées ont été profondément remaniées dans la version 2.4.0 du noyau, et une architecture extensible a été mise en place et semble répondre à tous les besoins de manière simple : Netfilter.

Netfilter est simplement une série de points d'entrée dans les couches réseau du noyau au niveau desquels des modules peuvent s'enregistrer afin d'effectuer des contrôles ou des traitements particuliers sur les paquets. Il existe une entrée en chaque point clé du trajet suivi par les paquets dans les couches réseau du noyau, ce qui permet d'intervenir de manière souple et à n'importe quel niveau. Un certain nombre de modules permettant d'effectuer les traitements les plus courants sont fournis directement dans le noyau, mais l'architecture Netfilter est suffisamment souple pour permettre le développement et l'ajout des modules complémentaires qui pourraient être développés par la suite.

Les fonctionnalités fournies par ces modules sont regroupées par domaines fonctionnels. Ainsi, les modules permettant de réaliser des pare-feu se chargent spécifiquement de donner les moyens de filtrer les paquets selon des critères bien définis, et les modules permettant d'effectuer des translations d'adresses ne prennent en charge que la modification des adresses source et destination des paquets à la volée. Afin de bien les identifier, ces fonctionnalités sont regroupées dans ce que l'on appelle des tables. Une table n'est en fait rien d'autre qu'un ensemble cohérent de règles permettant de manipuler les paquets circulant dans les couches réseau du noyau pour obtenir une fonctionnalité bien précise. Les tables les plus couramment utilisées sont les tables « filter », « mangle » et « nat », qui permettent respectivement de réaliser des pare-feu, de marquer les paquets pour leur appliquer un traitement ultérieur, et d'effectuer des translations d'adresses.

Les différentes tables de NetFilter s'abonnent chacune aux points d'entrée qui sont nécessaires pour implémenter leur fonctionnalité, et les paquets qui passent au travers de ces points d'entrée doivent traverser les règles définies dans ces tables. Afin de faciliter la définition des règles stockées dans les tables, les règles sont regroupées dans des listes de règles que l'on appelle communément des chaînes. Chaque table dispose donc toujours d'une chaîne de règles prédéfinie pour chacun des points d'entrée de Netfilter qu'elle utilise. L'utilisateur peut bien entendu définir de nouvelles chaînes et les utiliser dans les chaînes prédéfinies, ces chaînes apparaissent alors simplement comme des sous-programmes des chaînes prédéfinies.

Les règles des tables de Netfilter permettent de spécifier les paquets qui les vérifient, selon des critères précis, par exemple leur adresse source ou le type de protocole qu'ils transportent. Les règles indiquent également les traitements qui seront appliqués à ces paquets. Par exemple, il est possible de détruire purement et simplement tous les paquets provenant d'une machine considérée comme non sûre si l'on veut faire un pare-feu. On pourra aussi envoyer ces paquets dans une autre chaîne, qui peuvent indiquer d'autres règles et d'autres traitements.

Les critères de sélection de paquets des règles de filtrage se basent sur les informations de l'en-tête de ces paquets. Rappelez-vous que chaque paquet de données émis sur le réseau transporte avec lui des informations nécessaires au fonctionnement du dit réseau, entre autres les adresses source et destination du paquet. Ce sont sur ces informations que la sélection des paquets est effectuée dans Netfilter. Dans le cas d'un protocole encapsulé dans un autre protocole, par exemple un paquet TCP dans un paquet IP, les informations du protocole encapsulé peuvent également être utilisées, si l'on a chargé des modules complémentaires dans NetFilter. Par exemple, le numéro de port TCP peut faire partie des critères de sélection d'une règle et donc de différencier le trafic des différents services réseau.

Les traitements que l'on peut appliquer à un paquet sont également fournis par des modules de Netfilter. Les traitements les plus simples sont bien entendu fournis en standard avec le noyau. En général, on peut chercher à réaliser les opérations suivantes sur un paquet :

• l'enregistrer, pour analyse ultérieure ;
• le rediriger vers un port local, pour traitement par un programme dédié (par exemple, par un serveur proxy) ;
• l'accepter, l'abandonner ou le rejeter directement (le rejet se distingue de l'abandon par l'émission d'une notification « hôte inaccessible » à la machine ayant émis le paquet) ;
• le modifier et, en particulier, effectuer une translation d'adresse ou le marquer pour le reconnaître dans un traitement ultérieur ;
• l'envoyer dans une autre chaîne pour effectuer des vérifications complémentaires ;
• le faire sortir immédiatement de la chaîne courante.

De plus, les statistiques tenues par le noyau pour la règle ainsi vérifiée sont mises à jour. Ces statistiques comprennent le nombre de paquets qui ont vérifié cette règle ainsi que le nombre d'octets que ces paquets contenaient.

Lorsqu'un paquet arrive à la fin d'une chaîne (soit parce qu'il n'a pas été rejeté ou détruit par une règle de filtrage de pare-feu, soit parce qu'il ne correspond aux critères d'aucune règle, ou soit parce qu'il est arrivé à ce stade après avoir subi des modifications), le noyau revient dans la chaîne appelante et poursuit le traitement du paquet. Si la chaîne au bout de laquelle le paquet arrive est une chaîne prédéfinie, il n'y a plus de chaîne appelante, et le sort du paquet est déterminé par ce qu'on appelle la politique de la chaîne prédéfinie. La politique (« policy » en anglais) des chaînes prédéfinies indique donc ce que l'on doit faire avec les paquets qui arrivent en fin de chaîne. En général, on utilise une politique relativement stricte lorsqu'on réalise un pare-feu, qui rejette par défaut tous les paquets qui n'ont pas été acceptés explicitement par une règle de la chaîne.

Note : Certains paquets peuvent être découpés en plusieurs paquets plus petits lors de la traversée d'un réseau. Par exemple, un paquet TCP un peu trop gros et initialement encapsulé dans un seul paquet IP peut se voir éclater en plusieurs paquets IP. Cela peut poser quelques problèmes aux règles de filtrage, puisque dans ce cas les données spécifiques à TCP (par exemple les numéros de ports) ne sont disponibles que sur le premier paquet IP reçu, pas sur les suivants. C'est pour cette raison que le noyau peut effectuer une « défragmentation » des paquets lorsque cela est nécessaire, et que les paquets transmis par la passerelle ne sont pas toujours strictement identitiques aux paquets qu'elle reçoit.

Nous avons vu que grâce aux mécanismes de filtrage du noyau, il est possible de modifier les paquets à la volée. Il peut être intéressant de modifier un paquet pour diverses raisons, les trois plus intéressantes étant sans doute de le marquer à l'aide d'un champ spécial dans son en-tête afin de le reconnaître ultérieurement, de modifier sa priorité pour permettre un traitement privilégié ou au contraire placer en arrière plan ce type de paquet (libérant ainsi les ressources réseau pour d'autres types de connexion), et de modifier ses adresses source et destination, pour effectuer une translation d'adresse. Nous allons nous intéresser plus particulièrement aux différentes formes de translations d'adresses dans la suite de cette section.

Une translation d'adresse n'est en fait rien d'autre qu'un remplacement contrôlé des adresses source ou destination de tous les paquets d'une connexion. En général, cela permet de détourner les connexions réseau ou de simuler une provenance unique pour plusieurs connexions. Par exemple, les connexions à Internet peuvent être détournées vers un proxy fonctionnant sur la passerelle de manière transparente, en modifiant les adresses destination des paquets émis par les clients. De même, il est possible de simuler un seul serveur en remplaçant à la volée les adresses source des paquets que la passerelle envoie sur Internet.

On distingue donc deux principaux types de translations d'adresses : les translations d'adresse source et les translations d'adresse destination. Parmi les translations d'adresse source se trouve un cas particulier particulièrement intéressant : le « masquerading ». Cette technique permet de remplacer toutes les adresses source des paquets provenant des machines d'un réseau local par l'adresse de l'interface de la passerelle connectée à Internet, tout en conservant une trace des connexions réseau afin d'acheminer vers leur véritable destinataire les paquets de réponses. Ainsi, une seule connexion à Internet peut être utilisée par plusieurs machines distinctes, même si elles ne disposent pas d'adresses IP fournies par l'IANA.

Lorsqu'une machine du réseau local envoie un paquet à destination d'Internet, ce paquet est acheminé vers la passerelle, qui est la route par défaut. Celle-ci commence par modifier l'adresse source de ce paquet et mettre sa propre adresse à la place, puis le transfère vers la machine du fournisseur d'accès. Tous les paquets émis par les machines du réseau local semblent donc provenir de cette passerelle, et seront acheminés normalement à destination. En fait, la complication provient des paquets de réponses, puisque les machines situées sur Internet croient que la machine avec laquelle elles communiquent est la passerelle. Ces paquets sont donc tous envoyés à la passerelle directement, et celle-ci doit retrouver la machine du réseau local à laquelle ils sont destinés. Cette opération est réalisée de différentes manières selon les protocoles utilisés, et elle suppose que la passerelle conserve en permanence une trace des connexions réseau effectuées par les machines du réseau local.

Pour TCP, ce suivi de connexion est réalisé en modifiant également le port source des paquets provenant des machines locales. La passerelle utilise un port unique pour chaque connexion, qui va lui permettre de retrouver la machine à laquelle un paquet est destiné lorsqu'elle en reçoit un provenant d'Internet. Par exemple, si une machine locale fait une connexion à Internet, la passerelle alloue un nouveau numéro de port pour cette connexion et modifie tous les paquets sortants comme ayant été émis par la passerelle elle-même, sur ce port. Lorsque l'autre machine prenant part à la connexion, située sur Internet, envoie un paquet de réponses, celui-ci sera à destination de la passerelle, avec comme port destination le port alloué à cette connexion. La passerelle peut donc retrouver, à partir de ce port, l'adresse de la machine destination réelle, ainsi que le port source que cette machine utilisait initialement. La passerelle modifie donc ces deux champs du paquet, et le renvoie sur le réseau local. Finalement, la machine destination reçoit le paquet sur son port, et ce paquet semble provenir directement d'Internet, comme si la connexion avait été directe. Notez bien que la passerelle ne modifie pas les adresses source des paquets provenant d'Internet, elle ne fait que les réacheminer vers la bonne destination.

Ainsi, le masquerading est un mécanisme complètement transparent pour les machines du réseau local. En revanche, pour les machines de l'Internet, il ne semble y avoir qu'un seul interlocuteur : la passerelle. Celle-ci utilise des numéros de ports variés, mais cela ne les regarde pas. Les machines du réseau local sont donc complètement « masquées » par la passerelle, d'où le nom de masquerading.

Tout ce travail effectué par la passerelle nécessite un traitement spécifique sur chaque paquet qu'elle achemine, et consomme bien entendu des ressources système. Cependant, les débits utilisés pour les connexions à Internet, même les plus rapides, sont très loin de mettre à genoux une passerelle sous Linux, même sur les plus petites machines (386 et 486). Vous voilà rassurés, et peut-être aurez-vous trouvé d'ici peu une utilité à l'un de ces dinosaures qui traînent encore dans votre garage…

Il existe cinq points d'entrée au total pour les modules de Netfilter dans le code des couches réseau IP de Linux. À chacun de ces points d'entrée, les paquets sont soumis aux différentes chaînes des tables qui s'y intéressent. Comme on l'a déjà dit plus haut, chaque table dispose d'une chaîne prédéfinie pour chacun des points d'entrée auxquels elle s'intéresse. Le nom de ces chaînes prédéfinies est le nom du point d'entrée au niveau duquel elles sont appelées. Les paragraphes suivants décrivent ces cinq points d'entrée, ainsi que l'ordre dans lequel les chaînes des différentes tables sont traversées par les paquets.

Les paquets réseau provenant de l'extérieur sont d'abord contrôlés par le noyau afin de détecter les erreurs les plus simples. Les paquets mal formés ou corrompus sont systématiquement éliminés à ce niveau, avant même d'atteindre le code de Netfilter. Les autres paquets commencent alors leur trajet dans les couches de plus haut niveau. C'est à ce moment-là qu'ils rencontrent le point d'entrée PREROUTING. Les règles des chaînes PREROUTING des tables mangle et nat sont appliquées à ce moment. Ces chaînes précèdent le code de routage, qui est en charge de déterminer le trajet que le paquet devra suivre par la suite à partir de l'adresse destination des paquets. C'est donc dans ces chaînes que l'on pourra entre autres modifier l'adresse destination des paquets, si l'on veut faire une translation d'adresse destination. Cette opération se fait typiquement dans la table nat.

Les paquets qui passent le point d'entrée PREROUTING sont ensuite orientés par le code de routage de Linux. S'ils sont à destination de la machine locale, ils rencontrent un autre point d'entrée : le point d'entrée INPUT. Les règles des chaînes INPUT des tables mangle et filter sont exécutées à ce moment. C'est donc à ce niveau que l'on peut empêcher un paquet d'entrer dans le système, ce qui se fait naturellement dans la table filter.

Les autres paquets doivent être transférés vers une autre machine, souvent par une autre interface réseau. Ils atteignent donc le point d'entrée FORWARD. Ce point d'entrée permet de contrôler les paquets qui transitent au travers d'une passerelle. Les paquets y traversent les chaînes FORWARD des tables mangle et filter, cette dernière étant justement dédiée au filtrage des paquets qui transitent par la passerelle.

Les paquets qui sont acceptés par les chaînes FORWARD retournent ensuite dans le code de routage du noyau, afin de déterminer l'interface réseau par laquelle ils doivent être réémis. Une fois cela réalisé, ils sont prêts à être réémis, mais ils doivent auparavant traverser les chaînes des tables abonnées au point d'entrée POSTROUTING. Il s'agit bien sûr des chaînes POSTROUTING des tables mangle et nat. C'est dans cette dernière chaîne que se font les translations d'adresse source.

Enfin, les paquets émis par la machine locale à destination de l'extérieur doivent impérativement passer par le point d'entrée OUTPUT, qui exécute les chaînes OUTPUT des tables mangle, nat et filter. C'est donc à ce niveau que l'on pourra modifier les adresses destination des paquets de la machine locale avant leur routage et effectuer le filtrage des paquets sortants, dans les chaînes OUTPUT des tables nat et filter. Les paquets qui se révèlent avoir le droit de sortir traversent alors de code de routage, puis, tout comme les paquets qui ont été transférés, passent par le point d'entrée POSTROUTING.

Les fonctionnalités de Netfilter sont toutes fournies par le noyau lui-même, aussi leur configuration doit-elle se faire au niveau du noyau. La manière de procéder pour configurer le noyau a été indiquée dans le paragraphe traitant de la compilation du noyau. Les options à activer pour mettre en place les fonctionnalités de filtrage des paquets et de translation d'adresse sont les suivantes :

• « Network packet filtering (replace ipchains) », pour activer les fonctionnalités de filtrage des paquets en général ;
• « Network packet filtering debugging », pour obtenir les messages de débogage du noyau. Ces messages peuvent être très utiles pour mettre au point les règles de filtrage ;
• « Connection tracking (required for masq/NAT) » (menu « IP: Netfilter Configuration »), pour permettre le suivi des connexions auxquelles appartiennent les paquets IP reçus par la passerelle. Cette option est nécessaire pour réaliser un partage de connexion à Internet ;
• « FTP protocol support », pour permettre la gestion des connexions FTP, qui exigent un traitement particulier pour les translations d'adresses ;
• « IP tables support (required for filtering/masq/NAT) », pour permettre la gestion des tables de Netfilter ;
• « Packet filtering », pour inclure le support de la table « filter ». Cette option est nécessaire pour réaliser un pare-feu ;
• « REJECT target support », pour permettre le rejet des paquets (par défaut, seul l'abandon des paquets est fourni dans le code de filtrage) ;
• « Full NAT », pour inclure la table « nat » de Netfilter. Cette option est nécessaire pour réaliser un partage de connexion à Internet ;
• « MASQUERADE target support », pour permettre le masquerading afin de réaliser un partage de connexion à Internet.

Vous devrez ensuite compiler le noyau et les modules, et les installer comme indiqué dans la partie traitant de la compilation du noyau.

Note : Le noyau de Linux dispose d'un paramètre global permettant de contrôler le routage des paquets IP d'une interface réseau à une autre. Par défaut, ce paramètre est à 0, ce qui implique que la transmission des paquets ne sera pas autorisée. Il faut donc activer ce paramètre à chaque démarrage afin de pouvoir utiliser votre passerelle Linux. Cela peut être réalisé en écrivant la valeur 1 dans le fichier /proc/sys/net/ipv4/ip_forward du système de fichiers virtuel /proc/ :

echo "1" > /proc/sys/net/ipv4/ip_forward

La manipulation des chaînes et la manipulation des règles de Netfilter se fait grâce à l'outil iptables. Cette commande doit normalement avoir été installée par votre distribution. Toutefois, si ce n'est pas le cas, vous pouvez la compiler manuellement. Pour cela, il vous faudra récupérer l'archive des sources d'iptables. Cette archive peut être trouvée sur Internet. La version courante est la 1.2.9, aussi l'archive se nomme-t-elle iptables-1.2.6a.tar.bz2.

L'installation d'iptables ne pose pas de problème particulier en soi. Vous devrez d'abord décompresser l'archive avec les deux commandes suivantes :

bunzip2 iptables-1.2.9.tar.bz2
tar xf iptables-1.2.9.tar

puis modifier le fichier Makefile pour définir les répertoires d'installation dans les variables LIBDIR, BINDIR et MANDIR. En général, les répertoires utilisés seront respectivement les répertoires /usr/lib/, /usr/bin/ et /usr/man/. Une fois cela fait, il ne restera plus qu'à compiler le tout avec la commande make et à faire l'installation avec la commande make install.

Il est possible, grâce à iptables, d'effectuer toutes les opérations d'administration désirées sur les chaînes des tables de Netfilter. Vous pourrez donc créer des nouvelles chaînes, les détruire, définir les politiques par défaut, ainsi que manipuler les règles de ces chaînes (en ajouter, en supprimer ou en remplacer une). En fait, iptables dispose d'un grand nombre d'options, et seules les options les plus importantes seront présentées ici. Vous pouvez lire la page de manuel iptables si vous désirez plus de renseignements sur la manipulation des chaînes et des règles de filtrage du noyau.

IX-D-5-a. Manipulation des chaînes▲

iptables [-t table] -N chaîne

iptables [-t table] -X chaîne

iptables [-t table] -L chaîne

iptables [-t table] -F chaîne

IX-D-5-b. Manipulation des règles▲

iptables [-t table] -A chaîne [-s source] [-d destination] [-p protocole]
    [-i itfsource] [-o itfdest] [-j cible]

iptables -D chaîne numéro

iptables -P chaîne cible

Ce paragraphe a pour but de présenter quelques-unes des règles les plus classiques. Le but est ici de présenter les principales fonctionnalités d'iptables et de réaliser un pare-feu simpliste.

IX-D-6-a. Exemple de règles de filtrage▲

# Définition de la politique de base :
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Suppression des règles existantes :
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT

# Communications locales :
iptables -A INPUT  -d 127.0.0.0/8 -i lo -j ACCEPT
iptables -A OUTPUT -s 127.0.0.0/8 -o lo -j ACCEPT

# Connexions au réseau local :
iptables -A INPUT  -s 192.168.0.0/24 -i eth0 -j ACCEPT
iptables -A OUTPUT -s 192.168.0.1    -o eth0 -j ACCEPT

# Autorise les communications sortantes
# pour DNS, HTTP, HTTPS, FTP, POP, SMTP, SSH et IPSec :
iptables -A OUTPUT -o ppp0 -p UDP --dport domain -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport domain -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport http   -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport https  -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport ftp    -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport pop3   -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport smtp   -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport ssh    -j ACCEPT
iptables -A OUTPUT -o ppp0 -p AH  -j ACCEPT
iptables -A OUTPUT -o ppp0 -p ESP -j ACCEPT

# Autorise l'établissement des connexions protocolaires additionnelles :
iptables -A OUTPUT -o ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Autorise les paquets entrants pour les connexions
# que l'on a établies :
iptables -A INPUT -i ppp0 --match state --state ESTABLISHED,RELATED -j ACCEPT

# Autorise les connexions SSH entrantes :
iptables -A INPUT  -i ppp0 -p TCP --dport ssh -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --sport ssh -j ACCEPT

# Autorise les paquets ICMP intéressants :
iptables -A OUTPUT -p ICMP --icmp-type echo-reply -j ACCEPT
iptables -A INPUT  -p ICMP --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT
iptables -A INPUT  -p ICMP --icmp-type echo-reply -j ACCEPT
iptables -A INPUT  -p ICMP --icmp-type destination-unreachable -j ACCEPT

IX-D-6-b. Exemple de partage de connexion à Internet▲

# Effectue la translation d'adresses :
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

# Autorise le trafic DNS, HTTP, HTTPS,
# FTP, POP, SMTP et SSH au travers de la passerelle :
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -p UDP --dport domain -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -p TCP --dport domain -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -p TCP --dport http -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -p TCP --dport https -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -p TCP --dport ftp -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -p TCP --dport pop3 -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -p TCP --dport smtp -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -p TCP --dport ssh -j ACCEPT

# Autorise l'établissement des connexions protocolaires additionnelles :
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o eth0 --match state \
        --state ESTABLISHED,RELATED -j ACCEPT

# Autorise le trafic en retour pour les connexions établies par les clients :
iptables -A FORWARD -i ppp0 -d 192.168.0.0/24 --match state \
        --state ESTABLISHED,RELATED -j ACCEPT

# Autorise le trafic ICMP :
iptables -A FORWARD -p ICMP --icmp-type echo-request -j ACCEPT
iptables -A FORWARD -p ICMP --icmp-type echo-reply -j ACCEPT
iptables -A FORWARD -p ICMP --icmp-type destination-unreachable -j ACCEPT

# Activation du routage :
echo "1" > /proc/sys/net/ipv4/ip_forward

# Restreint la taille des paquets des connexions TCP
# lors de leur établissement :
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS -o ppp0 \
    --clamp-mss-to-pmtu

La configuration des autres machines du réseau est très simple. Vous devrez tout d'abord définir la machine possédant la connexion à Internet comme passerelle par défaut de tous vos postes clients. Cette opération peut se réaliser de différentes manières selon le système d'exploitation utilisé par ces machines. Sous Linux, il suffit d'utiliser la commande suivante :

route add default gw passerelle eth0

où passerelle est l'adresse de votre passerelle vers Internet sur le réseau local. Cette commande suppose que l'adaptateur réseau utilisé est eth0

La deuxième étape est ensuite de donner accès aux postes clients au DNS de votre fournisseur d'accès. Cela permettra en effet d'utiliser les noms de machines autres que ceux de votre réseau local. Encore une fois, la manière de procéder dépend du système utilisé. Sous Linux, il suffit d'ajouter les adresses IP des serveurs de noms de domaine de votre fournisseur d'accès dans le fichier de configuration /etc/resolv.conf.

Si les clients ont des difficultés à accéder à certaines pages Web, c'est que le MTU (« Maximum Transmission Unit », taille maximum des paquets réseau) est trop élevé. Ceci se corrige généralement tel qu'on l'a indiqué dans la définition des règles de la passerelle. Toutefois, si les ordinateurs qui bénéficient du partage de connexion à Internet continuent d'avoir des problèmes, c'est que le MTU de la route permettant d'accéder aux sites Web posant problème n'a pas pu être déterminé correctement. Dans ce cas, il faut le trouver soi-même, et le fixer dans la configuration réseau des clients. Pour cela, le plus simple est d'utiliser la commande ping avec son option -s sur les clients, avec plusieurs tailles de paquets possible. La taille maximum est de 1500 octets sur Ethernet. En général, une taille de 1400 octets convient :

ping -s 1400 adresse

Une fois le MTU correctement déterminé, il suffit de fixer cette valeur lors de la configuration des interfaces réseau des clients :

ifconfig interface mtu taille

interface représente ici l'interface à configurer, et taille la taille maximum trouvée à l'aide de ping.

Note : La taille effective du MTU est en réalité la taille fournie à la commande ping plus vingt-huit octets, car les paquets utilisés contiennent toujours l'en-tête ICMP en plus des données générées par ping.

IX-E-1-a. Réduction du nombre des services▲

IX-E-1-b. Définition de règles de contrôle d'accès▲

démons : machines [: commande]

# Exemple de fichier /etc/hosts.deny :
ALL : ALL

# Exemple de fichier /etc/hosts.allow :
telnetd, ftpd : LOCAL

only_from =

only_from += 192.168.0.0/24 127.0.0.1

disabled = servers services xadmin

IX-E-1-c. Contrôle des utilisateurs au niveau des services▲

# Exemple de fichier /etc/securetty
tty1
tty2
tty3
tty4
tty5
tty6

# Exemple de fichier /etc/ftpusers
root
uucp
mail

Les protocoles réseau de haut niveau ne garantissent en général pas la confidentialité des données qu'ils transmettent sur le réseau, ce qui signifie qu'elles peuvent être lues par tout le monde. Ils n'en garantissent pas non plus l'intégrité, chacun pouvant les modifier à volonté et fausser ainsi la communication. Ces défauts sont incurables, car ils sont en réalité inhérents au protocole IP lui-même. En effet, ce protocole a été conçu initialement pour assurer l'acheminement des informations, et les protocoles de haut niveau basés sur lui se contentent généralement de la garantie de livraison.

Note : La confidentialité des données est le fait que seules les personnes autorisées peuvent y accéder. L'intégrité des données est le fait que les données n'ont pas été altérées ou modifiées de manière non autorisée. Enfin, l'authenticité des données est le fait que les données sont certifiées comme provenant bien de celui qui prétend en être l'émetteur.

Généralement, le moyen le plus sûr pour garantir la confidentialité des données est de les chiffrer de telle sorte que seuls les destinataires autorisés puissent les déchiffrer et donc y accéder. C'est pour cette raison que la cryptographie, ou science du chiffrement est souvent utilisée pour résoudre les problèmes de sécurité informatique. Mais la cryptographie fournit également les techniques nécessaires pour assurer l'intégrité des données, généralement en calculant une empreinte ou condensé cryptographique des données. En effet, les algorithmes de calcul des empreintes sont conçus pour fournir des résultats très différents même si les données ne sont modifiées que très légèrement. Ainsi, si une personne mal intentionnée modifie un tant soit peu les données, le recalcul de l'empreinte associée indiquera tout de suite la supercherie. Enfin, l'authenticité des données peut être assurée en faisant en sorte que leur émetteur puisse prouver son identité. Cela se fait généralement en exigeant qu'il puisse répondre à une question dont on sait que lui seul connaît la réponse. Toute la difficulté est alors de trouver un système d'authentification où celui qui pose la question ne doit lui-même pas en connaître la réponse (faute de quoi celui qui pose la question pourrait se faire passer pour celui qui doit répondre !).

Note : Il est évident que pour garantir la confidentialité et l'authenticité des données, il faut garantir l'authenticité des interlocuteurs. En effet, sans cela, une tierce personne pourrait s'intercaler entre deux interlocuteurs et faire croire à chacun qu'il est l'autre. Même dans un canal de communication chiffré, cette personne serait en mesure de déchiffrer les messages dans les deux sens, voire même de les modifier et d'en recalculer les empreintes. Cette technique d'interposition s'appelle l'attaque du « man in the middle » (« l'homme du milieu » en Français)

Il est donc nécessaire, du fait des faiblesses des protocoles réseau standards, de recourir à des solutions cryptographiques pour fournir les services de confidentialité, d'authenticité et d'intégrité des données. Parmi ces solutions, les plus utilisées sont sans doute le protocole SSH (abréviation de l'anglais « Secure SHell ») et l'extension IPSec au protocole IP. Cette extension a initialement été développée pour le successeur du protocole IP, à savoir le protocole IPv6, mais a également été adaptée pour fonctionner avec l'implémentation actuelle d'IP.

IX-E-2-a. Principes de base de cryptographie▲

Tout d'abord, commençons par quelques définitions, beaucoup d'articles disponibles actuellement utilisant un vocabulaire imprécis. Le chiffrement (également appelé à tord cryptage), est l'opération qui consiste à transformer une information en clair en une information codée afin d'éviter qu'elle ne puisse être utilisée par une personne non autorisée. Le déchiffrement est l'opération inverse du chiffrement, qui permet donc de retrouver l'information initiale à partir de l'information codée. Le décryptage est l'opération qui consiste à déchiffrer une information sans y être autorisé. La cryptographie est la science qui se charge d'étudier la manière de chiffrer les informations. La cryptoanalyse est l'étude des moyens de décryptage. Cette science va de pair avec la cryptographie, puisqu'elle permet de déterminer la fiabilité des techniques mises en œuvre pour le chiffrement. Enfin, un pirate (également appelé « cracker ») est une personne désirant s'introduire de manière illicite dans un système, ou désirant détourner une application de son contexte d'utilisation normal. Il ne faut pas confondre les crackers avec les hackers, qui sont des personnes extrêmement compétentes en informatique et qui ne font rien de mal (par exemple, les développeurs du noyau Linux sont souvent des hackers).

Il existe un grand nombre de techniques de cryptographie, qui sont plus ou moins efficaces. La première technique, qui est aussi la plus simple et la moins sûre, est celle qui consiste à utiliser un algorithme de chiffrement réversible (ou une paire d'algorithmes ayant un effet inverse l'un de l'autre) pour chiffrer une information. Dans ce cas, la sécurité des données est assujettie au maintien au secret de l'algorithme utilisé. Il est évident que ce type de technique n'est pas utilisable avec les logiciels dont les sources sont diffusées (comme Linux), puisque l'algorithme est alors connu de tout le monde. C'est également la technique la moins sûre, parce qu'il est en général très facile de déterminer cet algorithme. Un exemple d'un tel algorithme est le codage classique qui consiste à décaler toutes les lettres de l'alphabet (A devient B, B devient C, etc.).

Une autre technique se base sur un algorithme connu de tout le monde, mais dont l'effet est paramétré par une clef tenue secrète. Le déchiffrement des informations ne peut se faire que si l'on connaît cette clef. Les algorithmes de ce type sont souvent qualifiés de « symétriques », en raison du fait que la clef utilisée pour le déchiffrement est la même que celle utilisée pour le chiffrement. Cette technique n'est satisfaisante que dans la mesure où les personnes qui communiquent peuvent s'échanger cette clef de manière sûre. La clef utilisée ne devant être connue que des personnes autorisées à participer à la communication, cet échange doit se faire soit de visu, soit dans un canal déjà chiffré (mais dans ce cas, il faut échanger la clef de déchiffrement du canal, et on se retrouve devant le problème de l'œuf et de la poule), soit à l'aide d'un protocole d'échange de clef sûr. Les algorithmes de ce type sont également connus sous le nom d'algorithmes à clef secrète en raison de cette particularité. Il existe un grand nombre d'algorithmes à clef secrète, les plus connus étant DES, AES et IDEA.

La technique la plus sûre actuellement, et aussi la plus rusée, est d'utiliser un algorithme de chiffrement asymétrique. À la différence des algorithmes symétriques, les algorithmes asymétriques utilisent deux clefs différentes et duales pour le chiffrement et le déchiffrement. Ces algorithmes se basent sur des fonctions mathématiques dont la fonction inverse est extrêmement difficile à déterminer sans une information également difficile à calculer. Cette information fait office de clef permettant de retrouver l'information en clair. Toute la ruse ici est que la clef servant au déchiffrement peut ne plus être échangée du tout, ce qui supprime la nécessité de réaliser un échange de clefs généralement risqué. En fait, seule la clef de chiffrement doit (et peut sans crainte) être publiée. C'est en raison de cette propriété que les algorithmes asymétriques sont également appelés algorithmes à clef publique.

Le principe des algorithmes asymétriques est le suivant. Une clef publique, utilisée pour chiffrer les informations, est fournie à tout le monde, et seul celui qui dispose de la clef privée associée à cette clef publique peut déchiffrer le texte. Toute personne qui désire communiquer avec le propriétaire de la clef publique utilise celle-ci pour chiffrer les informations qu'il doit lui transférer. Ainsi, du fait que seul le destinataire dispose de la clef de déchiffrement (sa clef privée), il est le seul à pouvoir récupérer ces informations. Il est donc possible d'échanger des informations de manière sûre avec tous les intervenants en utilisant simplement leurs clefs publiques respectives. Aucun échange d'information sensible n'est effectué en clair. Les algorithmes à clef publique les plus connus sont RSA et DSA.

La gestion des clefs des algorithmes à clef publique est techniquement laborieuse, de même que les calculs mis en œuvre par les algorithmes utilisés. Il est donc courant d'amorcer une communication avec un algorithme à clef publique, comme RSA par exemple, puis de l'utiliser pour échanger une clef secrète permettant de poursuivre la communication avec un algorithme symétrique. Il existe également des algorithmes spécialisés dans les échanges de clefs dans un canal non sûr, par exemple l'algorithme Diffie Hellman.

Enfin, il existe des algorithmes de chiffrement à sens unique qui ne permettent pas de retrouver l'information initiale, mais qui sont utilisés pour calculer une empreinte des informations à transférer. Cela permet d'identifier l'information de manière unique. Ces algorithmes sont donc souvent utilisés pour garantir l'intégrité des données diffusées dans un environnement peu sûr. Pour cela, celui qui réalise la diffusion chiffre un condensé des informations diffusées avec sa clef privée. Tout le monde peut donc déchiffrer ce condensé avec la clef publique de cette personne, et vérifier que le message qu'ils reçoivent a bien la même empreinte. Chacun a donc la certitude que le message provient bien de son auteur, car toute modification du message changerait son empreinte d'une part, et il est impossible de chiffrer cette nouvelle empreinte sans connaître la clef privée de l'expéditeur. Les algorithmes de calcul d'empreinte les plus connus sont MD5 et SHA.

Note : Notez que les algorithmes de chiffrement à clef publique nécessitent toujours que l'on soit sûr que l'on utilise la bonne clef publique pour s'adresser à une personne. Or, rien ne nous garantit que la clef publique d'une personne diffusée sur le réseau provienne bien de cette personne ! Il est donc toujours nécessaire d'échanger les clefs publiques de main à main, avec vérification de l'identité de la personne avec qui l'échange se fait. Il est également possible de recourir à une tierce personne digne de confiance et dont on connaît déjà la clef publique pour garantir que la clef que l'on reçoit est bien celle de la personne qui prétend en être le propriétaire. On peut ainsi construire ce qu'on appelle un « réseau de confiance », dans lequel chacun sait que quelqu'un en qui il a confiance, directement ou indirectement, a authentifié ses interlocuteurs.

Bien entendu, tout cela est contraignant. Mais, contrairement aux algorithmes de chiffrement à clef secrète, il n'est pas grave de perdre les clefs échangées avec les algorithmes asymétriques, puisque ces clefs sont destinées à être publiques…

IX-E-2-b. Utilisation de SSH▲

./configure --prefix=/usr --sysconfdir=/etc/ssh --with-tcp-wrappers --with-pam

make
make install

ssh-keygen [-t type]

# Paramètres de connexion :
Port 22
ListenAddress 0.0.0.0
KeepAlive yes

# Protocoles utilisables :
Protocol 2

# Chemin sur les fichiers de clefs :
HostKey /etc/ssh_host_rsa_key
HostKey /etc/ssh_host_dsa_key

# Paramètres des messages de traces :
SyslogFacility AUTH
LogLevel INFO

# On définit les modes d'authentification utilisables :

# Authentification par clef publique :
RSAAuthentication no
PubkeyAuthentication yes

IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no

# Authentification par mot de passe :
PasswordAuthentication no
PermitEmptyPasswords no

# Options générales :

# L'utilisateur root ne doit pouvoir se loguer qu'en local :
PermitRootLogin no

# Utilise le compte non privilégié sshd
# pour les communications réseau :
UsePrivilegeSeparation yes

# On n'autorise la connexion que pour les utilisateurs dont
# les fichiers de configuration sont correctement protégés :
StrictModes yes

# Encapsulation automatique du protocole X :
X11Forwarding yes
X11DisplayOffset 10

# Affichage des informations habituelles au login :
PrintMotd no
PrintLastLog yes

ssh [-l nom] machine [commande]

ssh nom@machine [commande]

ssh -Llocal:serveur:port machine [commande]

ssh -Rport:client:local machine [commande]

IX-E-2-c. Utilisation d'IPSec▲

#!/usr/sbin/setkey -f

# Vide la base de données des SAs :
flush;

# Vide la base de données des SPs :
spdflush;

# Définit les SAs pour le protocole AH :
# add source dest protocole SPI algo clef
add 170.20.57.31 170.20.58.40 ah 0x200 \
      -A hmac-md5 0x848255320c7fd11b6082f9628f078af7;
add 170.20.58.40 170.20.57.31 ah 0x201 \
      -A hmac-md5 0xcd23ef4b73ea54b626d16092293a298a;

# Définit les SAs pour le protocole ESP :
# add source dest protocole SPI algo clef
add 170.20.57.31 170.20.58.40 esp 0x300 \
      -E 3des-cbc 0xe6933d365096e13be514ea1d881d87371100b15119e2ffb9;
add 170.20.58.40 170.20.57.31 esp 0x301 \
      -E 3des-cbc 0xb2b630c9e9692c36d248b7206bda17c47f772f96290ac05f;

# Définit les politiques :
# spadd source dest protocole -P politique
# politique = direction action regles
# regle = ipsecp/mode/options/niveau
# options = règles de définition des tunnels
# niveau = use ou require
spdadd 170.20.57.31 170.20.58.40 any -P out ipsec
        esp/transport//require
        ah/transport//require;

spdadd 170.20.58.40 170.20.57.31 any -P in ipsec
        esp/transport//require
        ah/transport//require;

dd if=/dev/random count=n bs=1 | xxd -ps

# Définit la politique de sécurité sur 170.20.58.40 :
spdadd 170.20.57.31 170.20.58.40 any -P in ipsec
        esp/transport//require
        ah/transport//require;

spdadd 170.20.58.40 170.20.57.31 any -P out ipsec
        esp/transport//require
        ah/transport//require;

#!/usr/sbin/setkey -f

# Vide la base de données des SAs :
flush;

# Vide la base de données des SPs :
spdflush;

# Définit les SAs pour les en-têtes :
# add source dest protocole SPI algo clef
add 170.20.57.31 170.20.58.40 ah 0x200 -m tunnel -A hmac-md5 0x848255320c7fd11b6
082f9628f078af7;
add 170.20.58.40 170.20.57.31 ah 0x201 -m tunnel -A hmac-md5 0xcd23ef4b73ea54b62
6d16092293a298a;

# Définit les SAs pour les paquets :
# add source dest protocole SPU algo clef
add 170.20.57.31 170.20.58.40 esp 0x300 -m tunnel -E 3des-cbc 0xe6933d365096e13b
e514ea1d881d87371100b15119e2ffb9;
add 170.20.58.40 170.20.57.31 esp 0x301 -m tunnel -E 3des-cbc 0xb2b630c9e9692c36
d248b7206bda17c47f772f96290ac05f;

# Définit les politiques :
# spadd source dest protocoles politique
# politique = direction action regles
# regle = ipsecp/mode/options/niveau
# options = règles de définition des tunnels
# niveau = use ou require
spdadd 192.168.20.2 192.168.20.1 any -P in ipsec
        esp/tunnel/170.20.58.40-170.20.57.31/require
        ah/tunnel/170.20.58.40-170.20.57.31/require;

spdadd 192.168.20.1 192.168.20.2 any -P out ipsec
        esp/tunnel/170.20.57.31-170.20.58.40/require
        ah/tunnel/170.20.57.31-170.20.58.40/require;

echo 1 > /proc/sys/net/ipv4/ip_forward

openssl req -new -nodes -newkey rsa:1024 -sha1 \
   -keyform PEM -keyout machine1.private -outform PEM -out requete.pem

openssl x509 -req -in requete.pem \
   -signkey machine1.private -out machine1.public

openssl dgst clef.public

path certificate "/etc/ssl/certs";
remote anonymous
{
        exchange_mode main;
        certificate_type x509 "neptune.public" "neptune.private";
        verify_cert off;
        my_identifier asn1dn;
        peers_identifier asn1dn;
        proposal
        {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method rsasig;
                dh_group modp1024;
        }
}

sainfo anonymous
{
        pfs_group modp1024;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}

spdadd 0.0.0.0/0 serveur any -P in ipsec
        esp/transport//require
        ah/transport//require;

spdadd serveur 0.0.0.0/0 any -P out ipsec
        esp/transport//require
        ah/transport//require;

racoon -f /etc/racoon.conf

Nous avons vu dans la Section 6.8 que le programme en charge de demander l'identification des utilisateurs sur les terminaux de login était le programme getty. Ce programme ne permet aux utilisateurs que de s'identifier. Lorsque quelqu'un saisit son nom, getty se contente de lancer le processus login pour que celui-ci réalise l'authentification de l'utilisateur en lui demandant son mot de passe. En fait, getty peut très bien lancer un autre programme que login si l'identification n'est pas nécessaire sur le terminal qu'il gère, mais, en général, il faut identifier les utilisateurs.

Le programme getty est donc le point d'entrée par lequel il faut nécessairement passer pour utiliser le système. Dans le cas des terminaux virtuels, getty utilise une ligne de communication virtuelle, mais il peut parfaitement utiliser une ligne de communication réelle (c'est d'ailleurs ce pour quoi il a été conçu à l'origine). En particulier, il est possible de lancer un processus getty sur une ligne série, afin de permettre l'utilisation de terminaux réels connectés sur le port série correspondant.

La ligne série sur laquelle le processus getty fonctionne n'est pas forcément connectée à un terminal physique. Elle peut parfaitement être connectée à un modem. Dans ce cas, les utilisateurs devront appeler le serveur pour se connecter à l'aide d'un logiciel d'émulation de terminal. Il existe plusieurs logiciels permettant d'appeler un ordinateur distant et d'émuler un terminal. On citera par exemple le logiciel HyperTerminal de Windows, et les programmes Telix et Minicom. Ce dernier est couramment fourni avec les distributions de Linux, car c'est un logiciel libre.

En fait, il existe plusieurs variantes de getty, spécialisées pour des usages spécifiques, et permettant de faciliter le paramétrage du fichier de configuration /etc/inittab, dans lequel sont définis les terminaux disponibles. Les distributions de Linux sont souvent fournies avec les versions suivantes :

• mingetty, qui est un getty simplifié, couramment utilisé pour les terminaux virtuels ;
• mgetty, qui est une version spécialement conçue pour être utilisée sur les lignes série connectées à un modem. mgetty est en particulier capable d'initialiser les modems, de décrocher automatiquement la ligne lorsqu'il y a un appel, et de gérer les principales commandes des modems compatibles Hayes ;
• agetty, qui est une version complète de getty, utilisable aussi bien sur les lignes série (avec ou sans modem) que pour les terminaux virtuels. On utilisera de préférence cette version si l'on désire proposer une connexion par l'intermédiaire d'un câble null-modem.

Note : Les câbles null-modem sont des câbles série symétriques, qui permettent de relier deux ordinateurs par l'intermédiaire de leurs ports série. Ces câbles peuvent être trouvés chez la plupart des revendeurs de matériel informatique (vous pouvez également en fabriquer un vous-même si vous avez du temps à perdre).

Connaissant les diverses possibilités de ces programmes, proposer un service de connexion extérieur est relativement simple. Il suffit en effet de rajouter dans le fichier de configuration /etc/inittab les lignes permettant de lancer les programmes getty sur les bonnes lignes. Par exemple, pour offrir une connexion modem sur le deuxième port série (couramment appelé COM2), on ajoutera la ligne suivante :

S1:23:respawn:/usr/sbin/mgetty -n 3 -s 38400 ttyS1

Cette commande indique à init que mgetty doit être relancé à chaque fois qu'il se termine dans les niveaux d'exécution 2 et 3. Il doit prendre le contrôle de la ligne série utilisée par le fichier spécial de périphérique /dev/ttyS1, utiliser la vitesse de communication de 38400 bauds sur cette ligne (option -s) et ne décrocher qu'au bout de la troisième sonnerie (option -n). Vous pouvez bien entendu ajuster ces options en fonction de vos besoins.

En revanche, si l'on désire offrir une possibilité de connexion sur un port série par l'intermédiaire d'un câble null-modem, on utilisera plutôt le programme agetty. La ligne à ajouter dans le fichier /etc/inittab sera alors :

S1:123:respawn:/sbin/agetty -L 38400 ttyS1

Notez que les options sont quelque peu différentes. La vitesse de la ligne est donnée directement, et l'option -L indique que la ligne série utilisée est locale et ne gère pas le signal de porteuse CD (abréviation de l'anglais « Carrier Detect ») habituellement utilisé pour détecter les coupures téléphoniques. Encore une fois, vous pouvez adapter ces commandes selon vos besoins. N'hésitez pas à consulter les pages de manuel des programmes mgetty et agetty pour obtenir plus de renseignements.

Note : Vous pouvez tester vos connexions série à l'aide de l'émulateur de terminal minicom. S'il est installé sur votre distribution, vous pourrez le lancer simplement en tapant la commande minicom. Si vous l'utilisez sur une connexion directe (c'est-à-dire par un câble null-modem), vous devrez utiliser l'option -o, afin d'éviter que minicom n'envoie les codes d'initialisation du modem sur la ligne série.

Il se peut que vous ne parveniez pas à vous connecter sur vos ports série. Dans ce cas, la première des choses à faire est de regarder les paramètres de la ligne série à l'aide de la commande stty. Vous devriez vous intéresser tout particulièrement à la vitesse utilisée, et éventuellement vous assurer que les deux ports série des deux ordinateurs utilisent la même vitesse, ou que le modem est capable de gérer la vitesse utilisée par le port série. Si besoin est, vous pouvez modifier la vitesse d'un port série à l'aide de la commande stty. Par exemple, pour configurer le port série COM2 à la vitesse de 115200 bauds, vous devez taper la commande suivante :

stty -F /dev/ttyS1 ispeed 115200

Le protocole PPP utilisé par les fournisseurs d'accès à Internet est, comme son nom l'indique (« Point to Point Protocol », ou « protocole de liaison point à point »), un protocole permettant de relier deux ordinateurs uniquement. Ce protocole est complètement symétrique, et la mise en place d'un serveur PPP n'est pas plus compliquée que celle d'un client. Les liaisons PPP sont donc couramment utilisées pour relier deux réseaux distants par l'intermédiaire des lignes téléphoniques.

Lorsque nous avons présenté la configuration des accès à Internet, nous avons utilisé des options spécifiques à ce cas de figure afin de gérer le fait que les paramètres réseau sont imposés par le fournisseur d'accès. Dans le cas d'un serveur, ces paramètres ne sont pas nécessaires, puisque nous sommes cette fois à la place du fournisseur d'accès. En revanche, certains paramètres supplémentaires devront être spécifiés, notamment pour configurer le modem afin d'accepter les connexions externes.

En général, il faut lancer une instance du démon pppd pour chaque ligne série utilisée pour les connexions entrantes, car pppd ne peut gérer qu'une seule connexion à la fois. Cette technique peut paraître lourde, mais en fait elle est relativement pratique, car elle permet de spécifier des options spécifiques à chaque ligne série. Comme d'habitude, ces options peuvent être spécifiées sur la ligne de commande de pppd, mais elles peuvent également être enregistrées dans un fichier de configuration. Le fichier de configuration global /etc/ppp/options est généralement utilisé pour stocker les options communes à toutes les lignes série. Les options spécifiques à chaque ligne sont enregistrées quant à elles dans les fichiers options.ttySx, où ttySx est le nom du fichier spécial de périphérique utilisé pour accéder à cette ligne. L'usage de ces fichiers de configuration permet de simplifier notablement les lignes de commandes utilisées pour lancer pppd.

La ligne de commande à utiliser pour lancer pppd en mode serveur diffère peu de celle utilisée pour établir une connexion PPP en tant que client. Les deux principales différences proviennent du fait que :

• le serveur doit spécifier l'adresse IP qu'il utilisera pour l'interface PPP et l'adresse IP qu'il donnera au client lors de l'établissement de la liaison ;
• le script chat utilisé ne doit pas composer un numéro, mais initialiser le modem pour qu'il réponde aux appels entrants.

Les adresses IP sont spécifiées en ligne de commande à l'aide de la syntaxe suivante :

locale:distante

où locale est l'adresse IP de l'interface PPP du serveur, et distante est l'adresse IP que le client recevra lorsqu'il se connectera. Ces deux adresses peuvent appartenir au même réseau (auquel cas le lien PPP constitue un réseau en soi) ou non (le lien PPP constitue alors pas un pont entre deux réseaux distincts). Ainsi, l'option suivante :

192.168.30.1:192.168.31.1

indiquera à pppd que l'adresse IP de l'interface PPP locale sera 192.168.30.1, et que les clients qui se connecteront sur la ligne correspondante devront recevoir l'adresse 192.168.31.1.

Notez que les adresses utilisées ici font partie des adresses IP réservées pour les réseaux locaux. Ce n'est pas ce que font les fournisseurs d'accès à Internet en général, car ils disposent d'un ensemble d'adresses IP réelles redistribuables, mais les adresses réservées sont parfaitement utilisables. Le seul cas où cela pourrait être gênant serait si l'on voulait faire passer les adresses des deux passerelles de la liaison PPP sur Internet, mais les paquets utilisant ces adresses ne circulent justement que sur cette liaison (à moins que les passerelles ne se trouvent sur des réseaux locaux et utilisent des adresses de ces réseaux pour la liaison PPP, auquel cas, de toute manière, il faudrait utiliser la technique du masquerading pour connecter ces réseaux sur Internet).

Le script d'initialisation du modem, quant à lui, peut être spécifié à l'aide de l'option init de pppd. Cette option fonctionne exactement comme l'option connect que l'on a utilisée pour établir la liaison téléphonique dans la Section 9.3.2. La différence est ici que l'on ne cherche pas à composer un numéro de téléphone, mais plutôt à initialiser le modem pour qu'il décroche automatiquement la ligne lorsqu'il reçoit un appel.

Il existe malheureusement plusieurs dialectes de langages de commandes utilisés par les modems. En général, chaque modem dispose donc de ses propres commandes, et il faut consulter sa documentation pour savoir leurs syntaxes. Malgré cela, ce n'est pas trop gênant, car la plupart des modems sont compatibles avec le standard Hayes, dont les commandes sont bien connues. Pour l'initialisation d'un modem pour un serveur, les commandes d'initialisation suivantes seront très utiles :

Finalement, la ligne de commande à utiliser est donc la suivante :

pppd port vitesse detach modem crtscts init "/usr/sbin/chat -v \
        -f /etc/ppp/script" &

où port est le nom du fichier spécial de périphérique à utiliser pour cette connexion, par exemple /dev/ttyS0, vitesse est la vitesse de la ligne, par exemple 115200, et /etc/ppp/script est le nom du fichier du script chat devant servir à l'initialisation du modem. L'option detach permet de demander à pppd de se détacher du terminal courant, afin que l'on puisse le lancer en arrière-plan.

Vous trouverez ci-dessous un script chat d'exemple, permettant de spécifier les options vues ci-dessus :

"" ATZ
OK ATS0=1
OK AT&C1
OK AT&K3
OK ""

Note : Vous remarquerez qu'il n'est pas nécessaire, contrairement à ce que l'on a vu lors de la configuration d'un client PPP, de spécifier le nom de l'utilisateur et le protocole d'identification et d'authentification utilisé. Cela est normal, car le serveur n'a pas à s'identifier auprès de la machine cliente en général (il peut bien entendu le faire s'il le désire, mais dans ce cas seuls les clients capables de gérer ce type de connexion pourront se connecter).

En revanche, il peut être nécessaire d'exiger que les clients s'identifient et s'authentifient à l'aide de l'un des protocoles PAP ou CHAP. Pour cela, il suffit simplement d'ajouter les noms des clients et leurs secrets respectifs dans les fichiers de secrets /etc/ppp/pap-secrets et /etc/ppp/chap-secrets, et d'ajouter l'une des options require-pap ou require-chap sur la ligne de commande du démon pppd. Remarquez que le format des fichiers pap-secrets et chap-secrets est le même aussi bien pour les connexions entrantes que pour les appels vers l'extérieur. Cela signifie que l'on doit donner d'abord le nom du client, ensuite le nom du serveur, et ensuite son secret et enfin la liste des adresses IP que les clients peuvent utiliser.

Remarquez également que la colonne spécifiant la liste des adresses IP ne doit pas rester vide lorsqu'on désire créer un secret pour le serveur. En effet, pppd se base sur l'adresse IP de la machine distante et sur le nom du client pour déterminer le secret à utiliser lors de l'authentification. Cependant, si l'on désire utiliser les mêmes secrets pour toutes les lignes (et donc pour toutes les adresses que le client peut se voir imposer), on pourra utiliser une étoile. Cela signifie que toutes les adresses correspondront à la ligne, et seul le nom du client sera utilisé pour déterminer le secret à utiliser. Par exemple, si le serveur se nomme monserveur et le poste client s'appelle jdupont, on utilisera la ligne suivante :

#Client      Serveur          Secret     Adresses
jdupont    monserveur         gh25k;f      *

Lorsque la liaison PPP est établie, le démon pppd configure l'interface réseau correspondante. Le protocole utilisé par défaut est bien entendu le protocole IP. En général, il est nécessaire de configurer cette interface afin de spécifier les règles de routage permettant au client d'envoyer et de recevoir des paquets. Lors de l'établissement de la liaison, le démon pppd ajoute donc automatiquement une règle de routage pour indiquer que tous les paquets à destination de l'adresse du client doivent passer par l'interface ppp de la liaison courante. Cette règle convient dans la majorité des cas, et en tout cas pour les fournisseurs d'accès à Internet, car le client ne dispose que d'une seule machine. En revanche, si la liaison PPP est utilisée pour relier deux réseaux, les règles de routages par défaut ne suffiront plus, car des paquets à destination de toutes les machines du réseau distant doivent être envoyés via l'interface ppp (et inversement). Pour résoudre ces petits problèmes, on devra compléter ou modifier les scripts /etc/ppp/ip-up et /etc/ppp/ip-down. Ces deux scripts sont appelés par le démon pppd respectivement lors de l'établissement de la liaison PPP et lors de sa terminaison. On placera donc les commandes de routage complémentaires dans le script ip-up, et on fera le ménage correspondant dans le script ip-down.

Remarquez que ces deux scripts sont communs à toutes les interfaces ppp que les différents démons pppd peuvent utiliser. Ils sont également utilisés lors de l'établissement d'une connexion en tant que client. Leur modification devra donc être entourée d'un soin extrême. Afin de distinguer les différents cas d'utilisation, ces scripts sont appelés avec les paramètres suivants :

Un script classique fait un test sur le nom de l'interface réseau et ajuste les règles de routage en fonction de cette interface, en se basant sur les adresses IP locales et distantes reçues en paramètre. La plupart des distributions fournissent un script d'exemple que vous pouvez bien entendu modifier soit directement, soit à l'aide de leur outil de configuration.

Le démon pppd se termine à chaque fois que la liaison PPP se termine. Ce comportement est normal pour un client, mais ce n'est pas généralement ce que l'on cherche à faire pour un serveur. Il faut donc relancer pppd régulièrement à chaque fois qu'il se termine. Cela peut être réalisé en ajoutant sa ligne de commande dans le fichier de configuration /etc/inittab dans les niveaux d'exécution adéquats. Comme init impose une taille réduite sur les lignes de commandes des programmes qu'il peut lancer, il est nécessaire d'utiliser les fichiers d'options de pppd. Par exemple, si l'on veut assurer le service PPP pour une ligne entrante sur le deuxième port série dans les niveaux d'exécution 2 et 3, on utilisera la ligne suivante :

ppp1:23:respawn:/usr/sbin/pppd /dev/ttyS1 115200 \
192.168.30.1:192.168.31.1"

avec les options suivantes activées dans le fichier d'options /etc/ppp/options.ttyS1 :

# Initialisation du modem :
init "/usr/sbin/chat -v -f /etc/ppp/client.ttyS1
# Protocole d'authentification :
require-pap
# Contrôle de la ligne téléphonique :
modem
# Contrôle de flux matériel :
crtscts

La connexion entre deux ordinateurs par l'intermédiaire d'un câble série est un cas particulier des liaisons PPP. Les techniques utilisées sont les mêmes, mais plusieurs simplifications importantes peuvent être faites :

• les deux ordinateurs sont reliés directement par un câble null-modem, et aucun modem ne s'intercale pour compliquer les choses. Par conséquent, on peut supprimer les scripts chat d'initialisation et de connexion ;
• on a le contrôle physique sur les deux ordinateurs, ce qui implique que les mécanismes d'identification et d'authentification sont superflus. Il est donc inutile de préciser les secrets PAP ou CHAP sur chaque machine ;
• il n'y a que deux ordinateurs à relier, donc les règles de routages sont élémentaires ;
• enfin, les adresses choisies sont connues d'avance et peuvent être spécifiées de manière symétrique sur le client et le serveur.

Il découle de ces simplifications que l'établissement d'une liaison PPP au travers d'un câble null-modem est une opération très facile. Comme vous allez le constater, le protocole PPP est effectivement symétrique.

Sur le « serveur », il suffit de lancer par exemple la commande suivante :

pppd /dev/ttyS0 115200 192.168.30.1:192.168.31.1 detach crtscts &

Cette commande permet de lancer le démon pppd sur le port série COM1 (fichier spécial de périphérique /dev/ttyS0) en utilisant la vitesse de 115200 bauds (vitesse maximale généralement supportée par les ports série des ordinateurs), en utilisant l'adresse IP locale 192.168.30.1 et l'adresse IP distante 192.168.31.1. Le démon pppd doit se détacher du terminal, car il est lancé en arrière-plan. Enfin, le contrôle de flux matériel est utilisé (option crtscts).

La commande sur le « client » est absolument symétrique, puisque seules les adresses locales et distantes sont interverties :

pppd /dev/ttyS0 115200 192.168.31.1:192.168.30.1 detach crtscts &

Bien entendu, le port série utilisé peut être différent de celui du serveur, mais il est impératif que les deux ports série soient configurés pour utiliser les mêmes paramètres de communication (vitesse, nombre de bits de données, bit de parité, bit d'arrêt). Vous aurez donc peut-être à utiliser la commande stty pour fixer ces paramètres sur le serveur et sur le client.

Une fois ces deux commandes lancées, la connexion PPP est établie. Le démon pppd ajoute alors automatiquement une règle de routage pour acheminer les paquets d'un ordinateur à l'autre. Vous n'aurez donc pas à modifier les scripts /etc/ppp/ip-up et /etc/ppp/ip-down. Comme vous pouvez le constater, l'utilisation de PPP pour relier simplement deux ordinateurs n'est pas une opération très compliquée…

Le protocole DHCP est géré, au niveau serveur, par le démon dhcpd. Ce démon se configure par l'intermédiaire du fichier de configuration /etc/dhcpd.conf, dans lequel se trouvent les définitions des réseaux à configurer, ainsi que les différentes informations qui doivent être communiquées aux clients. Ce fichier de configuration peut contenir plusieurs déclarations de réseau différentes, chacune étant introduite par le mot clé subnet. Ces déclarations permettent de définir les options pour les clients de différents réseaux de manière indépendante, mais si certaines de ces options sont communes à tous vos sous-réseaux, vous pouvez les factoriser en tête du fichier dhcpd.conf. Par exemple, le fichier de configuration suivant :

# Exemple de fichier de configuration dhcpd.conf :
default-lease-time 600;
max-lease-time 86400;
option subnet mask 255.255.255.0;

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.10 192.168.1.100;
    range 192.168.1.150 192.168.1.200;
    option broadcast-address 192.168.1.255;
    option routers 192.168.1.1;
    option domain-name "monrezo.perso";
}

subnet 192.168.53.0 netmask 255.255.255.0 {
    range 192.168.53.10 192.168.53.254;
    option broadcast-address 192.168.53.255;
    option routers 192.168.53.2;
    option domain-name "autrerezo.org";
}

permet de configurer les deux réseaux 192.168.1.0 et 192.168.53.0 en spécifiant un masque de sous-réseau égal à 255.255.255.0 et une durée de bail d'adresse IP par défaut de 10 minutes (option default-lease-time) et maximale d'un jour (option max-lease-time). Vous remarquerez que ces dernières options utilisent la seconde comme unité de temps.

Comme vous pouvez le constater, la syntaxe du fichier de configuration dhcpd.conf n'est pas bien compliquée. Le mot clé subnet doit être suivi de l'adresse du réseau sur lesquels les clients à configurer par DHCP se trouvent. Le mot clé netmask doit être suivi quant à lui par le masque de ce sous-réseau. Les adresses IP attribuées aux clients peuvent être choisies dans différentes plages de valeurs, chacune étant spécifiée par le mot clé range suivi de l'adresse de début et de l'adresse de fin de la plage. Il est également possible d'attribuer des adresses fixes à certaines machines, avec la syntaxe suivante :

hardware ethernet 08:00:2b:4c:59:23;
fixed-address 192.168.1.101;

où les mots clés hardware ethernet introduisent l'adresse Ethernet de l'interface réseau de la machine cliente, et où fixed-address spécifie l'adresse IP que cette machine doit utiliser pour cette interface.

Enfin, un grand nombre d'options peuvent également être spécifiées, par exemple pour définir les adresses de diffusion (mot clé broadcast-address), les adresses des passerelles (mot clé routers), les noms de domaines (mot clé domain-name) ou encore les durées des bails accordés aux machines clientes (mots clés default-lease-time et max-lease-time). La liste complète des options utilisables est donnée dans la page de manuel dhcpd.conf et je vous invite à la consulter si vous désirez en savoir plus.

Lorsque vous aurez rédigé le fichier de configuration adapté à votre installation, il ne vous restera plus qu'à lancer le démon dhcpd. Celui-ci utilise la syntaxe suivante :

dhcpd interface0 [interface1 […]]

où interface0, interface1, etc., sont les interfaces réseau utilisées pour accéder aux réseaux à configurer en DHCP. Ces interfaces doivent être configurées avec des adresses de réseau pour lesquelles il est possible de trouver une section subnet correspondante dans le fichier de configuration /etc/dhcpd.conf. Enfin, la commande de démarrage du démon dhcpd pourra être placée dans les fichiers d'initialisation du serveur DHCP.

Note : Le démon dhcpd utilise les fonctionnalités d'accès direct aux cartes réseau et de filtrage des paquets du noyau Linux pour écouter sur le réseau les demandes de configuration par DHCP des clients. Par conséquent, vous devrez activer ces options dans la configuration du noyau si ce n'est déjà fait. Pour cela, il vous faudra cocher les options « Packet socket », « Packet socket: mmapped IO » et « Socket Filtering » du menu « Networking options ». Vous devrez également activer l'option « IP: multicasting » dans la liste des options pour le protocole IP afin de permettre au démon d'effectuer des émissions de paquets en mode broadcast. Le détail de la configuration et de la compilation du noyau a été vu dans la Section 7.3.

L'installation d'un serveur NFS est la solution de prédilection pour le partage des fichiers sous Unix. Il faut savoir cependant que NFS n'offre pas des performances remarquables d'une part, et qu'il ouvre des brèches dans la sécurité du système d'autre part.

Comme il l'a été dit ci-dessus, l'installation d'un serveur NFS requiert l'utilisation de programmes spécifiques. Plus précisément, NFS utilise deux démons pour fournir les services NFS aux machines clientes. Ces deux démons se nomment respectivement « mountd » et « nfsd ». Le premier démon prend en charge les requêtes de montage des systèmes de fichiers NFS, et nfsd effectue les requêtes d'accès aux fichiers pour les clients. Par ailleurs, ces deux démons utilisent les mécanismes d'appels de procédure à distance « RPC » (abréviation de l'anglais « Remote Procedure Call » de Sun Microsystems. Ces services sont désormais disponibles sur toutes les machines Unix et constitue la norme en la matière. Il est donc également nécessaire de mettre en place les services RPC avant de lancer les démons NFS.

Le principe de fonctionnement des appels de procédures à distance est le suivant. Chaque programme désirant fournir des services RPC écoute sur un port TCP ou UDP pour des requêtes éventuelles. Les clients qui veulent utiliser ces services doivent envoyer leurs requêtes sur ce port, en précisant toutes les informations nécessaires à l'exécution de cette requête : numéro de la requête et paramètres de la requête. Le serveur exécute cette requête et renvoie le résultat. Les bibliothèques RPC fournissent les fonctions nécessaires pour effectuer le transfert des paramètres et les appels à distance eux-mêmes.

En pratique cependant, les clients ne savent pas sur quel port le serveur RPC attend leurs requêtes. Un mécanisme a donc été mis en place pour leur permettre de récupérer ce port et communiquer ensuite avec le serveur. Chaque serveur RPC est identifié par un numéro de programme unique, ainsi qu'un numéro de version. Lorsqu'ils démarrent, les serveurs s'enregistrent dans le système en précisant le port sur lequel ils écouteront les requêtes. Les clients peuvent alors interroger le système distant pour demander le port sur lequel ils trouveront un serveur donné, à partir du numéro de programme et du numéro de version de celui-ci.

Il existe donc un service RPC particulier, nommé « portmapper », qui fournit aux clients qui le demandent les numéros de port des autres serveurs. Bien entendu, le portmapper doit être toujours contactable, ce qui implique qu'il utilise systématiquement le même numéro de port. Par convention, le portmapper est identifié par le numéro de programme 100000, et il écoute les requêtes des clients sur les ports 111 des protocoles TCP et UDP.

La mise en place des serveurs de fichiers passe donc par le lancement de ces trois démons : le démon portmapper, le démon mountd et le démon nfsd. Les fichiers exécutables de ces démons sont respectivement portmap, rpc.mountd et rpc.nfsd. Ils sont normalement placés dans le répertoire /sbin/ ou /usr/sbin/. Vous devrez donc lancer ces trois démons sur la machine serveur de fichiers, il est probable que votre distribution fasse le nécessaire dans ses scripts de démarrage.

Note : Il est prévu d'intégrer les fonctionnalités de serveur NFS dans le noyau de Linux. Cependant, le serveur de fichiers du noyau n'est pas encore finalisé, et ne sera donc pas décrit ici.

Une fois les démons lancés, vous pourrez configurer les systèmes de fichiers exportés par votre serveur. Ces systèmes de fichiers sont en fait de simples répertoires que vous mettez à disposition de certaines machines. La liste de ces répertoires est placée dans le fichier de configuration /etc/exports. Chaque ligne de ce fichier caractérise un répertoire accessible par les autres machines du réseau. Ces lignes utilisent le format suivant :

répertoire    machines

où répertoire est le chemin sur le répertoire à exporter, et machines est une liste de machines pouvant accéder à ce répertoire. Cette liste contient des noms de machines, des adresses IP ou des noms de réseaux, séparés par des espaces. Il est également possible d'utiliser les caractères génériques '?' et '*' afin de spécifier des groupes de machines.

Des options peuvent être utilisées pour chaque machine, à l'aide de la syntaxe suivante :

machine(options)

où machine est l'une des entrées de la liste de machines d'une ligne du fichier exports, et options est la liste des options pour cette entrée, séparées par des virgules. Les options les plus utilisées sont bien entendu ro et rw, qui permettent de fournir à cette machine ou à ce groupe de machine respectivement un accès en lecture seule et en lecture et écriture sur le répertoire.

Le problème fondamental de NFS est la sécurité. En effet, les fichiers sont exportés par défaut avec un identificateur d'utilisateur qui est celui qui possède le fichier sur la machine serveur. Or il est tout à fait possible que cet identificateur ne corresponde pas au même utilisateur sur tous les clients. Cela signifie que les utilisateurs des machines clientes peuvent parfaitement avoir accès à des fichiers qui ne leur appartiennent pas sur le serveur. Ce problème est fondamental, aussi faut-il le prendre en considération sérieusement.

NFS fournit plusieurs solutions pour assurer la sécurité sur les systèmes de fichiers exportés. La première, qui est aussi la plus restrictive, est d'attribuer les fichiers exportés à un utilisateur ne disposant de quasiment aucun droit (opération que l'on nomme souvent « squashing de l'utilisateur »). Cet utilisateur spécial est l'utilisateur « nobody », dont l'identificateur est 65534 par défaut. Ainsi, tous les clients accèdent à ces fichiers au nom de l'utilisateur nobody, et ne peuvent donc pas modifier les fichiers du serveur. Le squashing de l'utilisateur root est toujours réalisé par défaut, pour des raisons de sécurité évidentes.

La deuxième solution est nettement moins sûre. Elle nécessite de lancer le démon « ugidd » sur chaque machine client. Ce démon est appelé par le serveur NFS pour déterminer l'identificateur des utilisateurs du client à partir de leur nom. Ainsi, chaque fichier est exporté avec l'identificateur de l'utilisateur qui porte le même nom que celui qui possède le fichier accédé sur le serveur. Les problèmes de sécurité posés par cette solution sont énormes : rien ne garantit que deux utilisateurs distincts sur deux machines différentes ne puissent pas avoir le même nom d'une part, et un attaquant potentiel peut utiliser le démon ugidd pour obtenir la liste des utilisateurs de la machine cliente d'autre part (ce qui constitue déjà la moitié du travail pour s'introduire dans le système de la machine cliente). Cependant, cette solution est très pratique pour les réseaux dont on contrôle chaque machine, à condition de restreindre l'accès au démon ugidd au serveur uniquement, par exemple en ayant recours à tcpd.

La troisième solution est de définir sur le serveur l'association entre les identificateurs des utilisateurs du serveur et les identificateurs du client, ce pour chaque machine cliente. Cette technique est sûre, mais nettement plus compliquée à mettre en œuvre.

Enfin, la dernière solution est d'utiliser les services d'information du réseau NIS (abréviation de l'anglais « Network Information Service »), qui permettent de définir un certain nombre d'informations de manière globale sur un réseau. En particulier, il est possible de centraliser la définition des utilisateurs et des mots de passe. Cette solution est très lourde à mettre en œuvre, puisqu'elle nécessite de configurer NIS au préalable. Elle n'est donc mise en place que sur les grands réseaux, et un particulier n'a pas de raisons d'y recourir (à moins de vouloir explorer ces mécanismes bien entendu). Nous n'en parlerons donc pas.

Toutes ces techniques peuvent être activées à l'aide d'options fournies dans la liste des options pour chaque machine déclarée dans le fichier de configuration /etc/exports. Les options utilisées sont décrites ci-dessous :

• l'option all_squash permet d'exporter tous les fichiers comme appartenant à l'utilisateur nobody. C'est l'option la plus sûre, mais aussi la plus restrictive ;
• l'option map_daemon permet d'utiliser le démon ugidd, qui doit être lancé sur les machines clientes et accessibles du serveur. L'accès aux répertoires exportés sera refusé si ce démon ne peut être contacté par le serveur NFS. C'est certainement la solution la plus pratique pour un particulier ;
• l'option map_static=fichier permet d'utiliser un fichier de correspondance des identificateurs des utilisateurs du serveur NFS sur les identificateurs des utilisateurs de la machine cliente.

Comme on peut le voir, cette dernière option permet de définir spécifiquement, pour chaque machine, la correspondance des identificateurs d'utilisateurs. Le fichier fourni en paramètre à l'option map_static contient un certain nombre de lignes, chacune définissant l'association entre les identificateurs d'utilisateurs de la machine distante et les identificateurs de ces utilisateurs sur le serveur. Ces lignes sont introduites à l'aide du mot clé uid. Il est également possible de donner les correspondances sur les groupes des utilisateurs avec le mot clé gid :

# Exemple de fichier de correspondance d'identificateurs :
#    client     serveur
uid  0-99       -
uid  500-1000   1000
gid  0-49       -
gid  50-100     1000

Dans l'exemple donné ci-dessus, les utilisateurs ayant un identificateur compris entre 0 et 99 inclus seront associés à l'utilisateur nobody (ils subissent le « squashing »). Il en est de même pour les groupes allant de 0 à 49. En revanche, les utilisateurs dont les identificateurs vont de 500 à 1000 sur la machine cliente se voient respectivement considérés comme les utilisateurs d'identificateur 1000 à 1500 par le serveur NFS. De même, les groupes d'identificateurs 50 à 100 sont considérés comme les groupes d'identificateurs 1000 à 1050.

L'exemple qui suit va permettre d'éclaircir un peu ces notions. Il montre comment les trois types de contrôle des identificateurs peuvent être mis en place, pour trois types de clients différents :

# Exemple de fichier /etc/exports :

# Répertoire /pub : accessible de tout le monde, avec les droits
# de l'utilisateur nobody :
/pub    (ro,all_squash)

# Répertoire /home : accessible de toutes les machines du réseau local,
# avec contrôle des utilisateurs effectué par le démon rpc.ugidd :
/home   *.monrezo.org(map_daemon)

# Répertoire /usr : accessible par la machine 192.168.5.2, avec mapping
# des utilisateurs :
/usr    192.168.5.2(map_static=/etc/nfs/192.168.5.2.map)

Le fichier /etc/nfs/192.168.5.2.map utilisé dans la troisième ligne définit la correspondance entre les utilisateurs de la machine 192.168.5.2 et le serveur NFS :

# Fichier de correspondance pour 192.168.5.2 :
#       client  serveur
uid     0-99    -
uid     500     507
gid     0-49    -
gid     50      50

Les informations stockées dans le fichiers /etc/exports sont prises en compte lors de l'exécution de la commande exportfs. Cette commande est généralement exécutée à chaque démarrage de la machine dans les scripts de démarrage du système, avec l'option -a. Cette option permet d'exporter tous les systèmes de fichiers référencés dans /etc/exports, tout comme la commande mount utilise cette option pour monter tous les systèmes de fichiers au démarrage.

À chaque modification du fichier /etc/exports, il est nécessaire de signaler cette modification au démon mountd. Cela peut être fait simplement à l'aide de la commande suivante :

exportfs -a

Une fois la configuration du serveur NFS effectuée, il ne reste plus qu'à configurer les postes clients. Bien entendu, la manière de réaliser cela dépend du système utilisé. Nous allons voir ici comment accéder à un répertoire exporté par un serveur à partir d'une machine fonctionnant sous Linux.

Du point de vue du client, les fichiers accédés par NFS sont considérés comme des fichiers normaux d'un système de fichiers classique. Ils sont donc gérés directement par le noyau, en tant que système de fichiers à part entière. L'utilisation de NFS est donc directe, pour peu que l'on ait activé les fonctionnalités NFS dans le noyau.

Encore une fois, vous devrez modifier la configuration du noyau si celui fourni avec votre distribution ne gère pas les systèmes de fichiers NFS (ce qui est fort peu probable). La seule fonctionnalité à activer, en plus de la gestion du réseau bien entendu, est l'option « NFS filesystem support » du menu « Network File Systems » (ce menu est un sous-menu du menu « Filesystems » si vous utilisez la configuration en mode texte).

Lorsque le noyau sera compilé et installé, il sera capable d'utiliser les systèmes de fichiers NFS nativement. Vous n'aurez donc pas besoin des démons nfsd et mountd, tout sera pris en charge par le noyau. Cependant, si le serveur exporte ses répertoires avec l'option map_daemon, il sera nécessaire de lancer le démon ugidd sur la machine cliente (le fichier exécutable se nomme rpc.ugidd et se trouve dans le répertoire /usr/sbin/). Il est conseillé de lancer ce démon à partir d'inetd, en l'encapsulant à l'aide du démon tcpd.

Le montage d'un système de fichiers NFS se fait classiquement, avec la commande mount. Il suffit ici de préciser le type de système de fichiers « nfs » avec l'option -t, et d'utiliser la syntaxe suivante pour le fichier spécial de périphérique à utiliser :

machine:répertoire

où machine est le nom du serveur NFS, et répertoire est le chemin absolu sur le répertoire exporté par cette machine et auquel on désire accéder. Ainsi, si la machine « mon.serveur.nfs » exporte le répertoire « /mon/répertoire/exporté », la commande suivante permettra de monter ce système de fichiers NFS dans le répertoire /mnt :

mount -t nfs \
    mon.serveur.nfs:/mon/répertoire/exporté /mnt

Le système de fichiers NFS accepte des options permettant d'optimiser les transferts d'informations. Ces options peuvent être fournies en ligne de commande à mount à l'aide de l'option -o. Les plus utiles sont sans doute rsize, qui permet de fixer la taille des blocs de données transférés pour la lecture des fichiers, et wsize, qui permet de fixer cette taille pour l'écriture des fichiers. Il est recommandé d'utiliser des paramètres raisonnables afin d'éviter des erreurs de transfert et des pertes de données. La valeur par défaut est 1024, mais il est recommandé d'utiliser des blocs de taille 8192 pour obtenir de meilleures performances. Ainsi, la commande précédente pourra être optimisée comme suit :

mount -t nfs -o rsize=8192,wsize=8192 \
    mon.serveur.nfs:/mon/répertoire/exporté /mnt

Bien entendu, ces valeurs dépendent de la bande passante de votre réseau, et vous aurez sans doute à effectuer des tests de transferts de fichiers pour trouver les valeurs optimales.

Bien que les protocoles SMB et NFS soient profondément différents, les principes utilisés pour mettre en place un serveur SMB sont quasiment les mêmes que ceux utilisés pour un serveur NFS. L'installation d'un serveur SMB requiert en effet l'utilisation de deux démons qui prennent en charge les services fournis par les serveurs de fichiers SMB. Ces démons utilisent tous deux le fichier de configuration smb.conf, placé le plus souvent dans le répertoire /etc/. Seuls les serveurs doivent faire fonctionner ces démons, les clients Linux quant à eux se contentent d'utiliser le système de fichiers SMB du noyau.

Ces démons, ainsi que tous les outils nécessaires à l'utilisation du protocole SMB, sont fournis dans la suite logicielle « Samba », dont le nom est évidemment inspiré de « SMB ». Cette suite logicielle est distribuée sous la licence GNU et est donc complètement libre d'utilisation. Elle est normalement fournie avec toutes les distributions. La version actuelle est la 3.0.3. Si ce n'est pas celle fournie avec votre distribution, il est fortement recommandé d'effectuer une mise à jour.

L'installation de Samba ne pose pas de problème particulier. Nous ne la décrirons donc pas ici. Sachez cependant qu'elle est recommandée même sur les postes clients, car bien que les démons ne soient pas lancés sur ceux-ci, les outils permettant de se connecter à un serveur de fichiers sont fournis avec Samba et restent nécessaires.

Comme on l'a vu ci-dessus, le protocole SMB se base sur le protocole de bas niveau NetBIOS. NetBIOS est un protocole très primitif, qui n'utilise pas un mécanisme d'adressage semblable à celui de la plupart des protocoles modernes. Chaque machine est identifiée sur le réseau par un nom unique, qu'elle doit déclarer avant de pouvoir utiliser les ressources du réseau. Tout nouvel arrivant sur le réseau signale donc aux autres qu'il désire utiliser son nom, afin de déterminer si ce nom est déjà pris ou non par une autre machine.

L'un des plus gros défauts de NetBIOS est tout simplement qu'il n'est pas routable tel quel, et qu'il est impossible de structurer un réseau en se basant seulement sur les noms NetBIOS. C'est pour cette raison que l'on encapsule souvent NetBIOS dans un protocole plus évolué capable de traverser les routeurs, comme TCP/IP par exemple. C'est exactement ce que fait Samba, qui apparaît donc comme un service réseau Unix classique permettant de comprendre les paquets NetBIOS encapsulés dans les paquets TCP/IP. Cette technique suppose évidemment que tous les clients du réseau, y compris les postes Windows, soient configurés pour encapsuler NetBIOS dans TCP/IP. L'utilisation de TCP/IP est de toute manière fortement recommandée si l'on veut réaliser un réseau un tant soit peu sérieux, et les versions récentes de Windows utilisent également cette technique.

Outre les noms d'ordinateurs, le protocole NetBIOS permet de définir des groupes d'ordinateurs, qui contiennent tous les ordinateurs supposés échanger des informations couramment. Un ordinateur ne peut faire partie que d'un seul groupe, mais il peut également ne faire partie d'aucun groupe s'il le désire. Ces groupes d'ordinateurs sont créés uniquement en fonction du travail qu'ils ont à effectuer, et ne sont a priori absolument pas liés à leur emplacement géographique ni à leur emplacement sur le réseau. Ainsi, il est possible de communiquer avec tous les ordinateurs d'un groupe, un peu comme le protocole TCP/IP permet d'utiliser des adresses de diffusion. Dans le monde Windows, ces groupes de machines sont plus couramment dénommés des « workgroup », et il n'y a en fait aucune différence technique. Pour le protocole SMB, chaque ordinateur du réseau doit faire partie d'un groupe bien défini, bien que ce ne soit pas une nécessité au niveau de NetBIOS.

Lorsqu'un groupe de travail possède une base de données centrale permettant de réaliser l'authentification des utilisateurs lors des accès aux machines par le réseau, on dit qu'il s'agit d'un domaine. En pratique, un domaine n'est donc rien d'autre qu'un groupe de travail dont font partie un ou plusieurs serveurs d'authentification. Il existe plusieurs types de serveurs de domaine. Un serveur primaire est un serveur central, sur lequel se fait la gestion globale des utilisateurs. Outre un serveur primaire, un domaine peut également contenir un ou plusieurs serveurs de sauvegarde si nécessaire. Comme leur appellation l'indique, ces serveurs sont capables de remplacer le serveur primaire en cas de défaillance de celui-ci. Ils maintiennent donc une copie des tables d'utilisateurs, et la synchronisent régulièrement avec celle du serveur primaire. Enfin, un domaine peut contenir des serveurs membres, qui sont comme des serveurs de sauvegarde, à ceci près qu'ils ne peuvent pas remplacer le serveur de domaine primaire. Bien entendu, le domaine contient également les stations de travail classiques, qui effectuent des requêtes sur le serveur primaire.

Afin de gérer la liste des noms NetBIOS du réseau, Samba fournit le démon « nmbd ». Ce démon est essentiel au fonctionnement correct de Samba et doit donc toujours être lancé. Il peut également être configuré en tant que serveur WINS (abréviation de l'anglais « Windows Internet Name Server »), afin de pouvoir fournir les noms NetBIOS sur Internet. WINS est une technique développée par Microsoft pour résoudre le problème du nommage des postes de travail sur Internet. Un serveur WINS est donc à NetBIOS un peu ce qu'un serveur DNS est à TCP/IP. Le démon nmbd est installé classiquement dans le répertoire /usr/bin/ ou dans le répertoire /usr/sbin/. Vous devrez le lancer avec l'option -D, faute de quoi il ne démarrera pas en tant que démon :

/usr/sbin/nmbd -D

Le deuxième démon fourni par Samba est « smbd ». Celui-ci gère effectivement le protocole SMB, et est donc en charge d'effectuer la gestion des utilisateurs et des partages. Il doit être lancé également avec l'option -D si l'on veut qu'il démarre en tant que démon. Ce démon est normalement installé au même endroit que nmbd :

/usr/sbin/smbd -D

Vous pourrez éventuellement faire en sorte que ces démons soient lancés automatiquement en modifiant les scripts de démarrage de votre système. Une fois ces deux démons lancés, votre machine Linux se comportera exactement comme une machine Windows serveur classique. Ainsi, les ressources partagées par ce serveur seront accessibles par les clients SMB, comme les postes Windows par exemple.

Malheureusement, la plupart des clients SMB ne gèrent pas les notions avancées des systèmes de fichiers Unix. Le protocole SMB ne supporte d'ailleurs qu'une partie infime de ces fonctionnalités. De plus, la gestion des droits sur les fichiers exportés par un serveur de fichiers Windows se base généralement sur le modèle de sécurité des d'ACLs (« Access Control List »), plutôt que sur le modèle de sécurité Unix classique. Samba peut donc être configuré pour utiliser le support des ACLs natif des systèmes de fichiers Linux, ainsi que pour utiliser les modèles de sécurité primitifs des anciennes versions de Windows.

La première difficulté à résoudre concerne la gestion des droits d'accès aux fichiers des partages. Sous Unix, chaque fichier et chaque répertoire disposent de droits d'accès, et seuls les utilisateurs autorisés peuvent les manipuler. Dans le monde Windows, il n'y a quasiment pas de notion d'utilisateur, et en général pas de gestion de la sécurité. Seuls Windows NT/2000/XP disposent de ces fonctionnalités, à condition qu'ils utilisent des systèmes de fichiers NTFS et que le type de partage utilisé le permette.

En fait, la gestion de la sécurité se fait de manière globale, pour tous les fichiers d'un partage. Il existe principalement deux modes de contrôle d'accès aux partages SMB :

• le contrôle d'accès au niveau ressource, qui se fait à partir d'un mot de passe unique pour la ressource, sans tenir compte de l'utilisateur qui cherche à y accéder ;
• le contrôle d'accès au niveau utilisateur, qui nécessite de fournir un nom d'utilisateur et un mot de passe.

Le contrôle d'accès au niveau utilisateur nécessite de se trouver dans un domaine, et non dans un simple Workgroup. Il faut donc disposer d'un serveur de domaine afin de réaliser l'authentification des utilisateurs qui cherchent à accéder à ces ressources. Pour des raisons commerciales, Microsoft s'est arrangé pour que seuls Windows NT, Windows 2000 et Windows XP serveur puissent servir de contrôleurs de domaine, ce qui fait qu'il est impossible d'utiliser le contrôle d'accès au niveau utilisateur sur un réseau ne disposant que de machines sous Windows 95, 98, ou NT/2000/XP client (heureusement, Samba est capable de servir de contrôleur de domaine, cependant, nous ne verrons pas ce type de configuration). Il va de soi que le contrôle d'accès au niveau utilisateur est la seule solution réellement sûre du point de vue de la sécurité.

Pour couronner le tout, les partages ne permettent que de fixer les droits de lecture et d'écriture pour celui qui accède aux fichiers du partage. Les droits d'exécution n'ont pas de signification sous Windows puisque, contrairement aux fichiers Unix, le type des fichiers est déterminé par leur extension. Les notions de sécurité des partages sont donc profondément différentes de celles utilisées par Unix, surtout pour le contrôle d'accès au niveau ressource, puisqu'aucun nom d'utilisateur n'est requis lors de l'authentification ! Mais ce n'est pas tout. Les fichiers Unix appartiennent tous à un utilisateur et à un groupe d'utilisateurs, chose qui n'a pas de signification pour Windows. De plus, les systèmes de fichiers Unix font la distinction entre les majuscules et les minuscules dans les noms de fichiers, ce que ne fait pas Windows. Et ils disposent de la notion de liens physiques et symboliques. Autant de problèmes qui doivent être gérés par Samba.

Note : Le fait de ne pas disposer des informations concernant les droits des utilisateurs sur les fichiers accédés par SMB n'empêche pas le serveur de fichiers de contrôler les accès effectués par le client. Si par exemple, un fichier est marqué comme étant en lecture seule, aucun client ne peut y écrire, même par l'intermédiaire d'un partage accédé en lecture et écriture.

Pour résoudre tous ces problèmes, Samba dispose d'un grand nombre d'options, qui peuvent être utilisées dans le fichier de configuration /etc/samba/smb.conf. Ces options permettent d'indiquer la manière dont l'authentification doit être faite, les droits avec lesquels les fichiers sont accédés ou créés, les utilisateurs au nom desquels les fichiers sont créés, et le comportement à suivre lorsqu'un client essaie de suivre un lien symbolique. Seules les principales options gérées par Samba seront décrites ici. Les options avancées seront laissées de côté, car Samba propose un nombre incroyable de fonctionnalités et les traiter toutes dépasserait le cadre de ce document. Vous pourrez trouver des informations complémentaires en cas de nécessité dans la documentation de Samba, ou bien dans l'excellent livre « Using Samba » de Robert Eckstein, publié aux éditions O'Reilly. Une version en ligne de ce livre est fournie avec les sources de Samba et complète ainsi la documentation officielle de ce programme.

La plupart des distributions fournissent un fichier de configuration /etc/samba/smb.conf contenant la plupart des options par défaut, plus quelques exemples de configuration. Par exemple, les répertoires des utilisateurs sont souvent exportés par défaut. Vous pourrez bien entendu modifier ce fichier de configuration. Il est donc peut-être nécessaire de donner quelques précisions.

Le fichier smb.conf est structuré en sections permettant de fixer les paramètres de différentes fonctionnalités du logiciel. Chaque section est introduite par son nom, donné entre crochets. Certaines sections sont spécifiques à Samba et d'autres permettent de définir les partages que vous désirez créer. Les paramètres définis dans les sections se présentent sous la forme de couple « paramètre = valeur », où paramètre est le nom d'un des paramètres possibles dans cette section, et valeur est la valeur que ce paramètre peut prendre.

Parmi les sections propres à Samba, on compte la section « [global] ». Cette section est particulièrement importante, car elle fixe les paramètres globaux de Samba, ainsi que les valeurs par défaut des paramètres des autres sections. La section [global] suivante peut servir d'exemple :

[global]
# Définit le nom NetBIOS du serveur :
    netbios name = Linux
    server string = Linux fait la Samba (version %v)

# Définit le nom du groupe de travail :
    workgroup = monrezo

# Fixe les règles de gestion de la sécurité :
    security = user
    encrypt passwords = yes
    smb passwd file = /etc/samba/passwd

# Définit la correspondance entre les noms d'utilisateurs Windows
# et les noms Unix :
    username map = /etc/samba/usermap

# Définit le compte Unix à utiliser pour invité :
    guest ok = no
    guest account = nobody

# Définit les paramètres réseau :
    socket options = TCP_NODELAY
    interfaces = eth0
    bind interfaces only = yes

Cette section commence par définir le nom NetBIOS du serveur et sa description. Par défaut, le nom utilisé par Samba est le nom de domaine Unix de la machine, mais vous pouvez changer ce nom comme bon vous semble. Vous avez dû remarquer que dans la description de la machine (mot clé server string), la version de Samba est récupérée avec %v. En fait, Samba définit un certain nombre de variables qui sont remplacées dynamiquement lors de la connexion à un partage. Ainsi, %v représente la version de Samba utilisée, %u représente le nom de l'utilisateur qui se connecte, etc. Toutes ces variables sont décrites dans la page de man du fichier smb.conf.

Le nom du groupe de travail dont fait partie la machine est ensuite introduit avec le mot clé workgroup. Dans le cas présent, il s'agit du groupe de travail « monrezo ».

Viennent ensuite les options de sécurité. Le mot clé security permet de définir le mode de contrôle d'accès aux partages mis à disposition des clients par le serveur Samba. La valeur user indique que ce contrôle d'accès se fait au niveau utilisateur, ce qui est le plus cohérent sous Unix. Chaque utilisateur doit donc fournir son nom et son mot de passe pour accéder à ces partages. Samba peut également gérer le contrôle d'accès au niveau ressource, si l'on utilise la valeur share. Dans ce cas, Samba essaiera de retrouver l'utilisateur qui cherche à se connecter à partir de son mot de passe. Il faut donc ajouter dans ce cas une ligne telle que celle-ci dans la section globale ou dans l'une des sections définissant un partage :

    username = utilisateurs

où utilisateurs représente la liste des utilisateurs que Samba utilisera pour tester le mot de passe fourni. Bien entendu, si un nom d'utilisateur est fourni par le client pour accéder à cette ressource, ce nom est utilisé directement. Samba mémorisera également ce nom pour les demandes d'accès ultérieures à la ressource partagée. Cet algorithme n'est pas très sûr, car un utilisateur peut se connecter par hasard au nom d'un autre. Aussi n'est-il pas recommandé d'utiliser le contrôle d'accès au niveau ressources.

Jusqu'à Windows 95 et Windows NT4 Service Pack 2 compris, les mots de passe fournis par les clients étaient transférés en clair sur le réseau. Cela n'étant pas sûr, Microsoft a décidé d'adopter une nouvelle technique, dans laquelle les mots de passe à transférer sont chiffrés par une clef fournie par le serveur. Ainsi, une personne mal intentionnée écoutant les paquets transférés sur le réseau ne pourrait pas capter ces mots de passe. Samba est capable de gérer les deux cas de configuration, à l'aide de l'option encrypt password. Cependant, si vous décidez d'activer le chiffrement des mots de passe, vous devrez également créer un fichier de mots de passe pour les clients SMB. L'emplacement de ce fichier est indiqué avec l'option smb passwd file.

Le format du fichier de mot de passe de Samba ressemble fortement à celui du fichier de mot de passe Unix /etc/passwd. Vous pourrez trouver dans la documentation de Samba une description détaillée de ce fichier. Cependant, la chose la plus importante, c'est bien sûr de pouvoir ajouter des entrées pour chaque utilisateur dans ce fichier. Cette opération se fait avec l'utilitaire smbpasswd. Exécutée sous le compte root, la commande suivante permet d'ajouter un utilisateur et de définir son mot de passe :

smbpasswd -a utilisateur

où utilisateur est le nom de l'utilisateur dont on veut créer un nouveau mot de passe. L'utilisateur peut bien entendu changer son mot de passe avec smbpasswd.

Il est possible que les noms des utilisateurs Windows ne soient pas identiques à leurs logins sur la machine serveur de fichiers. En fait, il est même possible que plusieurs utilisateurs utilisent un même compte, créé uniquement pour les partages SMB. Samba fournit donc la possibilité d'utiliser un fichier de correspondance entre les noms des utilisateurs avec l'option username map. Le format du fichier de correspondance est très simple, puisqu'il est constitué de lignes définissant chacune une association entre un nom de login Unix et un nom d'utilisateur Windows. Ces lignes utilisent la syntaxe suivante :

login = utilisateur

où login est le nom de login de l'utilisateur sur la machine Unix, et utilisateur est le nom qu'il utilisera pour accéder aux partages.

L'option guest ok permet d'autoriser les connexions sans mot de passe sous un compte spécial, que l'on nomme le compte invité. Pour cela, il suffit de lui affecter la valeur yes. Cette option peut être fixée à no dans la section de configuration globale, et redéfinie dans les sections spécifiques de certains partages. Dans tous les cas, les connexions qui s'effectuent en tant qu'invité doivent utiliser un compte utilisateur Unix classique. Ce compte peut être défini à l'aide de l'option guest account, en général, l'utilisateur nobody utilisé par NFS est le plus approprié.

Enfin, il est possible de définir des paramètres réseau dans la section de configuration globale. Ces paramètres réseau permettent de fixer des options de sécurité complémentaires et des options d'optimisation. L'option interfaces donne la liste des interfaces à partir desquelles les demandes de connexion des clients seront acceptées. Ce type de contrôle est activé lorsque le paramètre bind interfaces only prend la valeur yes. Ces options conviennent parfaitement pour un réseau local de particulier. L'option socket options quant à elle permet de définir les paramètres de fonctionnement des communications TCP. L'option TCP_NODELAY indique au système d'envoyer les paquets TCP dès que Samba le demande, sans chercher à en regrouper plusieurs pour optimiser la taille des paquets. Cette option accélère significativement le fonctionnement des programmes tels que Samba, qui utilisent beaucoup de petits paquets pour envoyer des requêtes ou des réponses. Sans cette option, le système chercherait à regrouper ces paquets, même si Samba n'en a pas d'autres à envoyer, et ralentirait ainsi inutilement les transferts de données.

Chaque partage fourni par le serveur SMB dispose également d'une section, dont le nom est le nom utilisé pour ce partage. Ces sections sont beaucoup plus simples que la section global, comme le montre l'exemple suivant :

[Données]
# Donne le chemin sur le répertoire utilisé par ce partage :
    path = /usr/share/samba/données

# Description du partage :
    comment = Disque de données

# Nom de volume Windows :
    volume = SMB-LNX

# Options d'accès :
    writeable = yes
    guest ok = yes

Comme vous pouvez le constater, l'option path permet de définir le répertoire utilisé pour stocker les fichiers du partage. Ce répertoire est un répertoire du serveur, et le chemin doit donc obligatoirement être un chemin Unix valide. En particulier, il faut tenir compte ici de la casse des noms de fichiers. L'option comment donne la description du partage, telle qu'elle apparaîtrait dans le voisinage réseau de Windows. Le nom de volume quant à lui est celui qui sera donné si un client Windows attache une lettre de lecteur à ce partage. Il est spécifié à l'aide de l'option volume. Enfin, les options d'accès utilisées dans cet exemple permettent d'autoriser l'écriture dans les fichiers de ce partage, et d'autoriser les accès en tant qu'invité (c'est-à-dire sans mot de passe).

Samba dispose d'une fonctionnalité intéressante afin de définir automatiquement un partage pour chacun des répertoires personnels des utilisateurs déclarés dans le serveur. Lorsqu'un client cherche à accéder à un partage qui n'est pas défini par une section qui lui est propre, Samba tente de le localiser un répertoire personnel d'utilisateur portant ce nom. S'il le trouve, il utilisera ce répertoire pour effectuer le partage automatiquement. Les paramètres de ce partage automatique sont définis dans la section [homes], dont vous trouverez un exemple ci-dessous :

[homes]
    comment = Répertoires personnels
    browsable = no
    writable = yes

L'utilisation de l'option browsable = no ici sert simplement à indiquer qu'il ne doit pas apparaître de partage nommé homes. En effet, ce qui est désiré ici, c'est d'exposer les noms des répertoires personnels des utilisateurs, pas le partage homes lui-même. Les autres options sont les mêmes que pour les partages normaux.

La section [homes] peut poser quelques problèmes, puisqu'elle partage également le compte root. Cela n'est certainement pas le comportement désiré. Il est même fortement recommandé d'interdire les connexions pour les utilisateurs privilégiés du système. Cela peut être réalisé en utilisant l'option invalid users :

    invalid users = root bin daemon adm sync shutdown \
        halt mail news uucp operator gopher

En fait, il est conseillé de placer cette option dans la section [global], afin d'interdire les connexions de ces utilisateurs sur tous les partages.

Enfin, Samba fournit une fonctionnalité comparable à la section [homes] pour les imprimantes partagées. Il est en effet capable d'analyser le fichier de configuration /etc/printcap pour déterminer la liste des imprimantes installées, et les partager pour les clients Windows. Ces imprimantes apparaîtront donc comme des imprimantes partagées classiques. Pour cela, il suffit d'ajouter les lignes suivantes dans la section [global] du fichier smb.conf :

[global]
# Définit le type d'impression utilisé (bsd ou cups) :
    printing = bsd

# Lit la définition des imprimantes installées dans /etc/printcap
# (type de commande BSD uniquement) :
    printcap name = /etc/printcap
    load printers = yes

La première ligne indique à Samba le type de commande à utiliser pour réaliser une impression. Si vous utilisez le système d'impression BSD, vous devez fixer l'option printing à bsd. Si vous utilisez CUPS, la valeur à utiliser est cups.

Les options concernant toutes les imprimantes que Samba trouvera peuvent être précisées dans la section [printers]. Cette section joue donc le même rôle pour les imprimantes partagées que la section [homes] joue pour les répertoires personnels des utilisateurs. La section donnée ci-dessous pourra vous servir d'exemple :

[printers]
    comment = Imprimantes
    browseable = no
    printable = yes
    writeable = no
    guest ok = no
    path = /tmp
    create mode = 0700

L'option browseable a ici la même signification que dans la section [homes]. On ne désire en effet pas qu'un partage portant le nom printers apparaisse dans les voisinages réseau des machines Windows ! En revanche, l'option printable permet d'indiquer clairement que ces partages sont des imprimantes. Il est évident que l'on ne peut pas écrire sur une imprimante, l'option writeable est donc fixée à no. Enfin, les impressions ne sont autorisées que pour les utilisateurs identifiés, et l'utilisateur invité n'a pas le droit de soumettre un travail d'impression.

Le mécanisme utilisé par Samba pour imprimer un document est le suivant. Lorsqu'un client demande une impression sur une des imprimantes partagées, Samba copie le fichier que le client lui envoie en local. Ce fichier est ensuite communiqué au gestionnaire d'impression Unix, en l'occurrence lpr sous Linux. Celui-ci imprime le fichier et le supprime du disque. Dans la section [printers], l'option path permet d'indiquer dans quel répertoire les fichiers temporaires envoyés par les clients doivent être stockés. Il est tout à fait cohérent de les placer dans le répertoire /tmp comme dans l'exemple donné ci-dessus. Enfin, il est logique de protéger ces fichiers contre les autres utilisateurs. Cela est réalisé à l'aide de l'option create mode, qui fixe les droits de ces fichiers à 0 pour tout le monde, sauf pour le compte root, à leur création. Ainsi, seuls les programmes fonctionnant sous le compte root (donc Samba et la commande lpr) peuvent lire, écrire et effacer ces fichiers.

Il est bien entendu possible de définir les imprimantes manuellement, à raison d'une section par imprimante. Ce type de configuration ne sera toutefois pas décrit ici.

Toute modification du fichier de configuration de Samba implique de la signaler aux démons smbd et nmbd. Cela peut être réalisé en leur envoyant un signal SIGHUP. Vous devrez donc taper les commandes suivantes :

killall -HUP smbd
killall -HUP nmbd

Comme on peut le voir, le fichier de configuration smb.conf n'est pas très compliqué, mais utilise un grand nombre d'options. Heureusement Samba fournit l'outil de configuration « SWAT » (abréviation de l'anglais « Samba Web Administration Tool »), qui permet d'effectuer la configuration de Samba graphiquement. Comme son nom l'indique, SWAT joue le rôle de serveur Web, et peut être utilisé avec n'importe quel navigateur en se connectant sur le port 901 de la machine sur laquelle il tourne.

Pour que cela puisse fonctionner, il faut ajouter le service réseau « swat » dans votre fichier de configuration /etc/services :

swat    901/tcp

Vous devrez également ajouter une ligne dans votre fichier /etc/inetd.conf, afin que le démon inetd puisse lancer SWAT automatiquement lorsqu'un client cherche à l'utiliser sur le réseau. Vous devrez donc ajouter la ligne suivante :

swat  stream  tcp  nowait.400  root  /usr/local/samba/bin/swat swat

et signaler à inetd la modification de inetd.conf à l'aide de la commande :

killall -HUP inetd

Vous pourrez alors accéder à la configuration graphique de SWAT à l'aide d'un navigateur Web, en utilisant simplement l'URL suivante :

http://localhost:901

SWAT demandera bien entendu le nom de l'utilisateur root et son mot de passe pour permettre la modification du fichier smb.conf. Notez qu'il est fortement déconseillé de laisser la possibilité de réaliser une connexion Web sur le compte root, et que vous ne devriez pas autoriser les connexions non locales sur le port TCP 901. L'utilisation de SWAT ne pose pas vraiment de problèmes et ne sera donc pas décrite plus en détail ici.

L'utilisation des volumes partagés par l'intermédiaire du protocole SMB sous Linux est très simple. Elle se fait exactement comme pour NFS : il suffit simplement de monter le volume dans un répertoire vide de l'arborescence de votre système de fichiers.

Pour que cela puisse être réalisable, il faut bien entendu que le noyau supporte le système de fichiers SMB. Ce système de fichiers est considéré par le noyau exactement comme le système de fichiers NFS : il s'agit d'un système de fichiers réseau. Vous pourrez donc activer le support de ce système de fichiers à l'aide de l'option de configuration « SMB filesystem support (to mount WfW shares etc.) », que vous trouverez normalement dans le menu « Network File Systems » (ce menu est un sous-menu du menu « Filesystems » si vous utilisez le programme de configuration en mode texte). La compilation du noyau et son installation ont été décrites en détail dans la Section 7.3.

Lorsque vous aurez configuré et installé ce noyau, vous pourrez monter les volumes partagés par des serveurs de fichiers SMB (qu'il s'agisse de serveurs Linux ou Windows) exactement comme n'importe quel système de fichiers, et accéder à leurs ressources. Malheureusement, la commande mount du système ne supporte pas encore complètement le système de fichiers SMB. Elle utilise donc un programme complémentaire nommé smbmount, fourni avec la distribution de Samba. Notez bien que ce programme ne fait pas officiellement partie de Samba, il est seulement fourni en tant qu'utilitaire complémentaire pour Linux. Bien qu'il fasse également partie d'un paquetage indépendant, il est recommandé d'utiliser la version fournie avec Samba. Cela signifie que vous devrez installer Samba sur les postes clients, même si vous ne lancez pas les démons smbd et nmbd. La commande standard mount du système sera peut-être modifiée un jour pour intégrer toutes les fonctionnalités de la commande smbmount, ce qui rendra inutile l'installation de Samba sur les postes clients.

Quoi qu'il en soit, la syntaxe de la commande smbmount est très simple :

smbmount partage répertoire

où partage est le nom de partage du volume à monter, et répertoire est son point de montage (par exemple, /mnt/). Le nom de partage utilisé est exactement le même nom que celui utilisé par Windows, à ceci près que les antislashs ('\') sont remplacés par des slashs ('/'). Ainsi, pour monter dans /mnt/ le partage Données du serveur de fichiers SMBSERVER, vous devrez utiliser la commande suivante :

smbmount //smbserver/données /mnt

Remarquez que le protocole SMB ne fait pas la distinction entre les majuscules et les minuscules (tout comme Windows d'une manière générale), et que vous pouvez utiliser indifféremment les majuscules ou les minuscules.

L'utilisation des slashs à la place des antislashs dans le nom du partage est due au fait que l'antislash est un caractère spécial que shell interprète comme étant la poursuite de la commande courante sur la ligne suivante. Vous pouvez utiliser des antislashs si vous le désirez, mais dans ce cas, vous devrez mettre le nom de partage entre guillemets, pour empêcher le shell de les interpréter. Malheureusement, l'antislash est également un caractère d'échappement dans les chaînes de caractères, et est utilisé pour introduire des caractères spéciaux. Étant lui-même un caractère spécial, il doit lui aussi être précédé d'un antislash d'échappement ! Il faut donc doubler tous les antislashs, et la commande précédente devient particulièrement longue et peu pratique avec cette syntaxe :

smbmount "\\\\smbserver\\données" /mnt

Il est très facile de faire des erreurs avec de telles commandes, aussi je ne vous la conseille pas.

En fait, il est possible de faire en sorte que la commande mount classique du système puisse être utilisée pour réaliser les montages de partages SMB à partir de la version 2.0.6. ou plus de Samba. Pour cela, il suffit de créer dans le répertoire /sbin/ un lien symbolique mount.smbfs vers la commande smbmount. Lorsqu'on utilisera la commande mount avec le type de système de fichiers smbfs, celle-ci utilisera ce lien et appellera ainsi automatiquement smbmount. Les paramètres fournis à mount seront transmis tels quels à smbmount. En particulier, vous pourrez utiliser une commande de ce type :

mount -t smbfs partage répertoire

où partage et répertoire sont toujours les noms de partage et de répertoire devant servir de point de montage.

Une fois le partage monté, vous pouvez l'utiliser comme un système de fichiers classique. Lorsque vous aurez fini de l'utiliser, vous pourrez simplement le démonter, avec la commande smbumount :

smbumount /mnt

Il est également possible d'utiliser la commande système classique umount, mais cela nécessite de repasser sous le compte root, ou de fixer le bit setuid sur l'exécutable de umount, ce qui est un énorme trou de sécurité. La commande smbumount en revanche peut être setuid, car elle vérifie que l'utilisateur ne cherche à démonter que les partages qu'il a lui-même montés.

Les partages au niveau ressource ne prennent pas en compte la notion d'utilisateur et de groupe d'utilisateurs des systèmes de fichiers Unix classiques. Par conséquent, le propriétaire et le groupe des fichiers accédés par un partage de ressources sont fixés par défaut à l'utilisateur qui a effectué le montage et à son groupe. Cela est naturel et ne pose pas de problèmes pour la plupart des utilisateurs, mais peut être gênant lorsqu'on monte un partage en tant que root pour le compte d'un autre utilisateur. Pour résoudre ce problème, il est possible de préciser le nom de l'utilisateur et son groupe à l'aide des options uid et gid de la commande smbmount :

smbmount partage répertoire -o uid=utilisateur,gid=groupe

où utilisateur et groupe sont respectivement les noms ou les numéros de l'utilisateur et du groupe auquel les fichiers devront être attribués. Les paramètres uid et gid peuvent également être utilisés avec la commande mount. Dans ce cas, ils sont passés tels quels à smbmount.

Vous l'aurez sans doute remarqué, la commande smbmount vous demande de taper un mot de passe pour accéder au partage. Ce mot de passe est le mot de passe attendu par le serveur de fichiers SMB. Pour Windows, il s'agit du mot de passe attribué au partage. Pour les serveurs de fichiers Samba, il s'agit du mot de passe de l'utilisateur au nom duquel se fait le partage, ou du mot de passe SMB enregistré dans le fichier de mots de passe smbpasswd de Samba. Dans tous les cas, ce mot de passe est demandé, même s'il est vide. La commande smbmount peut accepter une option password, qui permet de préciser ce mot de passe. Cependant, il est fortement déconseillé de l'utiliser, et ce pour deux raisons. Premièrement, le mot de passe apparaît en clair lorsqu'il est saisi, et la ligne de commande peut être vue par n'importe quel utilisateur avec la commande ps. Cela pose donc un problème de sécurité évident. Deuxièmement, l'option password n'est pas reconnue par la commande mount, et ne peut donc être utilisée qu'avec smbmount. C'est pour cela qu'une autre solution a été proposée, bien qu'encore imparfaite : définir le nom d'utilisateur et le mot de passe dans la variable d'environnement USER. Pour cela, il suffit d'utiliser l'une des commandes suivantes :

export USER=utilisateur%secret
export USER=utilisateur/workgroup%secret

où utilisateur est le nom d'utilisateur classique, workgroup est le groupe de travail et secret le mot de passe sur le partage à monter. Cette technique n'est pas non plus très sûre, et n'est en aucun cas pratique.

Une autre solution, plus sûre, est de définir les paramètres d'identification et d'authentification de l'utilisateur dans un fichier et de fournir ce fichier en paramètre à la commande smbmount à l'aide de l'option credentials :

smbmount partage répertoire -o credentials=fichier

où fichier est le fichier contenant l'identification de l'utilisateur. Ce fichier utilise la syntaxe suivante :

username = utilisateur
password = secret

où utilisateur est le nom de l'utilisateur et secret son mot de passe. Cette technique est la technique recommandée pour réaliser le montage de partages SMB directement dans le fichier de configuration /etc/fstab, car c'est la seule qui permette de ne pas avoir à saisir le mot de passe ni d'avoir à le définir en clair dans une ligne de commande.