<!doctype linuxdoc system>

<article>

<title>Linux Bridge+Firewall Mini-HOWTO version 1.2.0</title>
<author>Peter Breuer (<htmlurl url="mailto:ptb@it.uc3m.es" name="ptb@it.uc3m.es">)&nl;
Adaptation française par Etienne BERNARD (<htmlurl url="mailto:eb@via.ecp.fr" name="eb@via.ecp.fr">)</author>
<date>19 Décembre 1997</date>

<toc>

<sect><heading>Introduction<LABEL ID="Introduction">

<p>
Vous devriez lire l'original <url url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/mini/Bridge" name="Bridging mini-HOWTO"> (NdT&nbsp;: ou <url url="ftp://ftp.lip6.fr/pub/linux/french/docs/mini/Bridge" name="en version française">) par Chris Cole pour une vision différente sur le sujet. L'adresse email de Chris Cole est <htmlurl url="mailto:chris@polymer.uakron.edu" name="chris@polymer.uakron.edu">. La version de cet HOWTO, à partir duquel ce document est construit est la version 1.03, daté du 23 août 1996.

<sect><heading>Quoi, et pourquoi (et comment&nbsp;?)<LABEL ID="What and Why (and How?)">

<p>

<sect1><heading>Quoi<LABEL ID="What">

<p>
Un pont est un élément qui connecte intelligement des brins grâce à deux cartes ethernet.
Un <em/firewall/ est un élément isolant intelligent.

<sect1><heading>Pourquoi<LABEL ID="Why">

<p>Si vous avez de nombreux ordinateur, vous pouvez désirer installer un pont&nbsp;:

<enum>
<item><LABEL ID="bridge1">pour économiser le prix d'un nouveau <em/hub/ lorsqu'il se trouve que vous avez une carte ethernet libre&nbsp;;

<item><LABEL ID="bridge2">pour éviter d'avoir à apprendre l'<em/IP-forwarding/ et d'autres trucs alors que vous <em/avez/ deux cartes dans votre ordinateur&nbsp;;

<item><LABEL ID="bridge3">pour éviter des travaux de maintenance pour d'éventuels changements futurs&nbsp;!
</enum>

<p>
Le terme ``nombreux ordinateurs'' peut même représenter seulement trois ordinateurs, si ceux-ci font du routage ou du pontage ou qu'ils changent de place dans la pièce de temps en temps&nbsp;! Vous pouvez même vouloir un pont pour vous amuser à trouver à quoi cela sert. Je voulais un pont pour la raison <REF ID="bridge2" NAME="2">.

<p>
Si vous êtes intéressé par le point <REF ID="bridge1" NAME="1">, vous êtes peu dans votre cas. Lisez le <url url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/NET-2-HOWTO" name="NET-2-HOWTO"> et le <url url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/Serial-HOWTO" name="Serial-HOWTO"> pour de meilleurs astuces.

<p>Vous désirez un <em/firewall/ si&nbsp;:

<enum>
<item>vous essayez de protéger votre réseau des accès extérieur, ou<LABEL ID="firewall1">
<item>vous désirez interdire l'accès au monde extérieur aux machines de votre réseau.<LABEL ID="firewall2">
</enum>

<p>
Bizarrement, j'avais besoin du point <REF ID="firewall2" NAME="2"> ici aussi. La politique de mon université pour le moment est de ne pas jouer le rôle de fournisseur d'accès à Internet pour les <em/undergraduates/.

<sect1><heading>Comment<LABEL ID="How?">

<p>
J'ai commencé par du pontage entre deux cartes réseau sur une machine jouant le rôle de <em/firewall/, et j'ai fini par lancer le <em/firewall/ sans avoir coupé le pont. Cela a l'air de fonctionner, et c'est beaucoup plus flexible que chaque configuration isolée. Je peux arrêter le  <em/firewall/ et continuer à faire fonctionner le pont ou arrêter le pont lorsque je veux être plus prudent.

<p>Je suppose que la partie ``pont'' du noyau se trouve juste au-dessus de la couche physique et que la partie <em/firewall/ se trouve dans une couche réseau supérieure, afin que les parties de pontage et de <em/firewalling/ agissent en fait comme si elles étaient connectées en ``série'' et non pas en ``parallèle'' (aie&nbsp;!), selon le schéma suivant&nbsp;:

