9.5. Configuration des fonctions serveur

En général, les gens ne voient Internet que du point de vue client en terme d'architecture client / serveur. Cela signifie qu'ils se contentent de se connecter à Internet, et n'utilisent que des logiciels clients qui communiquent avec des serveurs situés sur Internet. Ce mode d'utilisation est de loin le plus courant et celui qui convient à la majorité des gens, qui n'ont en général même pas conscience de l'existence du monde des serveurs.

Cependant, il est parfois nécessaire de mettre en place des petits serveurs, sans forcément être un fournisseur d'accès à Internet ou un hébergeur de site Web. Par exemple, il peut être intéressant de fournir la possibilité de réaliser une connexion par téléphone à un ordinateur distant que l'on doit laisser allumé pour une raison ou une autre, afin de réaliser une opération de maintenance. Il est également possible de faire une liaison PPP entre deux ordinateurs par un câble série pour échanger des données, ou pour relier par l'intermédiaire du réseau téléphonique deux réseaux séparés physiquement.

Cette section présente donc les techniques de base permettant de paramétrer Linux pour accepter les communications entrantes, tant pour satisfaire aux demandes de connexion distantes que pour établir une liaison PPP.

9.5.1. Paramétrage des connexions extérieures

Nous avons vu dans la Section 6.6 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 :

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ée 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

9.5.2. Configuration des liaisons PPP

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écessaire, 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 elle 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 permettent 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 :

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

locale:distante
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 toutes manières, 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 :

CommandeSignification
ATS0=n

Décrochage automatique si n vaut 1, manuel si n vaut 0.

AT&C1

Activation du contrôle de la ligne CD (« Carrier Detect ») pour signaler les raccrochages des clients. Cette commande n'est utile que si l'option modem est passée en paramètre à pppd sur sa ligne de commande.

AT&K3

Activation du contrôle de flux matériel (pour optimiser les échanges de données entre le modem et l'ordinateur). Cette option nécessite d'utiliser l'option crtscts dans la ligne de commande de pppd.

Au final, la ligne de commande à utiliser est donc la suivante :

pppd port vitesse detach modem crtscts init "/usr/sbin/chat -v \
        -f /etc/ppp/script" &
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 :

ParamètreSignification
$1

Nom de l'interface réseau (par exemple, « ppp0 ».

$2

Nom du fichier spécial de périphérique de la ligne série utilisée (par exemple, « ttyS0 »).

$3

Vitesse de la ligne série.

$4

Adresse IP locale de l'interface réseau.

$5

Adresse IP du client.

$6

Paramètre complémentaire, que l'on peut passer au script à l'aide de l'option ipparam de pppd.

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

9.5.3. Liaison de deux ordinateurs par un câble série

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 :

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...

9.5.4. Installation d'un proxy

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.

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
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éga-octets, 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 :

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 :

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
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 port 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ée et que sa lecture est relativement facile. Je ne saurais que trop vous recommander de le consulter si vous désirez en savoir plus.

9.5.5. Configuration d'un serveur DHCP

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 [...]]
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.