<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [
<!ENTITY howto "http://www.traduc.org/docs/HOWTO/lecture/">
<!ENTITY mini-howto "http://www.traduc.org/docs/HOWTO/mini/lecture/">
]>
<!-- Created: 2002-06-08, 10:59:43 Nils.Radtke_@_Think-Future.de -->
<!-- Last modified: 2002-10-08, 13:36:23 -> nr -->
<article lang="fr">
<articleinfo>
<title>Associer un pont Ethernet et netfilter</title>
<subtitle>Version française du <foreignphrase>Ethernet Bridge +
netfilter Howto</foreignphrase></subtitle>
<author>
<firstname>Nils</firstname>
<surname>Radtke</surname>
<affiliation>
<address><email>Nils.Radtke_@_Think-Future.de</email></address>
</affiliation>
</author>
<othercredit role="traduction">
<firstname>François</firstname>
<surname>Romieu</surname>
<affiliation>
<jobtitle>Traduction française</jobtitle>
<address><email>francois@ueimor.eu.org</email></address>
</affiliation>
<contrib>Traduction française</contrib>
</othercredit>
<othercredit role="relecture">
<firstname>Guillaume</firstname>
<surname>Lelarge</surname>
<affiliation>
<jobtitle>Relecture de la version française</jobtitle>
<address><email>gleu@wanadoo.fr</email></address>
</affiliation>
<contrib>Relecture de la version française</contrib>
</othercredit>
<releaseinfo>0.2.fr.1.0</releaseinfo>
<pubdate>2003-03-09</pubdate>
<revhistory>
<revision>
<revnumber>0.2.fr.1.0</revnumber>
<date>2003-03-09</date>
<authorinitials>FR</authorinitials>
<revremark>Première traduction française</revremark>
</revision>
<revision>
<revnumber>0.2</revnumber>
<date>2002-10-08</date>
<authorinitials>NR</authorinitials>
<revremark>
Ajout de la partie <link
linkend="TestingActualConfiguration">d'exemple de
configuration</link> et d'indications dans <link
linkend="BridgeRouting">la configuration du routage</link> et
<link linkend="TestingRouting">le test du routage</link>
respectivement.
</revremark>
</revision>
<revision>
<revnumber>0.1</revnumber>
<date>2002-09-19</date>
<authorinitials>NR</authorinitials>
<revremark>
Mise à jour du lien vers ebtables dans la section des
« Thèmes voisins ». Ajout d'une remarque
ayant trait aux <link linkend="HintFalsePositive">messages de
déverminage des faux positifs de br_nf</link>
</revremark>
</revision>
</revhistory>
<abstract>
<para>
La mise en place d'un pont Ethernet permet d'ajouter une entité d'audit
ou de régulation à un réseau de façon transparente. Une telle installation
n'impose aucun changement à la topologie du réseau d'accueil.
Elle s'effectue en connectant le pont Ethernet entre le réseau à analyser
et l'élément responsable du routage (l'équipement connecté à l'Internet).
</para>
</abstract>
</articleinfo>
<sect1>
<title>Introduction</title>
<para>
La version originale de ce guide pratique est disponible dans d'<ulink
url="http://www.think-future.de/DOCUMENTATION/Ethernet-Bridge-netfilter-HOWTO/other_formats/">autres
formats</ulink>.
Pour le téléchargement, nous vous recommandons cette <ulink
url="http://www.think-future.de/DOCUMENTATION/Ethernet-Bridge-netfilter-HOWTO/Ethernet-Bridge-netfilter-HOWTO.tar.gz">archive
tar</ulink>.
La version originale de ce document est publié par le <ulink
url="http://www.tldp.org/docs.html#howto">Projet de documentation
Linux</ulink> (LDP).
</para>
<para>
La dernière <ulink
url="&howto;Ethernet-Bridge-netfilter-HOWTO.html">version
française</ulink> de ce document est disponible sur le site du projet
de traduction <ulink url="http://www.traduc.org">traduc.org</ulink>.
</para>
<para>
Pour ceux qui sont à la recherche d'une traduction, il existe aussi
une version <ulink
url="http://www.think-future.de/DOCUMENTATION/Ethernet-Bridge-netfilter-HOWTO_de/">version
allemande</ulink> !
</para>
</sect1>
<!-- #################### -->
<!-- ### introduction ### -->
<sect1>
<title>Introduction</title>
<para>
Les ponts Ethernet joignent de façon transparente plusieurs segments
Ethernet.
</para>
<para>
Un pont Ethernet distribue les trames qui se présentent à un port aux
autres ports. Il l'effectue de façon intelligente : une fois qu'il
sait grâce à partir de quel port joindre une interface d'adresse MAC donnée,
la trame ne sera émise que sur le port correspondant sans polluer les autres
segments.
</para>
<para>
Des interfaces Ethernet peuvent s'ajouter à une interface existante et
devenir des ports (logiques) de l'interface du pont.
</para>
<para>
L'emploi d'un dispositif de type netfilter au dessus d'un pont rend
le système capable d'effectuer du filtrage. On obtient ainsi un filtrage
transparent. Aucune adresse IP n'est même nécessaire. Il est bien sûr
possible d'en affecter une à l'interface de pontage à des fins de
maintenance (via ssh :o) ).
</para>
<para>
L'intérêt du dispositif est évident. La transparence épargne à
l'administrateur la charge de reprise de la topologie réseau.
Les utilisateurs ne remarquent pas l'existence du pont mais les
connexions sont bloquées. Enfin, la transition ne perturbe pas le
fonctionnement opérationnel (qu'on se figure un réseau où la perte de
connectivité réseau coûte cher !).
</para>
<para>
L'autre cas courant concerne les personnes connectées à l'Internet
au moyen d'un routeur dédié. Les fournisseurs d'accès ne partagent
guère les privilèges d'administration sur les équipements loués et
le client ne peut donc pas modifier la configuration. Le client a
cependant un réseau dont il ne veut pas reprendre toute la
configuration. Il n'est effectivement pas obligé de le faire s'il
a recours à un pont.
</para>
</sect1>
<!--
Bridging: Legt die Ethernet frames eines Segmentes auf das Interface
eines anderen Segmentes. FW auf der Ethernet Bridge ermoeglicht die
Verbindungskontrolle.
Eine Ethernet Bridge ist fuer die verbundenen Netzwerke nicht sichtbar.
Sie kann 2 oder mehr Ethernet Segmente verbinden, ohne Eingriff in die
bestehende Netzwerk-Topologie. Ein weiterer Vorteil eroeffnet sich, wenn
der Router nach extern nicht der eigenen Administration angehoert und
somit eine Modifikation der Netzwerk-Topologie ausgeschlossen ist.
-->
<!-- ### introduction ### -->
<!-- #################### -->
<!-- ############ -->
<!-- ### make ### -->
<sect1>
<title>Logiciels requis</title>
<para>
La configuration logicielle suivante est nécessaire sur l'hôte de
pontage conformément à notre
<link linkend="TestingTestingGrounds">terrain de test</link>.
</para>
<sect2>
<title>Noyau Linux</title>
<para>
La prise en charge du pontage Ethernet est disponible en standard
à partir du noyau <emphasis>2.4.18</emphasis>. Aucun ajout n'est requis.
</para>
<para>
Pour disposer de netfilter et pouvoir se servir d'iptables, il
faut toutefois appliquer un supplément de code. Le nécessaire se
trouve dans la <link linkend="LinkBridgeHome">page</link>
sourceforge du pontage Ethernet.
</para>
<informalexample><screen>
root@bridge:~> cd /usr/src/
root@bridge:~> wget -c http://bridge.sourceforge.net/devel/bridge-nf/bridge-nf-0.0.7-against-2.4.18.diff
root@bridge:~> cd /usr/src/linux/
root@bridge:~> patch -p1 -i ../bridge-nf/bridge-nf-0.0.7-against-2.4.18.diff
</screen></informalexample>
<para>
Une fois le noyau standard rectifié, on active les options de
configuration adéquates du noyau. On peut se reporter au document
suivant pour la mise au point d'un noyau personnel :
<ulink
url="http://www.think-future.de/DOCUMENTATION/CD-Net-Install-HOWTO/CD-Net-Install-HOWTO-4.html#Kernel_Configuration">CD-Net-Install-HOWTO, boîte à outils</ulink>.
Oui, c'est encore en allemand. Je corrigerai ça à l'occasion.
Pour l'instant, dans :
</para>
<informalexample><screen>
Code maturity level options
</screen></informalexample>
<para>
on active :
</para>
<informalexample><screen>
[*] Prompt for development and/or incomplete code/drivers
</screen></informalexample>
<para>
et dans :
</para>
<informalexample><screen>
Loadable module support
</screen></informalexample>
<informalexample><screen>
[*] Enable loadable module support
[*] Set version information on all module symbols
[*] Kernel module loader
</screen></informalexample>
<para>
Jusqu'ici, tout va bien. À présent, dans :
</para>
<informalexample><screen>
Networking options
</screen></informalexample>
<para>
on active :
</para>
<informalexample><screen>
[*] Network packet filtering (replaces ipchains)
[*] Network packet filtering debugging
</screen></informalexample>
<para>
De même, dans :
</para>
<informalexample><screen>
IP: Netfilter Configuration --->
</screen></informalexample>
<para>
on choisit tout ce qui est souhaité . Enfin, on active :
</para>
<informalexample><screen>
[M] 802.1d Ethernet Bridging
</screen></informalexample>
<para>
et
<footnote>
<para>
Remarque :
Cette entrée n'est disponible qu'avec un noyau modifié !
</para>
</footnote>
:
</para>
<informalexample><screen>
[*] netfilter (firewalling) support
</screen></informalexample>
<para>
Il ne reste plus qu'à exécuter un cycle :
</para>
<informalexample><screen>
root@bridge:~> make dep clean bzImage modules modules_install
</screen></informalexample>
<para>
C'est tout. On n'oubliera pas d'éditer le fichier
<filename>/etc/lilo.conf</filename> en conséquence avant de taper:
</para>
<informalexample><screen>
root@bridge:~> lilo -t
root@bridge:~> lilo
root@bridge:~> reboot
</screen></informalexample>
<para>
<note>
<para>
Pourquoi ne pas identifier le noyau comme destiné au pontage ?
On édite le Makefile de plus haut niveau dans les sources
du noyau et on modifie la ligne qui comprend
<emphasis>EXTRAVERSION =</emphasis>. On peut la positionner à
<emphasis>bridge</emphasis>
par exemple.
Une fois l'étape <emphasis>modules_install</emphasis> effectuée, les
modules se trouveront dans le répertoire
<filename>/lib/modules/2.4.18bridge</filename>.
</para>
</note>
</para>
</sect2>
<sect2>
<title>L'utilitaire <application>brctl</application></title>
<para>
Une fois le noyau capable de jouer les ponts Ethernet et de supporter
netfilter, on prépare l'utilitaire <application>brctl</application>.
<application>brctl</application> est l'outil de
<link linkend="SetupLinuxBrctl">configuration</link> pour le pontage.
On <link linkend="LinkBridgeHome">télécharge les sources</link> du
paquetage puis on le décompresse et on se positionne dans le répertoire
créé.
</para>
<informalexample><screen>
root@bridge:~> wget -c http://bridge.sourceforge.net/bridge-utils/bridge-utils-0.9.5.tar.gz
root@bridge:~> tar xvzf bridge-utils-0.9.5.tar.gz
root@bridge:~> cd bridge-utils-0.9.5
</screen></informalexample>
<para>
Il est temps de lire le fichier <filename>README</filename> ainsi
que ceux qui se trouvent dans le répertoire <filename>doc/</filename>.
On peut alors lancer une commande make. L'exécutable
<application>brctl/brctl</application> qui en résulte est à copier dans
le répertoire <filename>/sbin/</filename>.
</para>
<informalexample><screen>
root@bridge:~> make
root@bridge:~> cp -vi brctl/brctl /sbin/
</screen></informalexample>
<para>
On peut à présent passer à la section d'<link
linkend="SetupLinuxBrctl">installation</link>.
</para>
</sect2>
</sect1>
<!-- ### make ### -->
<!-- ############ -->
<!-- ############# -->
<!-- ### Setup ### -->
<sect1>
<title>Mise en service de Linux</title>
<sect2 id="SetupLinuxBrctl">
<title>Mise en service du pont</title>
<para>
Linux doit être mis au courant de l'existence du pont. On commence
donc par réclamer une interface de pontage Ethernet virtuelle
(à exécuter sur la machine <emphasis>bridge</emphasis>, voir la
<link linkend="TestingTestingGrounds">configuration de test</link>) :
</para>
<informalexample><screen>
root@bridge:~> brctl addbr br0
</screen></informalexample>
<para>
Le protocole d'établissement d'arbre (Spanning Tree) n'est pas
nécessaire. On suppose qu'il n'y a qu'un seul routeur. Une boucle
est donc peu probable. La fonctionnalité correspondante peut donc
être désactivée. Le bavardage réseau diminue alors.
</para>
<informalexample><screen>
root@bridge:~> brctl stp br0 off
</screen></informalexample>
<para>
Après cette phase préparatoire, on lance enfin quelques
commandes intéressantes. On ajoute les interfaces Ethernet
physiques en les attachant à l'interface de pontage virtuelle
<emphasis>br0</emphasis>
qui vient d'être créée :
</para>
<informalexample><screen>
root@bridge:~> brctl addif br0 eth0
root@bridge:~> brctl addif br0 eth1
</screen></informalexample>
<para>
À présent les interfaces Ethernet sont chacune devenues une extrémité
du pont. Certes, elles étaient et elles sont toujours là (on peut les
voir :o) ) mais comme elles appartiennent au pont, elles n'ont plus
besoin de leur adresse IP. On leur retire donc celle-ci :
</para>
<informalexample><screen>
root@bridge:~> ifconfig eth0 down
root@bridge:~> ifconfig eth1 down
root@bridge:~> ifconfig eth0 0.0.0.0 up
root@bridge:~> ifconfig eth1 0.0.0.0 up
</screen></informalexample>
<para>
Parfait, on dispose donc à présent d'une station sans adresse IP.
Si ce n'était pas déjà le cas, il est temps de passer sur une console
locale à la machine pour la configurer. Une console série est la
bienvenue.
<note>
<para>
Option :
On affecte une adresse IP à l'interface logique et on l'active :
</para>
<informalexample><screen>
root@bridge:~> ifconfig br0 10.0.3.129 up
</screen></informalexample>
</note>
C'est tout.
Il est conseillé de s'attarder sur une
<link linkend="TestingImportantNote">remarque importante</link> !
</para>
</sect2>
<sect2 id="BridgeRouting">
<title>Configuration du routage</title>
<para>
Dans le cas de la configuration d'un passerelle, on active la
transmission de paquets du noyau Linux :
</para>
<informalexample><screen>
root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward
</screen></informalexample>
<para>
La machine dispose déjà d'une adresse IP mais n'a aucune route par
défaut. On corrige ce manque :
</para>
<informalexample><screen>
root@bridge:~> route add default gw 10.0.3.129
</screen></informalexample>
<para>
La connectivité réseau devrait être normale, depuis, vers et au
travers de la passerelle.
</para>
</sect2>
</sect1>
<!-- ### Setup ### -->
<!-- ############# -->
<!-- ############### -->
<!-- ### Testing ### -->
<sect1 id="TestingTestingGrounds">
<title>Test du pontage Ethernet</title>
<sect2>
<title>Configuration de test</title>
<para>
On part de la situation suivante ou d'un schéma analogue :
</para>
<informalexample><screen>
/\
Ethernet Ethernet ATM / -/\
+---------+ +---------+ +---------+ /-/ !
| Station |-------| Pont |----------| Routeur |-----| Inter- \
+---------+ +---------+ +---------+ \ net ---|
^ ^ ^ ^ \ /
| | | | \---/
eth0 eth0 eth1 if0 ^
| | | | |
10.0.3.2 rien/10.0.3.1 195.137.15.7 le reste du monde
\ /
\ /
^ \-br0-/
| ^ ^
| ^ | |
| | | |
perso perso étranger agressif
</screen></informalexample>
<para>
Les possibilités d'administration sont limitées aux équipements
marqués <emphasis>perso</emphasis>. Le routeur, et l'Internet,
sont inaccessibles.
</para>
<para>
Si on veut contrôler le trafic sur le brin Ethernet, on ne peut
qu'ajouter un pare-feu ou intégrer un pont.
</para>
<para>
La méthode habituelle a pour revers le changement de route par
défaut sur chaque machine du réseau interne. C'est extrêmement
pénible et personne n'a envie de devoir changer 5 routes par défaut
sur 5 hôtes plus d'une fois. En outre, ça consomme du temps, on peut
se tromper et la sécurité n'est pas améliorée.
</para>
<para>
La seconde approche est plus systématique, consomme moins de temps et
réduit les risques d'erreur. Elle est plus sûre en ce sens qu'il n'est
pas nécessaire de faire apparaître une adresse IP supplémentaire.
Pas d'IP, pas de danger. Enfin, il s'agit de la théorie en supposant
que les piles sont sûres (ce qui a intérêt à être vérifié). L'emploi
d'un pont est transparent, pas de changements d'IP ou d'adresses MAC,
c'est là son attrait.
</para>
<para>
Chacun choisira sa méthode mais seule la plus amusante est examinée ici.
</para>
</sect2>
<sect2 id="TestingRouting">
<title>Ping le, Max !</title>
<para>
On configure l'interface eth0 comme d'habitude. Les interfaces du pont
sont configurées conformément à la
<link linkend="SetupLinuxBrctl">section d'installation</link>.
</para>
<para>
La commande ci-dessous est importante pour activer la transmission de
paquets.
</para>
<informalexample><screen>
root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward
</screen></informalexample>
<para>
On configure éventuellement une route par défaut :
</para>
<informalexample><screen>
root@bridge:~> route add default gw 10.0.3.129
</screen></informalexample>
<para>
On met en place les règles de filtrage sur
<emphasis>bridge</emphasis> :
</para>
<informalexample id="TestingIptablesListing"><screen>
root@bridge:~> iptables -P FORWARD DROP
root@bridge:~> iptables -F FORWARD
root@bridge:~> iptables -I FORWARD -j ACCEPT
root@bridge:~> iptables -I FORWARD -j LOG
root@bridge:~> iptables -I FORWARD -j DROP
root@bridge:~> iptables -A FORWARD -j DROP
root@bridge:~> iptables -x -v --line-numbers -L FORWARD
</screen></informalexample>
<para>
La dernière ligne produit l'affichage suivant :
</para>
<informalexample><screen>
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 DROP all -- any any anywhere anywhere
2 0 0 LOG all -- any any anywhere anywhere LOG level warning
3 0 0 ACCEPT all -- any any anywhere anywhere
4 0 0 DROP all -- any any anywhere anywhere
</screen></informalexample>
<para>
La cible <emphasis>LOG</emphasis> trace tous les paquets via
<emphasis>syslogd</emphasis>.
Une telle configuration devrait se limiter à la phase de test
puisqu'elle ouvre la voie à un épuisement prématuré de la capacité
de stockage de la machine en cas d'attaque de type déni de service.
</para>
<para>
On teste les règles de filtrage en pingant l'adresse IP (195.137.15.7)
du routeur sur la machine <emphasis>babasse</emphasis> :
</para>
<informalexample><screen>
root@box:~> ping -c 3 195.137.15.7
PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data.
--- router.provider.net ping statistics ---
3 packets transmitted, 0 received, 100% loss, time 2020ms
^C
root@box:~>
</screen></informalexample>
<para>
La règle par défaut rejette (DROP) le trafic. Pas de réponse ni
de traçage des trames. Cette configuration netfilter est destinée
à jeter toutes les trames à moins que la règle 1 qui précède la
règle LOG ne soit supprimée :
</para>
<informalexample><screen>
root@bridge:~> iptables -D FORWARD 1
root@bridge:~> iptables -x -v --line-numbers -L FORWARD
</screen></informalexample>
<para>
Les règles sont à présent :
</para>
<informalexample><screen>
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
2 0 0 LOG all -- any any anywhere anywhere LOG level warning
3 0 0 ACCEPT all -- any any anywhere anywhere
4 0 0 DROP all -- any any anywhere anywhere
</screen></informalexample>
<para>
Tous les paquets devraient passer. On le confirme avec un ping
sur l'hôte <emphasis>babasse</emphasis> :
</para>
<informalexample><screen>
root@box:~> ping -c 3 195.137.15.7
PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data.
64 bytes from router.provider.net (195.137.15.7): icmp_seq=1 ttl=255 time=0.103 ms
64 bytes from router.provider.net (195.137.15.7): icmp_seq=2 ttl=255 time=0.082 ms
64 bytes from router.provider.net (195.137.15.7): icmp_seq=3 ttl=255 time=0.083 ms
--- router.provider.net ping statistics ---
3 packets transmitted, 3 received, 0% loss, time 2002ms
rtt min/avg/max/mdev = 0.082/0.089/0.103/0.012 ms
root@box:~>
</screen></informalexample>
<para>
Parfait, le routeur est vivant et opérationnel (bien sûr, il l'a été
toute la journée).
<note id="TestingImportantNote">
<para>
Une fois l'interface du pont activée, il faut compter dans les trente
secondes pour que le pont soit complètement opérationnel. La phase
d'apprentissage du pont est d'à peu près trente secondes. Pendant
ce temps, le pont analyse les adresses MAC au contact de chaque port.
L'auteur du code, Lennert, précise que ce point est susceptible
d'amélioration un de ces jours.
Pendant la période d'apprentissage, aucun paquet n'est transmis et
aucun ping n'obtiendra de réponse. Il vaut mieux ne pas l'oublier.
</para>
</note>
</para>
</sect2>
<sect2 id="TestingActualConfiguration">
<title>Exemple de configuration</title>
<para>
Cette partie est destinée à donner au lecteur quelques indications
sur l'allure que doit avoir son système après avoir suivi les
indications du HOWTO.
</para>
<sect3>
<title>Configuration de l'interface</title>
<para>
Résultat de la commande <application>ifconfig</application> :
<para>
<informalexample><screen>
root@bridge:~> ifconfig
br0 Link encap:Ethernet HWaddr 00:04:75:81:D2:1D
inet addr:10.0.3.129 Bcast:195.30.198.255 Mask:255.255.255.128
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:826 errors:0 dropped:0 overruns:0 frame:0
TX packets:737 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:161180 (157.4 Kb) TX bytes:66708 (65.1 Kb)
eth0 Link encap:Ethernet HWaddr 00:04:75:81:ED:B7
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5729 errors:0 dropped:0 overruns:0 frame:0
TX packets:3115 errors:0 dropped:0 overruns:0 carrier:656
collisions:0 txqueuelen:100
RX bytes:1922290 (1.8 Mb) TX bytes:298837 (291.8 Kb)
Interrupt:11 Base address:0xe400
eth1 Link encap:Ethernet HWaddr 00:04:75:81:D2:1D
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:1 frame:0
TX packets:243 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:342 (342.0 b) TX bytes:48379 (47.2 Kb)
Interrupt:7 Base address:0xe800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1034 errors:0 dropped:0 overruns:0 frame:0
TX packets:1034 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:82068 (80.1 Kb) TX bytes:82068 (80.1 Kb)
</screen></informalexample>
</para>
</sect3>
<sect3>
<title>Configuration du routage</title>
<para>
Résultat de la commande <application>route</application> :
</para>
<informalexample><screen>
root@bridge:~> route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.3.129 0.0.0.0 255.255.255.128 U 0 0 0 br0
0.0.0.0 10.0.3.129 0.0.0.0 UG 0 0 0 br0
root@bridge:~>
</screen></informalexample>
</sect3>
<sect3>
<title>Configuration d'iptables</title>
<para>
On se reportera à la section
<link linkend="TestingIptablesListing">Ping le, Max!</link>.
</para>
</sect3>
</sect2>
<sect2 id="HintFalsePositive">
<title>Remarque</title>
<para>
Il semble y avoir une anomalie dans le code br-nf :
</para>
<informalexample><screen>
From: Bart De Schuymer
Date: Sun, 1 Sep 2002 21:52:46 +0200
To: Nils Radtke
Subject: Re: Ethernet-Brigde-netfilter-HOWTO
Hello Nils,
[...]
Also, network packet filtering debugging is generally a bad idea with the
br-nf patch. It can gives a lot of false warnings (about bugs) in the logs.
[...]
</screen>
</informalexample>
<para>
NdT: l'auteur du message électronique signale que l'emploi des options
de déverminage lorsque br-nf a été appliqué est susceptible de remplir
les fichiers d'enregistrement de fausses alertes.
</para>
<para>
Pour ma part je n'ai jamais eu de fausse alerte dans mes logs.
Peut-être que l'anomalie a été corrigée. Contacté sur ce point,
Bart a répondu
</para>
<informalexample><screen>
From: Bart De Schuymer
Date: Mon, 2 Sep 2002 18:30:25 +0200
To: Nils Radtke
Subject: Re: Ethernet-Brigde-netfilter-HOWTO
On Monday 02 September 2002 00:39, Nils Radtke wrote:
> Will the revision of the nf-debug code in br-nf be subject of improvement?
I must admit I haven't been running any kernel with netfilter debugging
lately. It sure used to give false positives a few months ago (the bridge
mailing list has posts about that), I've been lacking time to see why and if
it is still the case. It's on my todo list.
[...]
</screen></informalexample>
<para>
NdT: l'auteur reconnaît ne pas avoir essayé la combinaison sus-citée
depuis un moment. Il n'a pas eu le temps dernièrement de confirmer
le problème ni de l'analyser. Il figure en tout cas dans son pense-bête.
</para>
<para>
À la date d'écriture de ce document (19/09/2002), je n'ai trouvé
aucun message comme quoi l'erreur aurait disparu. Il est donc
conseillé de garder un œil sur la
<link linkend="LinkMailinglist">liste de diffusion du pontage
Ethernet</link>
</para>
</sect2>
</sect1>
<!-- ### Testing ### -->
<!-- ############### -->
<!-- ############# -->
<!-- ### links ### -->
<sect1>
<title>Liens</title>
<para>
L'auteur du document peut être contacté en anglais ou en allemand
par <ulink
url="mailto:Ethernet-Bridge-netfilter-Howto_@_Think-Future.de">courrier
électronique</ulink>. Voir la <ulink
url="http://www.Think-Future.de/">page web</ulink> de l'auteur.
</para>
<para>Merci d'envoyer vos commentaires, remarques, corrections
concernant la version française de ce document à <ulink
url="mailto:commentaires@traduc.org?subject=Ethernet-Bridge-netfilter-HOWTO">commentaires@traduc.org</ulink></para>
<sect2>
<title>Pontage Ethernet</title>
<para>
<itemizedlist>
<listitem id="LinkMailinglist"><para>
La <ulink
url="http://www.math.leidenuniv.nl/pipermail/bridge/">liste</ulink>
de diffusion du pontage Ethernet.
</para></listitem>
<listitem id="LinkBridgeHome"><para>
Utilitaires, correctifs, et cætera : page web du
<ulink url="http://bridge.sourceforge.net">pontage Ethernet du
noyau Linux</ulink>.
</para></listitem>
<listitem id="LinkBridgeStpHowto"><para>
Le <ulink
url="&howto;BRIDGE-STP-HOWTO.html">Guide
pratique du pontage et de STP</ulink>.
</para></listitem>
<listitem id="LinkEnterpriseFw"><para>
Le <ulink
url="http://bridge.sourceforge.net/docs/Firewalling%20for%20Free.pdf">pare-feu</ulink>
économique, par Shawn Grimes.
</para></listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Thèmes voisins</title>
<para>
<itemizedlist>
<listitem>
<para>
Filtrage au niveau des trames, Ethernet-Bridging-Tables :
<itemizedlist>
<listitem><para><ulink
url="http://sourceforge.net/projects/ebtables">ebtables chez
sourceforge</ulink></para></listitem>
<listitem><para><ulink
url="http://ebtables.sourceforge.net/">page
page de garde</ulink> sourceforge
d'ebtables</para></listitem>
<listitem><para><ulink
url="http://users.pandora.be/bart.de.schuymer/ebtables/properties.html">fonctionnalités
d'ebtables</ulink></para></listitem>
<listitem><para>exemples pour ebtables : <ulink
url="http://users.pandora.be/bart.de.schuymer/ebtables/examples.html">simples</ulink>,
<ulink
url="http://users.pandora.be/bart.de.schuymer/ebtables/battlefield_examples.html">évolués</ulink></para></listitem>
<listitem><para><ulink
url="http://users.pandora.be/bart.de.schuymer/ebtables/br_fw_ia/br_fw_ia.html">documentation
détaillée d'ebtables</ulink></para></listitem>
<listitem><para><ulink
url="http://ebtables.sourceforge.net/ebtables-hacking/ebtables-hacking-HOWTO.html">guide
du bricoleur ebtables</ulink></para></listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
extension IP du pontage Linux
<ulink
url="http://www.linuxvirtualserver.org/~julian/#bridging">IP mode, LVS</ulink>
</para>
</listitem>
<listitem>
<para>
Linux et la haute disponibilité :
<ulink
url="http://www.linux-ha.org/">Linux haute disponibilité</ulink>
</para>
</listitem>
<listitem>
<para>
Serveur virtuel Linux :
<ulink
url="http://www.linuxvirtualserver.org/">LVS</ulink>
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
<!-- ### links ### -->
<!-- ############# -->
<!-- ### inf.misc_make ### -->
<!-- ###################### -->
</article>
<!-- EOF -->
<!-- vim: set ai ts=2 tw=72: -->