<tscreen><verb>
-&gt; Pont-entrant -&gt; Firewall-entrant -&gt; Noyau -&gt; Firewall-sortant -&gt; Pont-sortant -&gt;
</verb></tscreen>

<p>Il n'y a pas d'autre façon d'expliquer comment une machine peut être en même temps ``conducteur'' et ``isolant''. Il existe quelques embuches, mais j'en parlerai plus tard. Schématiquement, vous devez router les paquets que vous  voulez filtrer. De toute façon, cela a l'air de fonctionner parfaitement pour moi, et voici comment...

<sect><heading>PONT<LABEL ID="BRIDGING">

<sect1><heading>Logiciel<LABEL ID="Software">
<p>
Récupérez l'<url url="ftp://shadow.cabi.net/pub/Linux/BRCFG.tgz" name="utilitaire de configuration du pont"> depuis la page personnelle d'Alan Cox. C'est la même référence que dans le document de Chris. Je n'ai pas compris que c'était un URL <em/ftp/ en non un URL <em/http/...

<sect1><heading>Lecture préliminaires<LABEL ID="Prior Reading">

<p>Lisez le <url url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/mini/Multiple-Ethernet" name="Multiple Ethernet HOWTO"> pour obtenir des conseils pour faire reconnaître et pour configurer plus d'une carte réseau.

<p>Vous pourrez trouver encore plus de détails sur le type de commandes magiques à passer au <em/prompt/ se trouvent dans le <url url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/BootPrompt-HOWTO" name="Boot Prompt HOWTO">.

<p>Pour compléter vos lectures, lisez le <url url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/NET-2-HOWTO" name="NET-2 HOWTO">. C'est un document plutôt long, et vous devrez y piocher les détails qui vous intéressent.

<sect1><heading>Configuration de lancement<LABEL ID="Boot configuration">

<p>Les lectures précédentes vont vous indiquer ce dont vous avez besoin pour préparer le noyau à reconnaître un deuxième périphérique ethernet lors du démarrage, en ajoutant la ligne suivante dans votre fichier <tt>/etc/lilo.conf</tt>, et en relançant <tt/lilo/&nbsp;:

<tscreen><verb>append = &quot;ether=0,0,eth1&quot; </verb></tscreen>

<p>Notez le &quot;eth1&quot;. &quot;eth0&quot; représente la première carte. &quot;eth1&quot; est la seconde carte. Vous pouvez également ajouter les paramètres de démarrage à la ligne de commande que <tt/lilo/ vous offre. Pour trois cartes&nbsp;:

<tscreen><verb>linux ether=0,0,eth1 ether=0,0,eth2 </verb></tscreen>

<p>J'utilise <tt/loadlin/ pour lancer mon noyau Linux depuis DOS&nbsp;: 

<tscreen><verb>loadlin.exe c:\vmlinuz root=/dev/hda3 ro ether=0,0,eth1 ether=0,0,eth2 </verb></tscreen>

