From 031afcb3a778093ca633991cb9dc670053d6950c Mon Sep 17 00:00:00 2001 From: Marc Fonvieille Date: Mon, 22 Jul 2002 20:50:51 +0000 Subject: [PATCH] Typos fixes and a sgml fix --- .../articles/filtering-bridges/article.sgml | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/fr_FR.ISO8859-1/articles/filtering-bridges/article.sgml b/fr_FR.ISO8859-1/articles/filtering-bridges/article.sgml index eae75e5b2c..c0e62610d3 100644 --- a/fr_FR.ISO8859-1/articles/filtering-bridges/article.sgml +++ b/fr_FR.ISO8859-1/articles/filtering-bridges/article.sgml @@ -3,7 +3,7 @@ The FreeBSD French Documentation Project $FreeBSD$ - $Id: article.sgml,v 1.1 2002-06-08 09:55:07 gioria Exp $ + $Id: article.sgml,v 1.2 2002-07-22 20:50:51 blackend Exp $ Original revision: 1.10 --> -
+
Ponts filtrants @@ -35,7 +35,7 @@ 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 + avoir à 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 @@ -45,7 +45,7 @@ MAC (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 + source et la destination sont situées sur un segment différent. Sous beaucoup de points de vue un pont est similaire à un commutateur (switch) Ethernet avec uniquement deux ports. @@ -100,7 +100,7 @@ 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 + la transmission, comme elles doivent être capables 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 @@ -130,7 +130,7 @@ options IPFIREWALL_VERBOSE Maintenant il est nécessaire de compiler et d'installer le nouveau noyau. Vous pourrez trouver des instructions - détaillée dans la section Compiler et installer un noyau sur mesures du Manuel de FreeBSD. @@ -189,7 +189,7 @@ firewall_logging="YES" 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 + IP à une seule 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 @@ -222,7 +222,7 @@ firewall_logging="YES" 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 - ARP. Un tel protocole n'est pas inclut dans la + ARP. Un tel protocole n'est pas inclus 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 (ARP @@ -230,7 +230,7 @@ firewall_logging="YES" si le coupe-feu est configuré pour ne rien laisser passer. Il est maintenant temps de redémarrer le système et de - l'utiliser comme auparavant: il y aura de nouveau messages + l'utiliser comme auparavant: il y aura de nouveaux 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. @@ -272,15 +272,15 @@ firewall_logging="YES" 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 + interne. Il y aura quelques complications à faire cela parce que + toutes 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 + utilisent “out” ou “xmit” n'agiront 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 à @@ -438,9 +438,9 @@ add drop log all from any to any “reset” soit une règle “forward” pour les paquets ident (TCP 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 + meilleure solution est de les laisser passer vers leur + destination. Aussi longtemps que la machine de destination ne + fait pas tourner un daemon 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'IRC (la sonde d'ident doit s'arrêter). @@ -456,7 +456,7 @@ add drop log all from any to any deux règles s'occupent de cas différents. La règle “in via fxp0” fonctionne pour les deux chemins. En général, si - vous employez des règles “in via” dans tous le + vous employez des règles “in via” dans tout 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.