Version originale du 9 novembre 2000
Version française du 25 novembre
2001
L'écriture de ce document a débuté le 10
décembre 1999 par Derey Ney <derek@hipgraphics.com>
après trois jours de frustration avec le pontage et le
filtrage après avoir basculé d'un réseau PPP
à un lien DSL.
Les nouvelles versions peuvent êtres trouvées à www.tldp.org.
v0.04 (9 novembre 2000)
mise à jour pour le nouvel utilitaire de configuration de pont bridgex
v0.03 (24 mars 2000)
correction de l'URL pour BRCFG.tgz
v0.02 (13 décembre 1999)
intégration des corrections de Leonard Dickens (merci Leonard !)
v0.01 (10 décembre 1999)
version initiale
(c) 1999, 2000 Derek R. Ney
Ce document peut être distribué sous les conditions énoncées dans la licence LDP à http://www.tldp.org/COPYRIGHT.html.
Jusqu'il y a peu de temps, notre réseau était relié au réseau global via PPP par un modem. Avec cette configuration, j'avais installé un pare-feu utilisant IPChains et cela fonctionnait correctement. Nous avons récemment évolué vers une configuration DSL. Je pensais que ce serait une bagatelle de simplement basculer mon pare-feu de façon à ce qu'il m'isole du réseau entrant associé à la connexion DSL. J'avais tort. J'ai mis trois jours avant de parvenir à un résultat opérationnel. J'ai trouvé beaucoup d'informations douteuses sur le réseau qui m'ont procuré bien du désarroi. Ce mini-HOWTO a été écrit parce que je soupçonnais que notre installation serait plutôt banale dans le futur avec l'extansion de DSL et que je souhaitais aider les autres à s'épargner une importante frustration.
Je pense que ceci est applicable à une connexion modem-câble mais «c'est vous qui voyez» dans la mesure où je ne connais rien aux liaisons par modem-câble.
Le problème que je tente de résoudre est de de configurer le système de façon à ce que le code du pare-feu dans le noyau (qui est manipulé par ipchains) soit utilisable pour filtrer les paquets qui vont et viennent entre le monde extérieur et le réseau local. J'avais également besoin que certaines machines locales soient «vues» du réseau global (bien que filtrées au travers du pare-feu de manière permanente). Ceci éliminait le masquage IP (voir le IP Masquerade HOWTO) qui, autrement, serait probablement une solution plus aisée. Ce n'est pas si simple qu'il y paraît.
Pour arriver à notre but d'isoler un réseau local du réseau global (sur DSL) en utilisant notre linuxette, nous utiliserons deux cartes ethernet (NIC). Une de ces cartes est connectée au réseau local, l'autre au réseau global. La seule machine qui peut directement communiquer avec l'extérieur est la machine Linux. Toutes les autres machines de notre réseau local doivent passer par cette dernière (pare-feu).
La configuration logicielle consiste en résoudre deux problèmes:
router les paquets entre les réseaux local et global (pontage);
filtrer les paquets pour en stopper certains lorsqu'ils transitent par le pare-feu.
Le Bridging mini-Howto) donne des instructions détaillées en ce qui concerne le premier problème de routage des paquets entre les deux parties du réseau (local et global). Ceci fonctionne en positionnant les deux cartes ethernet sur le mode «promiscuous» de façon à ce qu'elles détectent les paquets sur chacune des interfaces et transfèrent ceux-ci quand ils appartiennent à l'autre côté. Ceci se fait de manière transparente: les autres ordinateurs sur le réseau ne voient même pas le pont, car celui-ci n'a même pas d'adresse IP. Mais cela ne résout pas totalement le problème. Je voulais que le pare-feu ait une adresse IP (du moins pour l'administrer à distance) et, plus ennuyeux, le code du pont dans le noyau interceptait et transférait les paquets AVANT qu'ils ne parviennent au code du pare-feu ce qui faisait que celui-ci n'avait aucun effet. Vous pouvez alternativement attribuer des adresses IP à vos cartes et continuer à les utiliser comme un pont. Bien que le Bridging mini-Howto ne le fait pas (en réalité, il utilise l'adresse de loopback), cela fonctionne bien. Cela résout un problème. En ce qui concerne le pare-feu, on se tourne vers une rustine sympa pour le noyau à http://ac2i.tzo.com/bridge_filter/ qui fait en sorte que les règles du pare-feu soient invoquées pour les paquets qui ont traversé le pont avec une nouvelle règle «bridgein».
Ce mini-HOWTO a pour but de vous aider à prendre en mains la situation où vous avez une machine Linux configurée comme une passerelle/pare-feu. Le système a deux cartes réseau. L'une des cartes est connectée au monde extérieur (dans notre cas, un modem DSL) et rien d'autre. L'autre carte est connectée à notre réseau local.
Notez que je n'ai eu d'expérience de ceci que sur mon i386 (ABIT BP6 MOBO, w/2 céléron) avec une RedHat 6.0, un noyau 2.2.13, un modem DSL connecté à un routeur et deux cartes Net Gear FA310TX. Votre cas peut être différent.
Notez également que la démarche proposée laissera votre réseau ouvert à des attaques éventuelles au démarrage (avant que le pare-feu ne soit activé). Si vous êtes très paranoïaque, vous devrez prendre des mesures pour éviter ceci.
J'ai trouvé pas mal d'informations sur internet que j'ai utilisée pour faire fonctionner les choses. Une partie de cette information était utile mais inappropriée.
Le Bridging mini-HOWTO a joué un rôle décisif pour la mise en uvre. Malheureusement sa seule utilisation ne permet pas de mettre en place un pare-feu.
Le Linux Bridge+Firewall mini-HOWTO) me paraissait, au premier abord, être pile ce dont j'avais besoin. Néanmoins, il s'avère que je pense qu'il est inapproprié. J'ai obtenu un fonctionnement relatif mais, en fin de compte, je me suis aperçu qu'il n'était pas nécessaire de scinder notre sous-réseau en deux comme il le préconise et je n'utiliserai pas cette méthode. Si vous tombez sur ce document, considérez-le avec des réserves.
La rustine Bridge Filter est la clé pour obtenir un bon fonctionnement de l'ensemble. Assez bizarrement, l'information sur la page web vous redirige vers le Bridge+Firewall mini-HOWTO. Vous n'avez pas besoin de mettre en uvre les indications du Bridge+Firewall mini-HOWTO pour obtenir que les choses fonctionnent. Vous aurez besoin de cette rustine.
Le IPCHAINS HOWTO est essentiel pour la mise en uvre du pare-feu en lui-même. Je ne traiterai pas de l'installation du pare-feu dans ce document; seules les choses qui diffèrent en raison de la mise en uvre du pontage seront abordées.
La démarche générale est la suivante:
installer le matériel (et vérifier son bon fonctionnement);
patcher et configurer le noyau;
configurer le réseau (ifconfig, route, bridging);
configurer le pare-feu.
Tout le long de la procédure, je considérerai une installation avec deux cartes ethernet (NIC), un lien extérieur DSL (où le modem DSL est connecté à une des deux cartes réseau) et un réseau local connecté à l'autre carte réseau. Arbitrairement, je désignerai la carte connectée au modem DSL par «eth1» et la carte sur le réseau local par «eth0». Le nommage des périphériques par le noyau dépend des connecteurs sur lesquels ils sont enfichés.
Je supposerai que l'on vous a assigné un sous-réseau d'adresses IP à 192.168.2.128-191, c'est à dire avec un masque de réseau de 255.255.255.192, et que le routeur fourni par le fournisseur DSL est à l'adresse 192.168.2.129. Ces valeurs sont des exemples arbitraires pour illustrer l'installation. J'utiliserai l'adresse 192.168.2.130 pour le pare-feu (les deux cartes), bien, qu'en fait, vous pouvez utiliser des adresses différentes pour chacune des deux cartes si vous le souhaitez.
Vous aurez besoin de deux cartes ethernet pour faire fonctionner les choses. Le plus grand problème que j'ai eu était que j'avais choisi un connecteur au hasard sur ma carte mère pour le seconde carte réseau et qu'il s'est avéré que ce slot (PCI) partageait une interruption avec celui de la première carte réseau. Je ne croyais pas que c'était un problème (en fait il y a peu d'informations sur ceci et je supposais que ça fonctionnerait correctement). Cela entraînait que les deux cartes réseau se désactivaient silencieusement (sans indiquer d'erreur) et arrêtaient d'émettre et de recevoir des paquets. Naturellement, quand vous procédez à toutes sortes de changements de configuration, c'est bien la dernière des choses dont vous avez besoin. Je ne sais pas si c'est un problème avec toutes les cartes réseau PCI ou seulement avec les nôtres mais j'aurais tendance à alerter sur les interruptions partagées. Le driver tulip, que nous utilisons, note l'IRQ de chaque carte dans le syslog au démarrage. Il y a une quantité d'informations ailleurs (reportez-vous au Ethernet-HOWTO à la section Utiliser plus d'une carte réseau par machine) à propos de la reconnaissance de deux cartes ethernet par le noyau en utilisant des options de démarrage; néanmoins, je n'ai pas besoin de ceci (mon noyau reconnaît les deux cartes sans argument).
Ensuite, vous devez connecter la deuxième carte réseau au modem DSL (ou quoi que ce soit d'autre qui vous relie au monde extérieur) et vous assurer que cela fonctionne. Vous devriez être en mesure «d'ifconfigurer» la seconde carte ethernet sur une adresse IP adhoc et pinguer le routeur de l'autre côté du lien. Ceci permet de vérifier que vous pouvez envoyer et recevoir des paquets au travers du lien DSL. Par exemple, pour le réseau pris en illustration vous faites:
ifconfig eth1 192.168.2.130 netmask 255.255.255.192 broadcast 192.168.2.191
pour configurer la carte. Et puis
ifconfig eth0 down # juste pour s'assurer que cela n'interfère pas avec autre chose ping 192.168.2.129
pour tester que vous pouvez bien atteindre le routeur. Pour bien faire, vous pourriez aussi vérifier que vous pouvez atteindre les machines sur votre réseau local par l'autre carte:
ifconfig eth1 down # juste pour s'assurer que cela n'interfère pas avec autre chose ifconfig eth0 up ping 192.168.2.x # où x est l'adresse d'un machine sur votre réseau local
À ce point, vous vous êtes assuré que l'ensemble du matériel fonctionne.
En fonction de la version de votre noyau, vous aurez besoin soit de l'ancien outil de configuration de pont (BRCFG) pour les noyaux antérieurs à la version 2.2.14, soit du nouvel outil de configuration (bridgex) pour les noyaux ultérieurs; ces utilitaires vous permettent de contrôler la fonction de pontage à l'intérieur du noyau quand CONFIGBRIDGE est activé. BRCFG est distribué sous forme de source avec des exécutables pré-compilés. Je ne sais pas sous quel noyau les exécutables ont été compilés mais j'ai obtenu des résultats différents après une recompilation avec les fichiers include de mon noyau (2.2.13). Malheureusement, pour ce faire, j'ai dû les patcher légèrement. Voici les rustines:
diff -C 3 -r /tmp/BRCFG/brcfg.c ./brcfg.c *** /tmp/BRCFG/brcfg.c Wed Feb 21 19:11:59 1996 --- ./brcfg.c Wed Dec 8 12:52:23 1999 *************** *** 1,6 **** ! #include <sys/types.h> ! #include <sys/socket.h> #include <skbuff.h> #include "br.h" --- 1,6 ---- ! #include <types.h> ! #include <socket.h> #include <skbuff.h> #include "br.h"
Appliquez la rustine, recompilez brcfg et installez-le dans un endroit convenable (j'ai choisi /usr/bin).
Pour les noyaux ultérieurs à la version 2.2.13, vous devez définitivement utiliser l'utilitaire bridgex. Je ne sais pas s'il fonctionne ou non avec des noyaux plus anciens. Remarquez que l'URL pour cet utilitaire peut être trouvée dans l'aide de la configuration du noyau /usr/src/linux/Documentation/Configure.help ainsi, si l'URL mentionnée ici est erronée, jetez un coup d'il dans le fichier d'aide (c'est l'aide pour l'item CONFIGBRIDGE. L'archive bridgex contient un exécutable déjà compilé mais vous devrez probablement le reconstruire en utilisant le Makefile également présent. Remarquez que l'utilitaire bridgex prend des arguments légèrement différents de ceux que prend le paquet BRCFG (qui seront détaillés plus tard quand je traiterai de la configuration du pont).
Vous devrez patcher et configurer votre noyau pour le pontage et le pont filtrant (de la même manière que pour le pare-feu, le réseau, etc. si vous n'avez pas déjà ces fonctionnalités). Les items de configuration suivants seront nécessaires (au minimum)