<p>Notez que cette astuce oblige le noyau à détecter les cartes au démarrage. La détection ne sera pas faite si vous chargez les gestionnaires de périphérique ethernet en <bf/module/ (par sécurité, puisque l'ordre de détection ne peut être déterminé), donc si vous utilisez des modules, vous aurez à ajouter l'IRQ appropriée et le paramètre de port pour le gestionnaire de périphérique dans votre fichier <tt>/etc/conf.modules</tt>. Dans mon cas, j'ai les lignes&nbsp;:

<tscreen> <verb>
alias eth0 3c509
alias eth1 de620
options 3c509 irq=5 io=0x210
options de620 irq=7 bnc=1
</verb> </tscreen>

<p>Vous pouvez savoir si vous utilisez les modules en utilisant ``ps -aux'' pour voir si <tt/kerneld/ est lancé, et en vérifiant qu'il y a des fichiers <tt/.o/ dans un sous-répertoire du répertoire <tt>/lib/modules</tt>. Utilisez le nom de répertoire que vous donne la commande <tt/uname -r/. Si vous avez un <tt/kerneld/ lancé et/ou vous avez un fichier <tt/foo.o/, éditez <tt>/etc/conf.modules</tt> et lisez avec soin la page de manuel de <tt/depmod/.

<p>Notez également que jusque récemment (noyau 2.0.25), le <em/driver/ pour la carte <bf/3c509/ ne pouvait pas être utilisé pour plus d'une carte s'il était utilisé en module. J'ai vu un <em/patch/ quelque part pour corriger cette limitation. Il devrait être inclus dans le noyau à l'heure où vous lisez ces lignes.

<sect1><heading>Configuration du noyau<LABEL ID="Kernel configuration">

<p>Recompilez le noyau avec le <em/bridging/&nbsp;:

<tscreen><verb>CONFIG_BRIDGE=y </verb></tscreen>

<p>J'ai également compilé mon noyau avec le <em/firewalling/, l'<em/IP-forwarding/ et l'<em/IP-masquerading/. C'est seulement si vous désirez utiliser le <em/firewalling/ également...

<tscreen><verb>CONFIG_FIREWALL=y           
CONFIG_NET_ALIAS=y          
CONFIG_INET=y               
CONFIG_IP_FORWARD=y         
CONFIG_IP_MULTICAST=y       
CONFIG_IP_FIREWALL=y        
CONFIG_IP_FIREWALL_VERBOSE=y
CONFIG_IP_MASQUERADE=y</verb></tscreen>

<p>Vous aurez besoin en plus de la configuration réseau standard&nbsp;:

<tscreen><verb>CONFIG_NET=y</verb></tscreen>

<p>et je ne pense pas que vous deviez vous préocupper des autres options réseau. Les options que je n'ai pas compilé dans le noyau sont sélectionnées en tant que modules afin que je puisse les ajouter éventuellement plus tard.

<p>Installez le nouveau noyau, relancez <tt/lilo/ et redémarrez sur le nouveau noyau. Rien ne devrait avoir changé pour l'instant&nbsp;!

<sect1><heading>Adresses réseau<LABEL ID="Network addresses">

<p>Chris dit qu'un pont ne doit pas avoir d'adresse IP mais ce n'est pas la configuration qui est présenté ici.

<p>Vous allez utiliser la machine pour vous connecter au réseau donc vous avez besoin d'une adresse et vous devez vous assurer que le device <em/loopback/ configuré normalement afin que vos logiciels puisse communiquer avec ce à quoi ils s'attendent. Si <em/loopback/ est désactivé, le <em/résolveur de noms/ ou d'autres services ne fonctionneront pas. Voyez le NET-2-HOWTO, mais votre configuration standard devrait déjà avoir fait cela&nbsp;:

<tscreen><verb>ifconfig lo 127.0.0.1
route add -net 127.0.0.0</verb></tscreen>

<p>Vous allez devoir donner des adresses à vos cartes réseau. J'ai changé le fichier <tt>/etc/rc.d/rc.inet1</tt> de ma slackware (3.x) pour configurer deux cartes et vous devrez juste regarder votre fichier de configuration du réseau et doubler ou tripler le nombre d'instructions s'y trouvant. Supposons que vous ayez déjà une adresse à

<tscreen><verb>192.168.2.100</verb></tscreen>

<p>(cette adresse fait partie des adresses réservées pour des réseaux privés, mais ne faites pas attention, cela ne cassera rien si vous utilisez cette adresse par erreur) alors vous avez probablement une ligne ressemblant à

<tscreen><verb>ifconfig eth0 192.168.2.100 netmask 255.255.255.0 metric 1</verb></tscreen>

<p>dans votre fichier de configuration. La première chose que vous allez probablement vouloir faire est couper l'espace des adresses atteintes par cette carte en deux afin de pouvoir éventuellement faire un pont ou filtrer entre les deux moitiés. Ajoutez donc une ligne qui réduit le masque de sous-réseau pour adresser un plus petit nombre de machines&nbsp;:

<tscreen><verb>ifconfig eth0 netmask 255.255.255.128</verb></tscreen>

<p>Essayez cette configuration. Cela restreint la carte à l'espace des adresses entre .0 et .127.

<p>A présent, vous pouvez configurer votre deuxième carte dans la deuxième moitié de l'espace des adresses locales. Assurez vous que personne n'utilise l'adresse que vous allez prendre. Pour des raisons de symétrie, j'utiliserai ici 228=128+100. N'importe quelle adresse conviendra, à condition qu'elle ne se trouve pas dans le masque de l'autre carte. Évitez les adresses spéciales comme .0, .1, .128, etc... à moins que vous sachiez ce que vous faites.

<tscreen><verb>ifconfig eth1 192.168.2.228 netmask 255.255.255.128 metric 1</verb></tscreen>

<p>Cela restreint la deuxième carte aux adresses entre .128 et .255. 

<sect1><heading>Routage réseau<LABEL ID="Network routing">

<p>C'est ici que les défauts de l'utilisation simultannée du pont et du firewall&nbsp;: vous ne pouvez pas filtrer des paquets qui ne sont pas routés. Pas de route, pas de firewall. Cette règle est vérifiée en tout cas dans les version 2.0.30 ou suivantes du noyau. Les filtres du firewall sont étroitement liés au code source de l'IP-Forwarding.

<p>Cela ne signifie pas que vous ne pouvez pas utiliser le pont. Vous pouvez installer un pont entre deux cartes et filtrer à partir d'une troisième. Vous pouvez n'avoir que deux cartes et les faire filtrer une adresse IP externe, comme celle d'un routeur proche, à condition que le routeur relié à une seule carte.

<p>En d'autres termes, puisque je veux utiliser la machine comme firewall, je dois contrôler avec précision la destination physique de certains paquets.

<p>J'ai le petit réseau de machines sur un <em/hub/ connecté à <tt/eth0/, je configure donc un réseau de ce côté&nbsp;:

<tscreen><verb>route add -net 192.168.2.128 netmask 255.255.255.128 dev eth0</verb></tscreen>

<p>Remplacez le 128 par un 0 pour un réseau de classe C entier. Ici, je ne le fais pas puisque j'ai juste divisé en deux l'espace d'adressage. Le &quot;dev eth0&quot; n'est pas nécessaire ici, puisque l'adresse de la carte fait partie de ce réseau, mais il peut être nécessaire de l'écrire chez vous. On pourrait désirer plus d'une carte prenant ce sous réseau en charge (127 machines sur un segment, bravo&nbsp;!) mais ces cartes utiliseraient le même masque de sous-réseau et seraient considérées comme une seule par la partie routage du noyau.

<p>Sur l'autre carte, j'ai une ligne qui passe directement à travers un gros routeur, auquel je fais confiance.

<verb>                                             client 129
         __                                        |    __ 
client 1   \    .0                    .128         |   /   net 1
client 2 --- Hub - eth0 - Kernel - eth1 - Hub - Router --- net 2
client 3 __/       .100            .228         .2 |   \__ net 3
                                                   |
                                             client 254</verb>

<p>J'utilise une route fixe (c'est-à-dire &quot;statique&quot;) depuis la carte vers ce routeur, puisque sinon il ferait partie du masque de sous-réseau de la première carte et le noyau se tromperait sur la manière d'envoyer les paquets au routeur. Je veux filtrer ces paquets et c'est une raison de plus de les router explicitement.

