Date: Thu, 6 Jun 2002 13:57:47 +0200 (CEST) From: Marc Fonvieille <marc@blackend.org> To: FreeBSD-gnats-submit@FreeBSD.org Cc: gioria@FreeBSD.org Subject: docs/38943: French translation of filtering-bridges article Message-ID: <200206061157.g56BvlWv011987@abigail.blackend.org>
next in thread | raw e-mail | index | archive | help
>Number: 38943
>Category: docs
>Synopsis: French translation of filtering-bridges article
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: update
>Submitter-Id: current-users
>Arrival-Date: Thu Jun 06 05:10:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Marc Fonvieille
>Release: FreeBSD 4.6-PRERELEASE i386
>Organization:
>Environment:
System: FreeBSD abigail.blackend.org 4.6-PRERELEASE FreeBSD 4.6-PRERELEASE #5: Sun May 12 00:30:43 CEST 2002 marc@abigail.blackend.org:/usr/src/sys/compile/ABIGAIL i386
>Description:
French translation of filtering-bridges article
>How-To-Repeat:
>Fix:
Apply the patch to fr_FR.ISO8859-1/
--- articles.diff begins here ---
diff -ruN articles.org/filtering-bridges/Makefile articles/filtering-bridges/Makefile
--- articles.org/filtering-bridges/Makefile Thu Jan 1 01:00:00 1970
+++ articles/filtering-bridges/Makefile Mon Jun 25 17:04:01 2001
@@ -0,0 +1,13 @@
+
+DOC?= article
+
+FORMATS?= html
+
+INSTALL_COMPRESSED?=gz
+INSTALL_ONLY_COMPRESSED?=
+
+SRCS= article.sgml
+
+DOC_PREFIX?= ${.CURDIR}/../../..
+
+.include "${DOC_PREFIX}/share/mk/doc.project.mk"
diff -ruN articles.org/filtering-bridges/article.sgml articles/filtering-bridges/article.sgml
--- articles.org/filtering-bridges/article.sgml Thu Jan 1 01:00:00 1970
+++ articles/filtering-bridges/article.sgml Thu Jun 6 13:46:30 2002
@@ -0,0 +1,483 @@
+<!--
+ The FreeBSD Project - http://www.FreeBSD.org
+ The FreeBSD French Documentation Project
+
+ $FreeBSD$
+ $Id$
+ Original revision: 1.10
+-->
+<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
+<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
+%man;
+<!ENTITY % abstract PUBLIC "-//FreeBSD//ENTITIES DocBook Abstract Entities//FR"> %abstract;
+<!ENTITY % artheader PUBLIC "-//FreeBSD//ENTITIES DocBook ArtHeader Entities//FR"> %artheader;
+<!ENTITY % translators PUBLIC "-//FreeBSD//ENTITIES DocBook Translator Entities//FR"> %translators;
+<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
+%man;
+]>
+
+<article>
+ <articleinfo>
+ <title>Ponts filtrants</title>
+
+ <authorgroup>
+ <author>
+ <firstname>Alex</firstname>
+ <surname>Dupre</surname>
+ <affiliation>
+ <address><email>sysadmin@alexdupre.com</email></address>
+ </affiliation>
+ </author>
+ </authorgroup>
+
+ <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/filtering-bridges/article.sgml,v 1.10 2002/06/05 22:09:07 keramida Exp $</pubdate>
+
+ <abstract>
+ <para>Souvent il est utile de diviser un réseau physique (comme un
+ réseau Ethernet) en deux segments séparés sans
+ avoir a créer des sous-réseaux, et utiliser de routeur
+ pour les relier ensemble. Le dispositif qui connecte les deux
+ réseaux de cette manière est
+ appelé un pont. Un système FreeBSD avec deux cartes
+ réseau est suffisant pour jouer le rôle d'un pont.</para>
+
+ <para>Un pont fonctionne en scannant les adresses au niveau
+ <acronym>MAC</acronym> (adresses Ethernet) des cartes connectées
+ à chacune de ses interfaces réseau et puis
+ transfère le trafic entre les deux réseaux si la
+ source et la destination sont situés sur un segment
+ différent. Sous beaucoup de points de vue
+ un pont est similaire à un commutateur (switch) Ethernet avec
+ uniquement deux ports.</para>
+ &abstract.license;
+ &abstract.disclaimer;
+ &trans.a.fonvieille;
+ </abstract>
+ </articleinfo>
+
+ <sect1 id="filtering-bridges-why">
+ <title>Pourquoi utiliser un pont filtrant?</title>
+
+ <para>De plus en plus fréquemment, grâce à la
+ baisse des coûts des connexions Internet haut débit
+ (xDSL) et aussi en raison de la réduction des adresses
+ IPv4 disponibles, beaucoup de compagnies
+ sont connectées à l'Internet 24 heures sur 24 et
+ avec peu (parfois même pas une puissance de 2) d'adresses IP.
+ Dans ces situations il est souvent désirable d'avoir un
+ coupe-feu qui filtre le trafic
+ entrant et sortant depuis et vers l'Internet, mais la solution
+ d'un filtrage de paquet basé sur un routeur peut ne pas
+ être applicable, soit en raison de problèmes de
+ sous-réseau, le routeur appartient au fournisseur
+ d'accès (<acronym>ISP</acronym>), ou
+ parce qu'il ne supporte pas une telle fonction. Dans ces
+ scénarios l'utilisation d'un pont filtrant est fortement
+ conseillée.</para>
+
+ <para>Un coupe-feu basé sur un pont peut être
+ configuré et inséré
+ entre le routeur xDSL et votre concentrateur/commutateur Ethernet
+ sans aucun problème d'adresse d'IP.</para>
+ </sect1>
+
+ <sect1 id="filtering-bridges-how">
+ <title>Comment l'installer</title>
+
+ <para>Ajouter les fonctions de pont à un système
+ FreeBSD n'est pas difficile. Depuis la 4.5-RELEASE il est possible
+ de charger de telles fonctionnalités sous forme de module
+ au lieu d'avoir à recompiler le noyau, simplifiant
+ énormément la procédure. Dans
+ les sous-sections suivantes j'expliquerai les deux méthodes
+ d'installation.</para>
+
+ <important>
+ <para><emphasis>Ne pas</emphasis> suivre les deux méthodes: une
+ procédure <emphasis>exclue</emphasis> l'autre. Choisissez la
+ meilleure en fonction de vos besoins et capacités.</para>
+ </important>
+
+ <para>Avant d'aller plus loin, soyez sûr de disposer deux cartes
+ Ethernet qui supportent le mode promiscuous pour la réception et
+ la transmission, comme elles doivent être capable d'envoyer des
+ paquets Ethernet avec n'importe quelle adresse, et non pas juste
+ pour la leur. De plus, pour avoir de bonnes performances, les
+ cartes devront être capable contrôler le bus
+ PCI (PCI bus mastering). Les meilleurs choix sont toujours
+ l'Intel EtherExpress Pro, suivie de la série 3c9xx de chez 3Com.
+ Pour simplifier la configuration il peut être utile d'avoir deux
+ cartes de différents constructeurs (utilisant un pilote de
+ périphérique différent) afin de distinguer
+ clairement quelle interface est connectée au routeur et
+ quelle autre est connectée au réseau.</para>
+
+ <sect2 id="filtering-bridges-kernel">
+ <title>Configuration du noyau</title>
+
+ <para>Donc vous avez décidé d'utiliser la bonne
+ vieille méthode d'installation. Pour commencer, vous
+ devez ajouter les lignes suivantes à votre fichier de
+ configuration du noyau:</para>
+
+ <programlisting>options BRIDGE
+options IPFIREWALL
+options IPFIREWALL_VERBOSE</programlisting>
+
+ <para>La première ligne est pour compiler le support du pont, la
+ seconde est le coupe-feu et la troisième sont les fonctions de
+ traces du coupe-feu.</para>
+
+ <para>Maintenant il est nécessaire de compiler et d'installer le
+ nouveau noyau. Vous pourrez trouver des instructions
+ détaillée dans la section <ulink
+ url="../../books/handbook/kernelconfig-building.html">Compiler
+ et installer un noyau sur mesures</ulink> du Manuel de
+ FreeBSD.</para>
+ </sect2>
+
+ <sect2 id="filtering-bridges-modules">
+ <title>Le chargement de modules</title>
+
+ <para>Si vous avez choisi d'employer cette méthode nouvelle et
+ plus simple; la seule chose à faire maintenant est d'ajouter la
+ ligne suivante au fichier
+ <filename>/boot/loader.conf</filename>:</para>
+
+ <programlisting>bridge_load="YES"</programlisting>
+
+ <para>De cette façon, durant le démarrage du
+ système le module <filename>bridge.ko</filename> sera
+ chargé avec le noyau. Il n'est pas nécessaire
+ de rajouter une ligne pour le module
+ <filename>ipfw.ko</filename>, étant donné qu'il
+ sera chargé automatiquement après
+ l'exécution des étapes présentées dans la
+ section suivante.</para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="filtering-bridges-finalprep">
+ <title>Dernière préparation</title>
+
+ <para>Avant de redémarrer afin de charger le nouveau noyau ou les
+ modules nécessaires (selon la méthode d'installation
+ précédemment retenue), vous devez faire quelques
+ modifications dans le fichier
+ de configuration <filename>/etc/rc.conf</filename>. La règle de
+ défaut du coupe-feu est de rejeter tous les paquets IP. Au
+ départ nous configurerons un coupe-feu “ouvert”, afin
+ de vérifier son fonctionnement sans problème relatif au
+ filtrage de paquet (dans le cas où vous faite cela à
+ distance, une telle configuration vous évitera de rester
+ isolé du réseau). Ajoutez les lignes suivantes dans
+ <filename>/etc/rc.conf</filename>:</para>
+
+ <programlisting>firewall_enable="YES"
+firewall_type="open"
+firewall_quiet="YES"
+firewall_logging="YES"</programlisting>
+
+ <para>La première ligne activera le coupe-feu (et chargera le module
+ <filename>ipfw.ko</filename> s'il n'est pas compilé dans le
+ noyau), la seconde le configurera dans le mode
+ “ouvert” (comme expliqué dans
+ <filename>/etc/rc.firewall</filename>), la troisième ligne rendra
+ le chargement des règles silencieux (sans affichage) et la
+ quatrième activera le support de trace d'activité
+ du coupe-feu.</para>
+
+ <para>Au sujet de la configuration des interfaces réseau, la
+ méthode la plus utilisée est d'assigner une adresse
+ IP à une seul des cartes réseau, mais le pont
+ fonctionnera à l'identique si les deux
+ interfaces ou aucune n'ont d'adresse IP configurée. Dans le
+ dernier cas (sans adresse IP) la machine faisant office de pont
+ sera toujours cachée et inaccessible depuis le réseau:
+ pour la configurer, vous devez vous attacher depuis la console ou
+ à travers une troisième interface réseau
+ séparée du pont. Parfois, durant
+ le démarrage du système, certains programmes ont
+ besoin d'accéder au réseau, par exemple pour la
+ résolution de noms: dans ce cas il
+ est nécessaire d'assigner une adresse IP à
+ l'interface externe (celle connectée à l'Internet
+ où le serveur <acronym>DNS</acronym>
+ réside), puisque le pont sera activé à la
+ fin de la procédure de démarrage. Cela signifie que
+ l'interface <devicename>fxp0</devicename> (dans notre cas) doit
+ être mentionnée dans la section concernant ifconfig
+ du fichier <filename>/etc/rc.conf</filename>, mais pas
+ <devicename>xl0</devicename>. Assigner une adresse IP aux deux
+ cartes réseau n'a pas beaucoup de sens, à moins que,
+ durant la procédure de démarrage, des applications
+ devront accéder à des
+ services sur les deux segments Ethernet.</para>
+
+ <para>Il y a une autre chose importante à savoir. Quand on utilise
+ l'IP sur Ethernet, il y a en fait deux protocoles Ethernet
+ utilisés: l'un est l'IP, l'autre est l'<acronym>ARP</acronym>.
+ <acronym>ARP</acronym> effectue la conversion de l'adresse IP d'un
+ hôte en son adresse Ethernet (couche <acronym>MAC</acronym>).
+ Afin d'autoriser la communication entre deux hôtes
+ séparés par le
+ pont, il est nécessaire que le pont transmette les paquets
+ <acronym>ARP</acronym>. Un tel protocole n'est pas inclut dans la
+ couche IP, puisque qu'il n'apparaît qu'avec l'utilisation de l'IP
+ sur Ethernet. Le coupe-feu de FreeBSD filtre exclusivement la
+ couche IP et donc tous les paquets non-IP (<acronym>ARP</acronym>
+ compris) seront transmis sans être filtrés, même
+ si le coupe-feu est configuré pour ne rien laisser passer.</para>
+
+ <para>Il est maintenant temps de redémarrer le système et de
+ l'utiliser comme auparavant: il y aura de nouveau messages
+ concernant le pont et le coupe-feu, mais le pont ne sera pas
+ activé et le coupe-feu, étant en mode “ouvert”,
+ n'interdira aucune opération.</para>
+
+ <para>Si il y a un quelconque problème, vous devriez le corriger
+ maintenant avant de continuer.</para>
+ </sect1>
+
+ <sect1 id="filtering-bridges-enabling">
+ <title>Activer le pont</title>
+
+ <para>A ce point, pour activer le pont, vous devez exécuter les
+ commandes suivantes (en pensant bien de remplacer les noms des deux
+ interfaces réseau <devicename>fxp0</devicename> et
+ <devicename>xl0</devicename> avec les vôtres):</para>
+
+ <screen>&prompt.root; <userinput>sysctl net.link.ether.bridge_cfg=fxp0:0,xl0:0</userinput>
+&prompt.root; <userinput>sysctl net.link.ether.bridge_ipfw=1</userinput>
+&prompt.root; <userinput>sysctl net.link.ether.bridge=1</userinput></screen>
+
+ <para>La première ligne spécifie quelles interfaces
+ devront être activées par le pont, la seconde
+ activera le coupe-feu sur le pont
+ et enfin la troisième activera le pont.</para>
+
+ <para>A ce moment là, vous devriez être en mesure
+ d'insérer la machine entre deux ensembles d'hôtes
+ sans compromettre de capacités de communication entre eux.
+ Ensuite, l'étape suivante est d'ajouter les parties
+ <literal>net.link.ether.<replaceable>[bla]</replaceable>=<replaceable>[bla]</replaceable></literal>
+ de ces lignes dans le fichier
+ <filename>/etc/sysctl.conf</filename> afin de les exécuter au
+ démarrage.</para>
+ </sect1>
+
+ <sect1 id="filtering-bridges-ipfirewall">
+ <title>Configurer le coupe-feu</title>
+
+ <para>Il est maintenant temps de créer votre propre fichier de
+ règle personnalisé pour le coupe-feu, afin de
+ sécuriser le réseau
+ interne. Il y aura quelques complication à faire cela parce que
+ toute les fonctionnalités du coupe-feu ne sont pas disponibles sur
+ un pont. En outre, il y a une différence entre les paquets qui
+ sont en cours de transmission et les paquets qui sont reçus par la
+ machine locale. En général, les paquets entrants
+ traversent le coupe-feu une seule fois, et pas deux comme c'est
+ normalement le cas; en fait ils sont filtrés à la
+ réception, aussi les règles qui
+ utilisent “out” ou “xmit” n'agirons
+ jamais. Personnellement, j'utilise “in via” qui est
+ une ancienne syntaxe, mais qui a un sens quand vous la lisez. Une
+ autre limitation est que vous êtes réduit à
+ l'utilisation seulement des commandes “pass” ou
+ “drop” pour les paquets filtrés par un pont.
+ Les choses sophistiquées comme “divert”,
+ “forward” ou “reject” ne sont pas
+ disponibles. De telles options peuvent toujours être
+ utilisées, mais uniquement sur le trafic à
+ destination ou depuis le pont lui-même (s'il possède
+ une adresse IP).</para>
+
+ <para>Une nouveauté de FreeBSD 4.0, est le concept de filtrage avec
+ gestion des états (stateful). C'est une grande
+ amélioration pour le trafic <acronym>UDP</acronym>, qui
+ typiquement est une requête de sortie, suivie peu de temps
+ après par une réponse avec le même ensemble
+ d'adresses IP et de numéro de ports (mais avec
+ une source et une destination réservée, bien sûr).
+ Pour les coupe-feux qui n'ont pas de gestion des états,
+ il n'y a presque pas de possibilité de gérer ce type
+ de trafic en une seule session. Mais avec un coupe-feu qui peut se
+ “souvenir” d'un paquet <acronym>UDP</acronym> sortant et
+ qui, pour quelques minutes, autorise une réponse, la gestion
+ des services <acronym>UDP</acronym> est triviale. L'exemple suivant
+ montre comment le faire. Il est possible de faire la même
+ chose avec les paquets <acronym>TCP</acronym>. Cela vous permet
+ d'éviter certaines attaques par refus de service et autres
+ désagréables problèmes, mais augmente
+ également rapidement la taille de votre
+ table des états.</para>
+
+ <para>Regardons un exemple de configuration. Notez tout d'abord
+ qu'au début du fichier <filename>/etc/rc.firewall</filename>
+ il y a déjà des règles standards pour
+ l'interface de boucle locale
+ <devicename>lo0</devicename>, aussi nous ne devrions pas y faire
+ attention. Les règles personnalisées devraient
+ être placées dans un fichier séparé (disons
+ <filename>/etc/rc.firewall.local</filename>) et chargées au
+ démarrage du système, en modifiant la ligne de
+ <filename>/etc/rc.conf</filename> où nous avions défini le
+ coupe-feu “ouvert”:</para>
+
+ <programlisting>firewall_type="/etc/rc.firewall.local"</programlisting>
+
+ <important>
+ <para>Vous devez préciser le chemin <emphasis>complet</emphasis>,
+ sinon il ne sera pas chargé avec le risque de rester
+ isolé du réseau.</para>
+ </important>
+
+ <para>Pour notre exemple imaginez que nous avons l'interface
+ <devicename>fxp0</devicename> connectée vers l'extérieur
+ (Internet) et l'interface <devicename>xl0</devicename> vers
+ l'intérieur (<acronym>LAN</acronym>). Le pont possède
+ une adresse IP <hostid role="ipaddr">1.2.3.4</hostid> (il n'est pas
+ possible que votre fournisseur d'accès puisse vous donner une
+ adresse de classe A comme celle-ci, mais pour cet exemple cela
+ ira).</para>
+
+ <programlisting># Les choses dont nous avons gardé l'état avant de
+continuer
+add check-state
+
+# Rejeter les réseaux RFC 1918
+add drop all from 10.0.0.0/8 to any in via fxp0
+add drop all from 172.16.0.0/12 to any in via fxp0
+add drop all from 192.68.0.0/16 to any in via fxp0
+
+# Autorise la machine pont à communiquer si elle le désire
+# (si la machine est sans adresse IP, ne pas inclure ces lignes)
+add pass tcp from 1.2.3.4 to any setup keep-state
+add pass udp from 1.2.3.4 to any keep-state
+add pass ip from 1.2.3.4 to any
+
+# Autorise les hôtes internes à communiquer
+add pass tcp from any to any in via xl0 setup keep-state
+add pass udp from any to any in via xl0 keep-state
+add pass ip from any to any in via xl0
+
+# Section TCP
+# Autoriser SSH
+add pass tcp from any to any 22 in via fxp0 setup keep-state
+# Autoriser SMTP seulement vers le serveur de courrier
+add pass tcp from any to relay 25 in via fxp0 setup keep-state
+# Autoriser le transfert de zone seulement par le serveur de noms esclave [dns2.nic.it]
+add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state
+# Laisser passer les sondes d'ident. C'est préférable plutôt que d'attendre
+# qu'elles s'arrêtent
+add pass tcp from any to any 113 in via fxp0 setup keep-state
+# Laisser passer la zone de "quarantaine"
+add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state
+
+# Section UDP
+# Autorise le DNS seulement vers le serveur de noms
+add pass udp from any to ns 53 in via fxp0 keep-state
+# Laisser passer la zone de "quarantaine"
+add pass udp from any to any 49152-65535 in via fxp0 keep-state
+
+# Section ICMP
+# Laisser passer 'ping'
+add pass icmp from any to any icmptypes 8 keep-state
+# Laisser passer les messages d'erreurs générés par 'traceroute'
+add pass icmp from any to any icmptypes 3
+add pass icmp from any to any icmptypes 11
+
+# Tout le reste est suspect
+add drop log all from any to any</programlisting>
+
+ <para>Ceux qui parmi vous ont déjà installé
+ des coupe-feux auparavant pourront noter l'absence de certaines
+ choses. En particulier, il n'y a pas de règles contre le
+ forgeage d'adresses, en fait nous n'avons <emphasis>pas</emphasis>
+ ajouté:</para>
+
+ <programlisting>add deny all from 1.2.3.4/8 to any in via fxp0</programlisting>
+
+ <para>Cela, bloque les paquets provenant de l'extérieur et clamant
+ être en provenance de votre réseau. C'est quelque chose
+ que vous devriez habituellement faire pour être sûr que
+ personne n'essaie de passer outre votre filtre de paquet, en
+ générant d'infames paquets qui sont comme s'il venaient
+ de l'intérieur. Le problème
+ avec cela est qu'il y a <emphasis>au moins</emphasis> un hôte de
+ l'extérieur que vous ne voulez pas ignorer: le routeur. Mais
+ habituellement, les fournisseurs d'accès contrent le forgeage sur
+ leur routeur, aussi nous ne devons pas nous en préoccuper plus que
+ cela.</para>
+
+ <para>La dernière règle semble être une copie
+ conforme de la règle par défaut, qui ne laisse passer
+ rien de ce qui n'est pas spécifiquement autorisé. Mais
+ il y a une différence: tout le
+ trafic suspect sera tracé.</para>
+
+ <para>Il y a deux règles pour faire passer le trafic
+ <acronym>SMTP</acronym> et <acronym>DNS</acronym> vers le serveur
+ de courrier et le serveur de noms, si vous en avez. Evidemment
+ l'ensemble du jeu de règle devra être arrangé
+ selon vos goûts
+ personnels, c'est juste un exemple particulier (le format des
+ règles est décrit précisément dans la
+ page de manuel &man.ipfw.8;). Notez qu'afin que “relay” et
+ “ns” puissent fonctionner, les services de résolution
+ de nom doivent fonctionner <emphasis>avant</emphasis> que le pont
+ soit activé. C'est un exemple pour être sûr que
+ vous avez configuré l'adresse IP sur la bonne carte
+ réseau. Alternativement
+ il est possible de spécifier l'adresse IP au lieu du nom
+ (nécessaire si la machine est sans adresse IP).</para>
+
+ <para>Les personnes qui ont l'habitude de configurer des coupe-feux
+ ont probablement également utilisé soit une règle
+ “reset” soit une règle “forward” pour les
+ paquets ident (<acronym>TCP</acronym> port 113). Malheureusement,
+ ce n'est pas une option applicable avec un pont, aussi la
+ meilleure solution est de laisser les passer vers leur
+ destination. Aussi longtemps que la machine de destination de
+ fait pas tourner un daemon d'ident, cela est relativement
+ inoffensif. L'alternative est de bloquer les connexions sur le
+ port 113, ce qui pose problème avec des services comme
+ l'<acronym>IRC</acronym> (la sonde d'ident doit s'arrêter).</para>
+
+ <para>La seule autre chose qui est un peu étrange que vous avez
+ peut-être noté est qu'il y a une règle pour
+ laisser le pont communiquer, et une autre pour les hôtes
+ internes. Rappelez-vous que c'est parce que les deux ensembles de
+ trafic prendront un chemin différent à travers le noyau
+ et dans le filtre de paquet. Le réseau interne ira à
+ travers le pont, alors que la machine
+ locale utilisera la pile IP normale pour communiquer. Ainsi les
+ deux règles s'occupent de cas différents. La
+ règle “in via <devicename>fxp0</devicename>”
+ fonctionne pour les deux chemins. En général, si
+ vous employez des règles “in via” dans tous le
+ filtre, vous devrez faire une exception pour les paquets
+ générés localement, parce qu'ils ne sont pas
+ passés par une de nos interfaces.</para>
+ </sect1>
+
+ <sect1 id="filtering-bridges-contributors">
+ <title>Participants</title>
+
+ <para>Plusieurs parties de cet article proviennent, et furent mises
+ à jour et adaptées d'un vieux texte sur les ponts,
+ écrit par Nick Sayer. Cet article est également
+ inspiré d'une introduction sur les ponts
+ de Steve Peterson.</para>
+
+ <para>Un grand merci à Luigi Rizzo pour l'implémentation
+ du code de pont dans FreeBSD et pour le temps qu'il a passé
+ à répondre à toutes
+ mes questions à ce sujet.</para>
+
+ <para>Un remerciement également à Tom Rhodes qui a
+ supervisé mon travail de traduction de l'Italien (langue
+ d'origine de cet article) à l'Anglais.</para>
+ </sect1>
+</article>
--- articles.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206061157.g56BvlWv011987>