Typos fixes and a sgml fix
This commit is contained in:
Marc Fonvieille
parent
25c7907cce
commit
031afcb3a7
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=13684
1 changed files with 16 additions and 16 deletions
|
|
@ -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
|
||||
-->
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
|
|
@ -16,7 +16,7 @@
|
|||
%man;
|
||||
]>
|
||||
|
||||
<article>
|
||||
<article lang="fr">
|
||||
<articleinfo>
|
||||
<title>Ponts filtrants</title>
|
||||
|
||||
|
|
@ -35,7 +35,7 @@
|
|||
<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
|
||||
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 @@
|
|||
<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
|
||||
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.</para>
|
||||
|
|
@ -100,7 +100,7 @@
|
|||
|
||||
<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
|
||||
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</programlisting>
|
|||
|
||||
<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
|
||||
détaillées dans la section <ulink
|
||||
url="../../books/handbook/kernelconfig-building.html">Compiler
|
||||
et installer un noyau sur mesures</ulink> du Manuel de
|
||||
FreeBSD.</para>
|
||||
|
|
@ -189,7 +189,7 @@ firewall_logging="YES"</programlisting>
|
|||
|
||||
<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
|
||||
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"</programlisting>
|
|||
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
|
||||
<acronym>ARP</acronym>. 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 (<acronym>ARP</acronym>
|
||||
|
|
@ -230,7 +230,7 @@ firewall_logging="YES"</programlisting>
|
|||
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
|
||||
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.</para>
|
||||
|
|
@ -272,15 +272,15 @@ firewall_logging="YES"</programlisting>
|
|||
<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
|
||||
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</programlisting>
|
|||
“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
|
||||
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'<acronym>IRC</acronym> (la sonde d'ident doit s'arrêter).</para>
|
||||
|
|
@ -456,7 +456,7 @@ add drop log all from any to any</programlisting>
|
|||
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
|
||||
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.</para>
|
||||
|
|
|
|||
Loading…
Reference in a new issue