Genevi�ve Gracian - Traduction fran�aise
Xavier Venient - Relecture de la version fran�aise
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 CONFIG_BRIDGE 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 CONFIG_BRIDGE. 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)�:
CONFIG_EXPERIMENTAL=y CONFIG_BRIDGE=y CONFIG_FIREWALL=y CONFIG_IP_FIREWALL=y |
Vous devriez mettre la main sur la rustine ��Bridge Filter�� et l'appliquer � votre noyau. Recompilez, installez votre noyau puis red�marrez.
� ce niveau, vous devriez avoir vos deux cartes r�seau en �tat de fonctionner, un noyau nouvellement reconfigur� et brcfg install�. Maintenant, vous devez construire un script de d�marrage pour assembler le tout. J'ai fait cela en utilisant les scripts ��fa�on RedHat�� (/etc/rc.d). J'ai d�clar� les adresses et masques r�seau sp�cifiques dans /etc/sysconfig/network�:
GATEWAY=192.168.2.129 # adresse du routeur DSL
GATEWAYDEV=eth1 # carte r�seau � laquelle le routeur est reli�
ETH0_ADDR=192.168.2.130 # adresse IP de la carte sur le r�seau local
ETH0_MASK=255.255.255.192 # masque du r�seau local
ETH0_BROAD=192.168.2.191 # adresse de diffusion du r�seau local
ETH1_ADDR=192.168.2.130 # adresse IP de la carte c�t� DSL ; peut �tre
# diff�rente de ETH0_ADDR si vous voulez
ETH1_MASK=$ETH0_MASK # masque r�seau c�t� DSL, devrait �tre le m�me
# que sur eth0
ETH1_BROAD=$ETH1_BROAD # idem pour l'adresse de diffusion
|
Ensuite, j'ai cr�� un script dans /etc/rc.d/init.d/bridge pour installer le pont. J'inclus deux scripts ici. Le premier est utilis� par le vieil outil BRCF l'autre pour le plus r�cent bridgex. D'abord, celui pour BRCFG�:
#!/bin/sh
#
# bridge Ce script installe le pontage pour DSL avec BRCFG
#
# description: utilise brcfg pour activer le pontage et configure les cartes
# ethernet
# nom du processus: bridge
# config:
# localisation de la biblioth�que de fonctions
. /etc/rc.d/init.d/functions
# localisation de la configuration du r�seau
. /etc/sysconfig/network
# voyons comment nous sommes appel�
case "$1" in
start)
echo -n "configuration du pont: "
ifconfig eth0 $ETH0_ADDR netmask $ETH0_MASK broadcast $ETH0_BROAD
ifconfig eth1 $ETH1_ADDR netmask $ETH1_MASK broadcast $ETH1_BROAD
route add $GATEWAY dev $GATEWAYDEV
route add default gw $GATEWAY dev $GATEWAYDEV
ifconfig eth0 promisc
ifconfig eth1 promisc
brcfg -enable
echo
;;
stop)
# arr�t des d�mons
brcfg -disable
ifconfig eth0 down
ifconfig eth1 down
;;
restart)
$0 stop
$0 start
;;
status)
ifconfig eth0
ifconfig eth1
brcfg
;;
*)
echo "utilisation: bridge {start|stop|restart|status}"
exit 1
esac
exit 0
|
Le script qui suit est � utiliser avec l'utilitaire de configuration de pont bridgex. Notez que bridgex est bien plus configurable que le moins jeune BRCFG et que vous devriez jeter un coup d'œil � la page de manuel incluse dans l'archive de bridgex et adapter ce script�:
#!/bin/sh
#
# bridge Ce script installe le pontage pour DSL avec bridgex
#
# description: utilise bridgex pour d�marrer le pontage et configurer les
# cartes ethernet
# nom du processus: bridge
# configuration:
# localisation de la biblioth�que de fonctions
. /etc/rc.d/init.d/functions
# localisation de la configuration du r�seau
. /etc/sysconfig/network
# voyons comment nous sommes appel�
case "$1" in
start)
echo -n "configuration du pont: "
ifconfig eth0 $ETH0_ADDR netmask $ETH0_MASK broadcast $ETH0_BROAD
ifconfig eth1 $ETH1_ADDR netmask $ETH1_MASK broadcast $ETH1_BROAD
route add default gw $GATEWAY dev $GATEWAYDEV
ifconfig eth0 promisc
ifconfig eth1 promisc
brcfg start
brcfg device eth0 enable
brcfg device eth1 enable
echo
;;
stop)
# arr�t des d�mons
brcfg stop
ifconfig eth0 down
ifconfig eth1 down
;;
restart)
$0 stop
$0 start
;;
status)
ifconfig eth0
ifconfig eth1
brcfg
;;
*)
echo "utilisation: bridge {start|stop|restart|status}"
exit 1
esac
exit 0
|
Le script est ex�cut� lors du d�marrage. Il attribue les adresses � chacune des cartes r�seau, ajoute une route par d�faut qui pointe vers le routeur DSL, ajoute une route sp�cifique vers le routeur DSL, positionne chaque carte en mode ��promiscuous�� et puis active le pontage. J'ai cr�� des liens vers ce script dans les r�pertoires suivants dans /etc/rc.d�:
/etc/rc.d/rc0.d/K90bridge /etc/rc.d/rc1.d/K90bridge /etc/rc.d/rc2.d/S11bridge /etc/rc.d/rc3.d/S11bridge /etc/rc.d/rc4.d/S11bridge /etc/rc.d/rc5.d/S11bridge /etc/rc.d/rc6.d/K90bridge |
Ceci fait en sorte qu'il s'ex�cute apr�s le script de d�marrage du r�seau. Vous devez d�sactiver les autres configurations de eth0 (ou eth1) telles que celles qui sont faites dans le script /etc/rc.d/init.d/network (en supprimant les fichiers ifcfg-eth? de /etc/sysconfig/network-scripts/ dans la RedHat).
Pour tester les choses, je sugg�re de red�marrer en mode mono-utilisateur (en sp�cifiant ��single�� comme argument du noyau, par exemple, dans lilo ��lilo: linux single��) et en ex�cutant les scripts de d�marrage de /etc/rc.d/rc3.d un par un jusqu'� ce que vous arriviez au d�marrage du pont. D�marrez le pont et alors v�rifiez si vous pouvez atteindre des machines (vous utiliserez certainement ��ping -n�� pour ceci, afin de maintenir le serveur de noms hors jeu)�:
pinguez le routeur DSL�;
pinguez une machine locale�;
pinguez une machine sur le r�seau global.
Si vous pouvez pinguer toutes ces localisations, il y a de fortes chances que tout se passe bien. Remarquez que le pont met un petit moment � d�marrer. Vous pouvez contr�ler son �tat en utilisant la commande brcfg sans option.
Vous aurez besoin d'installer un pare-feu (en supposant que vous en voulez un) pour vous prot�ger des acc�s non autoris�s. La rustine ��Bridge Filter�� vous permet d'utiliser une nouvelle r�gle int�gr�e ��bridgein�� avec ipchains. Cette r�gle est utilis�e � chaque fois qu'un paquet doit �tre redirig� de eth0 vers eth1 ou inversement. La r�gle bridgein n'est pas utilis�e quand le paquet est destin� au pare-feu lui m�me�; vous devez utiliser la r�gle input pour cela. Je ne tenterai pas de rentrer en d�tail dans l'installation du pare-feu. R�f�rez-vous au IPCHAINS HOWTO pour ceci.
Pour chacune des machines de votre r�seau local, vous devez simplement lui indiquer une adresse IP, un masque de r�seau et utiliser le routeur DSL comme une passerelle (route par d�faut) le pont filtrant transf�rera les paquets vers et depuis le routeur DSL.
La rustine qui ajoute la r�gle int�gr�e bridgein � ipchains fait que la commande de suppression de toutes les cha�nes, ipchains -X, produit l'erreur suivante�:
ipchains: Device or resource busy |
d'autant que je sache, ceci n'est pas grave. Je soup�onne que ipchains ne comprend pas que la nouvelle r�gle d'entr�e de pont est pr�d�finie.
Comme je l'ai mentionn� dans la section Section 3.2, au moins pour les cartes PCI, vous ne devez pas partager d'interruptions entre deux cartes (et probablement aussi avec aucun autre p�riph�rique).
La traduction fran�aise de ce document a �t� r�alis�e par
Genevi�ve Gracian <ggracian@free.fr>.