<tscreen><verb>route add 192.168.2.2 dev eth1</verb></tscreen>

<p>Je n'en ai pas besoin, puisque je n'ai pas d'autres machines dans cette moitié de l'espace d'adressage, mais je déclare un réseau sur la seconde carte. La séparation de mes interfaces réseau en deux groupes grâce au routage me permettra éventuellement de faire du filtrage très précis, mais vous pouvez très bien vous en sortir avec beaucoup moins de routage que cela.

<tscreen><verb>route add -net 192.168.2.128 netmask 255.255.255.128 dev eth1</verb></tscreen>

<p>J'ai également besoin d'envoyez tous les paquets non-locaux au monde et je dis donc au noyau de les envoyer au gros routeur&nbsp;:

<tscreen><verb>route add default gw 192.168.2.2</verb></tscreen>

<sect1><heading>configuration de la carte<LABEL ID="Card configuration">

<p>Nous avions auparavant une configuration standard pour le réseau, mais comme nous faisons du <em/bridging/, nous devons écouter sur chaque carte les paquets qui ne nous sont pas destinés. Ceci doit aller dans le fichier de configuration réseau&nbsp;:

<tscreen><verb>ifconfig promisc eth0
ifconfig promisc eth1</verb></tscreen>

<p>La page de manuel indique d'utiliser <tt/allmulti=promisc/, mais cela ne fonctionnait pas pour moi.

<sect1><heading>Routage additionnel<LABEL ID="Additional routing">

<p>J'ai remarqué une chose&nbsp;: j'ai dû passer la seconde carte dans un mode lui permettant aux questions du gros routeur à propos des machines que je cache sur mon réseau local.

<tscreen><verb>ifconfig arp eth1</verb></tscreen>

<p>Pour faire bonne mesure, j'ai effectué cette opération pour l'autre carte aussi.

<tscreen><verb>ifconfig arp eth0</verb></tscreen>

<sect1><heading>Configuration du pont<LABEL ID="Bridge Configuration">

<p>Ajoutez la mise en route du pont dans votre fichier de configuration&nbsp;:

<tscreen><verb>brcfg -enable</verb></tscreen>

<p>La configuration du pont mettra en route certains ports. Vous pouvez expérimenter l'allumage et l'extinction des ports un à la fois&nbsp;:

<tscreen><verb>brcfg -port 0 -disable/-enable
brcfg -port 1 -disable/-enable </verb></tscreen>

<p>Vous pouvez obtenir un rapport sur l'état courant avec&nbsp;:

<tscreen><verb>brcfg</verb></tscreen>

<p>sans aucun paramètres. Vous pourrez voir que le pont écoute, apprend, et effectue le <em/forwarding/. (Je ne comprends pas pourquoi le code répète la même adresse matérielle pour mes deux cartes, mais peu importe... le HOWTO de Chris affirme que c'est correct).

<sect1><heading>Essais<LABEL ID="Try it out">

<p>Si le réseau est encore en fonction, essayez votre script de configuration en vrai en arrêtant les deux cartes et en l'exécutant&nbsp;:

<tscreen><verb>ifconfig eth0 down
ifconfig eth1 down
/etc/rc.d/rc.inet1</verb></tscreen>

<p>Avec un peu de chance, les divers systèmes tel <bf/nfs/, <bf/ypbind/, etc... ne s'en rendront pas compte. <it/N'essayez pas ceci si vous n'êtes pas derrière le clavier&nbsp!/

<p>Si vous désirez être plus prudent que cela, vous devrez arrêter le plus de démons possible, et démonter les répertoires NFS. Le pire qu'il puisse vous arriver est d'avoir à rebooter en mode <em/single-user/ (le paramètre &quot;<bf>single</bf>&quot; de <tt/lilo/ ou <tt/loadlin/), et de restaurer les fichiers à leur valeur d'avant les modifications.

<sect1><heading>Vérifications

<p>Vérifiez qu'il existe un trafic différent sur chaque interface&nbsp;:

<tscreen>
<verb>tcpdump -i eth0</verb> (dans une fenêtre)
<verb>tcpdump -i eth1</verb> (dans une autre fenêtre)
</tscreen>

<p>Vous devriez être habitué à l'utilisation de <bf/tcpdump/ pour trouver des évènements qui ne devraient pas se passer, ou qui existent mais ne devraient pas.

<p>Par exemple, recherchez les paquets qui ont traversé le pont vers la seconde carte depuis le réseau interne. Ici, je cherche les paquets venant de la machine avec l'adresse .22&nbsp;:

<tscreen><verb>
tcpdump -i eth1 -e host 192.168.2.22
</verb></tscreen>

<p>A présent, envoyez un ping depuis l'hôte en .22 vers le routeur. Vous devriez voir le paquet affiché par tcpdump.

<p>A présent, vous devriez avoir un pont, et qui possède également deux adresses réseau. Vérifiez que vous pouvez les <tt/ping/er depuis l'extérieur de votre réseau local et depuis l'intérieur, que vous pouvez utiliser <tt/telnet/ et <tt/ftp/ depuis et vers l'intérieur du réseau.

<sect><heading>FIREWALLING<LABEL ID="FIREWALLING">

<sect1><heading>Logiciel et lectures<LABEL ID="Software and reading">

<p>Vous devriez lire le <url url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/Firewall-HOWTO" name="Firewall-HOWTO">.

<p>Il vous indiquera où trouver <tt/ipfwadm/ si vous ne l'avez pas déjà. Vous pouvez également récupérer d'autres outils, mais seulement <tt/ipfwadm/ m'a été utile. C'est pratique et de bas niveau&nbsp;! Vous pouvez voir exactement ce qu'il fait.

<sect1><heading>Vérifications préliminaires<LABEL ID="Preliminary checks">

<p>Vous avez compilé l'IP-forwarding et le masquerading dans le noyau, et vous allez vérifier que le <em/firewall/ est dans son état par défaut (il accepte) grâce à&nbsp;:

<tscreen><verb>ipfwadm -I -l
ipfwadm -O -l
ipfwadm -F -l</verb></tscreen>

<p>Ce qui, dans l'ordre, &quot;affiche les règles affectant la partie ..&quot;entrante ou sortante ou qui fait suivre (<em/masquerading/) &quot;.. du <em/firewall/&quot;. L'option &quot;-l&quot; signifie &quot;lister&quot;.

<p>Si vous avez compilé l'IP accounting également&nbsp;:

<tscreen><verb>ipfwadm -A -l</verb></tscreen>

<p>Vous devriez constater qu'aucune règle n'est définir et que l'action par défaut est d'accepter tous les paquets. Vous pouvez retourner à cet état à tout moment, avec&nbsp;:

<tscreen><verb>ipfwadm -I -f
ipfwadm -O -f
ipfwadm -F -f</verb></tscreen>

<p>L'option &quot;-f&quot; signifie &quot;flush&quot; (en français, &quot;vider&quot;). Vous pourriez en avoir besoin.


<sect1><heading>Règle par défaut<LABEL ID="Default rule">

<p>Je veux interdire l'accès au monde entier depuis mon réseau interne, et rien d'autre, donc je vais donner comme dernière règle (comme règle par défaut) une règle indiquant d'ignorer les paquets venant du réseau interne et dirigés vers l'extérieur. Je place toutes les règles (dans cet ordre) dans le fichier <tt>/etc/rc.d/rc.firewall</tt> que j'execute depuis <tt>/etc/rc.d/rc.local</tt> au démarrage.

<tscreen><verb>ipfwadm -I -a reject -S 192.168.2.0/255.255.255.128 -D 0.0.0.0/0.0.0.0</verb></tscreen>

<p>Le &quot;-S&quot; représente l'adresse source/masque de sous-réseau. L'option &quot;-D&quot; est pour l'adresse destination/masque de sous-réseau.

<p>Ce format n'a plus le vent en poupe. <tt/ipfwadm/ est intelligent et connaît des abréviations courantes. Vérifier les pages de manuel.

<p>Il peut être plus pratique de placer certaines ou toutes les règles sur la partie sortante du firewall en utilise &quot;-O&quot; au lieu de &quot;-I&quot;, mais je supposerai que les règles sont conçues pour être utilisées sur la moitié entrante.

<sect1><heading>Accès par adresse<LABEL ID="Holes per address">

<p>Avant la règle par défaut, je dois placer des règles qui servent d'exceptions pour cette interdiction générale des services extérieurs aux clients intérieurs.

<p>Je veux traiter les adresses des machines derrière le firewall de manière spéciale. Je veux empêcher aux gens de se loguer sur la machine qui sert de firewall à moins qu'elles aient une permission spéciale, mais une fois connectées, elles devraient être capables de parler au monde extérieur.

<tscreen><verb>ipfwadm -I -i accept -S 192.168.2.100/255.255.255.255 \
 -D 0.0.0.0/0.0.0.0</verb></tscreen>

<p>Je veux également que les clients internes soient capables de parler à la machine faisant <em/firewall/. Peut-être pourront-elles la persuader de les laisser sortir&nbsp;!

<tscreen><verb>ipfwadm -I -i accept -S 192.168.2.0/255.255.255.128 \
 -D 192.168.2.100/255.255.255.255</verb></tscreen>

<p>Vérifiez que vous pouvez joindre les machines à l'intérieur du firewall depuis l'extérieur par <tt/telnet/, mais que vous ne pouvez pas sortir. Vous pouvez faire le premier pas, mais les clients ne peuvent pas vous envoyer de messages. Essayez également <tt/rlogin/ et <tt/ping/ avec <tt/tcpdump/ lancé sur une carte ou l'autre. Vous devriez être capable de comprendre ce que vous lirez.

<sect1><heading>Accès par protocole<LABEL ID="Holes per protocol">

<p>J'assouplis les règles protocole par protocole. Je veux que les <tt/ping/s depuis l'extérieur vers l'intérieur obtiennent une réponse, par exemple, donc j'ai ajouté la règle&nbsp;:

<tscreen><verb>ipfwadm -I -i accept -P icmp -S 192.168.2.0/255.255.255.128 \
 -D 0.0.0.0/0.0.0.0</verb></tscreen>

<p>L'option &quot;<TT>-P icmp</TT>&quot; correspond au protocole tout entier.

<p>Avant que j'installe un <em/proxy ftp/, j'autorise également les appels ftp sortants en relâchant les restrictions sur un port donné. Ceci vise les ports 20, 21 et 115 sur les machines externes&nbsp;:

<tscreen><verb>ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
 -D 0.0.0.0/0.0.0.0 20 21 115</verb></tscreen>

<p>Je n'ai pas pu faire fonctionner <tt/sendmail/ entre les clients locaux sans serveur de noms. Au lieu d'installer un serveur de nom directement sur le <em/firewall/, j'ai juste autorisé les requêtes TCP de résolution de nom visant le plus proche serveur de nom, et j'ai placé son adresse dans le fichier <tt>/etc/resolv.conf</tt> des clients. (&quot;<TT>nameserver 123.456.789.31</TT>&quot; sur une ligne séparée).

<tscreen><verb>ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
 -D 123.456.789.31/255.255.255.255 54</verb></tscreen>

<p>Vous pouvez trouver quel numéro de port et protocole requiert un service grâce à <tt/tcpdump/. Utilisez ce service avec un <tt/ftp/ ou un <tt/telnet/ ou autre vers ou depuis une machine interne, et observez-le sur les ports d'entrée et de sortie du <em/firewall/ avec <tt/tcpdump/&nbsp;:

<tscreen><verb>tcpdump -i eth1 -e host client04</verb></tscreen>

<p>par exemple. Le fichier <tt>/etc/services/</tt> est une importante source d'indices. Pour laisser ENTRER le <tt/telnet/ et le <tt/ftp/ depuis l'extérieur, vous devez autoriser un client local à envoyer des données vers l'extérieur sur un port donné. Je comprends pourquoi ceci est nécessaire pour le <tt/ftp/ (c'est le serveur qui établit la connexion de données), mais je me demande pourquoi <tt/telnet/ en a également besoin.

<tscreen><verb>ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 ftp telnet \
 -D 0.0.0.0/0.0.0.0</verb></tscreen>

<p>Il existe un problème particulier avec certains démons qui cherchent le nom d'hôte de la machine <em/firewall/ afin de décider quelle est leur adresse réseau. J'ai eu des problèmes avec <tt/rpc.yppasswdd/. Il insiste sur des informations <em/broadcast/ qui indiquent qu'il se trouve en dehors du <em/firewall/ (sur la seconde carte). Cela signifie que les clients à l'intérieur ne peuvent pas le contacter.

<p>Au lieu de lancer l'IP aliasing ou de changer le code source du démon, j'ai traduit le nom vers l'adresse de la carte du côté intérieur sur les clients, dans leur fichier <tt>/etc/hosts</tt>.

<sect1><heading>Vérifications

<p>Vous voudrez tester que vous pouvez toujours utiliser <tt/telnet/, <tt/rlogin/ et <tt/ping/ depuis l'extérieur. Depuis l'intérieur, vous devriez être capable d'utiliser <tt/ping/ vers la sortie. Vous devriez également être capables d'utiliser le <tt/telnet/ vers la machine <em/firewall/ depuis l'intérieur, et cette dernière manipulation devrait vous permettre d'accéder au reste.

<p>Et voilà. A présent, vous voulez probablement apprendre <bf/rpc//<bf/Y/ellow <bf/P/ages et leur interaction avec le fichier de mots de passe. Le réseau derrière le firewall devrait vouloir empêcher aux utilisateurs non privilégiés de se logguer sur le <em/firewall/, et donc de sortir. C'est traité dans un autre HOWTO&nbsp;!

</article>
