<?xml version="1.0" encoding="ISO-8859-15"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<article lang="fr">
  <!--$Id$-->

  <articleinfo>
    <title>FAQ Shorewall</title>

    <subtitle>Version Française de <foreignphrase lang="en"><ulink
    url="http://www.shorewall.net/FAQ.html">Shorewall
    FAQs</ulink></foreignphrase></subtitle>

    <authorgroup>
      <corpauthor>Shorewall Community</corpauthor>

      <author>
        <firstname>Tom</firstname>

        <surname>Eastep</surname>
      </author>

      <othercredit role="translator">
        <firstname>Guy</firstname>

        <surname>Marcenac</surname>

        <contrib>Adaptation française</contrib>
      </othercredit>
    </authorgroup>

    <pubdate><?dbtimestamp format="Y/m/d"?></pubdate>

    <copyright>
      <year>2001-2006</year>

      <holder>Thomas M. Eastep</holder>

      <holder>Guy Marcenac</holder>
    </copyright>

    <legalnotice>
      <para>Permission est accordée de copier, distribuer et/ou modifier ce
      document selon les termes de la Licence de Documentation Libre GNU (GNU
      Free Documentation License), version 1.2 ou toute version ultérieure
      publiée par la Free Software Foundation ; sans section Invariables, sans
      première de Couverture, et sans texte de quatrième de couverture. Une
      copie de la présente Licence est incluse dans la section intitulée. Une
      traduction française de la licence se trouve dans la section
      <quote><ulink url="http://cesarx.free.fr/gfdlf.html">Licence de
      Documentation Libre GNU</ulink></quote>. Ce paragraphe est une
      traduction française pour aider à votre compréhension. Seul le texte
      original en anglais présenté ci-dessous fixe les conditions
      d'utilisation de cette documentation.</para>

      <para>Permission is granted to copy, distribute and/or modify this
      document under the terms of the GNU Free Documentation License, Version
      1.2 or any later version published by the Free Software Foundation; with
      no Invariant Sections, with no Front-Cover, and with no Back-Cover
      Texts. A copy of the license is included in the section entitled <quote>
      <ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink>
      </quote>.</para>
    </legalnotice>
  </articleinfo>

  <note>
    <para><emphasis role="underline">Notes du traducteur :</emphasis> Si vous
    trouvez des erreurs ou si vous avez des améliorations à apporter à cette
    traduction vous pouvez <ulink url="mailto:guy@posteurs.com">me
    contacter</ulink>.</para>
  </note>

  <caution>
    <para><emphasis role="bold">Cet article s'applique à Shorewall 3.0 et à
    ses versions ultérieures. Si vous utilisez une version plus ancienne de
    Shorewall, référez-vous à la documentation s'appliquant à votre
    version.</emphasis></para>
  </caution>

  <section>
    <title>Installation de Shorewall</title>

    <section>
      <title>Où puis-je trouver des instructions d'installation et de
      configuration pas à pas ?</title>

      <para><emphasis role="bold">Réponse:</emphasis> Allez voir les <ulink
      url="shorewall_quickstart_guide.htm">guides de démarrage
      rapide</ulink>.</para>
    </section>

    <section id="faq37">
      <title>(FAQ 37) Je viens d'installer Shorewall sur Debian et le
      répertoire /etc/shorewall est vide!!!</title>

      <para><emphasis role="bold">Réponse:</emphasis></para>

      <important>
        <para>Après avoir installé le paquetage .deb, avant de commencer à
        configurer Shorewall, vous devriez prendre connaissance de ce conseil
        de Lorenzo Martignoni, le mainteneur Debian de Shorewall:</para>

        <para><quote>Pour plus d'information quant à l'utilisation de
        Shorewall sur un système Debian vous devriez aller voir le fichier
        /usr/share/doc/shorewall/README.Debian distribué avec le paquetage
        Debian de Shorewall.</quote></para>
      </important>

      <para>Si vous vous servez du .deb pour installer, vous vous rendrez
      compte que votre répertoire <filename>/etc/shorewall</filename> est
      vide. Ceci est voulu. Les squelettes des fichiers de configuration se
      trouvent sur votre système dans le répertoire <filename
      class="directory">/usr/share/doc/shorewall/default-config</filename>.
      Copiez simplement les fichiers dont vous avez besoin depuis ce
      répertoire dans <filename class="directory">/etc/shorewall</filename>,
      puis modifiez ces copies.</para>

      <para>Remarquez que vous devez copier
      <filename>/usr/share/doc/shorewall/default-config/shorewall.conf</filename>
      et <filename>/usr/share/doc/shorewall/default-config/modules</filename>
      dans <filename
      class="directory"><filename>/etc/shorewall</filename></filename> même si
      vous ne modifiez pas ces fichiers.</para>
    </section>

    <section id="faq44">
      <title>(FAQ 44) Je n'arrive pas à installer ou mettre à jour le RPM -
      J'ai le message d'erreur "error: failed dependencies:iproute is
      needed..."</title>

      <para><emphasis role="bold">Réponse</emphasis>: Lisez les <ulink
      url="Install_fr.html">Instructions d'installation</ulink>!</para>
    </section>

    <section id="faq50">
      <title>(FAQ 50) Quand j'installe ou que je mets à jour, j'obtiens de
      multiples instances du message suivant "warning: user teastep does not
      exist - using root"</title>

      <para><emphasis role="bold">Réponse:</emphasis> Vous pouvez sans aucun
      risque ignorer ce message. Il était dû à une erreur mineure de paquetage
      qui a été corrigée depuis. Cela ne change rien dans l'utilisation de
      Shorewall.</para>
    </section>
  </section>

  <section id="PortForwarding">
    <title>Transfert de port (Redirection de Port)</title>

    <section id="faq1">
      <title>(FAQ 1) Je veux rediriger le port UDP 7777 vers mon PC personnel
      qui a l'adresse 192.1683.1.5. J'ai cherché partout et je ne trouve pas
      comment faire.</title>

      <para><emphasis role="bold">Réponse:</emphasis> Le premier exemple de la
      <ulink url="Documentation.htm#Rules">documentation du fichier
      rules</ulink> vous indique comment faire du transfert de port avec
      Shorewall. Le format d'une règle de redirection de port vers un système
      local se présente comme suit:</para>

      <programlisting>#ACTION    SOURCE      DEST                                   PROTO        DEST PORT
DNAT       net         loc:&lt;<emphasis>adresse IP locale</emphasis>&gt;[:&lt;<emphasis>port local</emphasis>&gt;] &lt;<emphasis>protocole</emphasis>&gt;  &lt;<emphasis>n° port</emphasis>&gt;</programlisting>

      <para>Ainsi pour rediriger le port UDP 7777 vers le système interne
      192.168.1.5, la règle est:</para>

      <programlisting>#ACTION    SOURCE   DEST             PROTO    DEST PORT
DNAT       net      loc:192.168.1.5  udp      7777</programlisting>

      <para>Si vous voulez rediriger vers un système interne les requêtes
      envoyées à une adresse donnée (<emphasis>&lt;IP externe&gt;</emphasis>)
      sur votre firewall:</para>

      <programlisting>#ACTION SOURCE DEST                                   PROTO       DEST PORT  SOURCE  ORIGINAL
#                                                                            PORT    DEST.
DNAT    net    loc:&lt;<emphasis>adresse IP locale</emphasis>&gt;[:&lt;<emphasis>port local</emphasis>&gt;]&lt;<emphasis>protocole</emphasis>&gt;  &lt;<emphasis>n° port</emphasis>&gt;   -       &lt;<emphasis>IP externe</emphasis>&gt;</programlisting>

      <para>Enfin, si vous avez besoin de rediriger une plage de ports,
      spécifiez la plage de ports &lt;premier port&gt;:&lt;dernier port&gt;
      dans la colonne DEST PORT.</para>

      <section id="faq1a">
        <title>(FAQ 1a) D'accord -- j'ai suivi toutes ces instruction, mais
        cela ne marche toujours pas.</title>

        <para><emphasis role="bold">Réponse:</emphasis> Ceci se produit
        généralement lorsque:</para>

        <itemizedlist>
          <listitem>
            <para>Vous tentez de tester depuis l'intérieur de votre firewall
            (non, cela ne marchera pas -- allez voir la <link
            linkend="faq2">FAQ 2</link> ).</para>
          </listitem>

          <listitem>
            <para>Vous avez un problème plus élémentaire de configuration de
            votre système local (celui vers lequel vous tentez de rediriger
            les paquets), une mauvaise passerelle par défaut par exemple (elle
            devrait être configurée avec l'adresse IP de l'interface interne
            de votre firewall).</para>
          </listitem>

          <listitem>
            <para>Votre FAI bloque le trafic entrant sur ce port
            particulier.</para>
          </listitem>

          <listitem>
            <para>Vous utilisez une version de Mandriva antérieure à la 10.0
            final et vous avez configuré le partage de connexion internet. Si
            c'est le cas, le nom de votre zone locale n'est pas 'loc' mais
            'masq' (dans vos règles changez toutes les instances de 'loc' pour
            'masq'). Vous pouvez envisager de ré-installer Shorewall avec une
            configuration conforme à la documentation de Shorewall. Voir le
            guide <ulink url="two-interface_fr.html">Firewall à deux
            interfaces</ulink> pour plus de détails.</para>
          </listitem>
        </itemizedlist>
      </section>

      <section id="faq1b">
        <title>(FAQ 1b) J'ai malgré tout encore des problèmes avec la
        redirection de port</title>

        <para><emphasis role="bold">Réponse:</emphasis> pour aller plus avant
        dans le diagnostic du problème:</para>

        <itemizedlist>
          <listitem>
            <para>En tant que root, tapez <quote> <command>iptables -t nat
            -Z</command> </quote>. Ceci remet à zéro les compteurs Netfilter
            de la table nat.</para>
          </listitem>

          <listitem>
            <para>Essayez de vous connecter au port redirigé depuis un hôte
            externe.</para>
          </listitem>

          <listitem>
            <para>En tant que root, tapez <quote> <command>shorewall[-lite]
            show nat</command> </quote></para>
          </listitem>

          <listitem>
            <para>Repérez la règle DNAT appropriée. Elle sera dans une chaîne
            nommée &lt;<emphasis>zone source</emphasis>&gt;_dnat
            (<quote>net_dnat</quote> dans les exemples ci-dessus).</para>
          </listitem>

          <listitem>
            <para>Est-ce que le décompte de paquets dans la première colonne
            est supérieur à zéro ? Si cela est le cas, la requête de connexion
            atteint le firewall et est bien redirigée vers le serveur. Dans ce
            cas, le problème vient en général de l'absence de paramètrage ou
            d'un paramètrage erroné de la passerelle par défaut sur le système
            local (celui vers lequel vous essayez de transférer les paquets --
            sa passerelle par défaut devrait être l'adresse IP de l'interface
            du firewall connectée à ce système local).</para>
          </listitem>

          <listitem>
            <para>Si le décompte de paquets est égal à zéro:</para>

            <itemizedlist>
              <listitem>
                <para>La requête de connexion n'arrive pas jusqu'à votre
                serveur (il est possible que votre FAI bloque ce port)</para>
              </listitem>

              <listitem>
                <para>Vous essayez de vous connecter à une adresse IP
                secondaire sur votre firewall et votre règle ne redirige que
                l'adresse IP primaire (dans votre règle DNAT vous devez
                spécifier l'adresse IP secondaire dans la colonne <quote>ORIG.
                DEST.</quote>)</para>
              </listitem>

              <listitem>
                <para>Pour d'autres raisons, votre règle DNAT ne correspond
                pas à la requête de connexion. Dans ce cas, pour aller plus
                loin dans le diagnostic, vous pourrez avoir à vous servir d'un
                <quote>sniffer</quote> de paquets comme tcpdump ou
                ethereal.</para>
              </listitem>

              <listitem>
                <para>Si le nombre de paquets est différent de zéro, vérifiez
                dans votre log si la connexion est droppée ou rejetée. Si
                c'est le cas, il est possible que vous ayez un problème de
                définition de zone qui fasse que le serveur soit dans une zone
                différente de ce qui est spécifié dans la colonne DEST. A
                l'invite root, tapez "<command>shorewall[-lite] show
                zones</command>" et assurez-vous que vous avez bien spécifié
                dan la colonne DEST la <emphasis
                role="bold">première</emphasis> zone de la liste qui
                correspond à OUT=&lt;dev&gt; et DEST=&lt;ip&gt; dans le
                message REJECT/DROP de votre fichier log.</para>
              </listitem>
            </itemizedlist>
          </listitem>
        </itemizedlist>
      </section>

      <section id="faq1c">
        <title>(FAQ 1c) Je voudrais que lorsque je me connecte depuis internet
        au port 1022 de mon firewall, cette connexion soit redirigée vers le
        port 22 de mon système local 192.168.1.3. Comment faire ?</title>

        <para><emphasis role="bold">Réponse</emphasis>:Dans le fichier
        /<filename>etc/shorewall/rules</filename>:</para>

        <programlisting>#ACTION    SOURCE   DEST                PROTO    DEST PORT
DNAT       net      loc:192.168.1.3:22  tcp      1022</programlisting>
      </section>

      <section id="faq1d">
        <title>(FAQ 1d) J'ai un serveur web dans man DMZ et j'utilise le
        transfert de port pour rendre ce serveur accessible depuis internet.
        Cela fonctionne très bien sauf lorsque mes utilisateurs locaux
        essayent de se connecter au serveur en utilisant l'adresse IP externe
        du firewall.</title>

        <para><emphasis role="bold">Réponse</emphasis>: Supposons que:</para>

        <itemizedlist>
          <listitem>
            <para>L'adresse IP externe est 206.124.146.176 sur <filename
            class="devicefile">eth0</filename>.</para>
          </listitem>

          <listitem>
            <para>L'adresse IP du serveur est 192.168.2.4</para>
          </listitem>
        </itemizedlist>

        <para>Vous pouvez activer l'accès au serveur depuis votre réseau local
        en utilisant l'adresse IP externe du firewall. Pour cela, vous pouvez
        ajouter cette règle:</para>

        <programlisting>#ACTION    SOURCE   DEST                PROTO    DEST PORT(S)    SOURCE      ORIGINAL
#                                                                PORT        DEST                 
DNAT       loc      dmz:192.168.2.4     tcp      80              -           206.124.146.176</programlisting>

        <para>Si votre adresse IP externe est dynamique, vous devez faire
        comme suit:</para>

        <para>Dans <filename>/etc/shorewall/params</filename>:</para>

        <programlisting><command>ETH0_IP=`find_interface_address eth0`</command>       </programlisting>

        <para>Pour les utilisateurs de 2.1.0 et des versions
        ultérieures:</para>

        <programlisting><command>ETH0_IP=`find_first_interface_address eth0`</command></programlisting>

        <para>Et votre règle DNAT deviendra:</para>

        <programlisting>#ACTION    SOURCE        DEST               PROTO    DEST PORT   SOURCE    ORIGINAL
#                                                                PORT      DEST.
DNAT       loc           dmz:192.168.2.4    tcp      80          -         $ETH0_IP</programlisting>
      </section>

      <section id="faq1e">
        <title>(FAQ 1e) Dans le but de décourager les attaques en force brute,
        je voudrais rediriger toutes les connexions internet arrivant sur un
        port non standard (4104) vers le port 22 du firewall/routeur. J'ai
        remarqué que lorsque je paramètre une règle REDIRECT sur le firewall,
        il ouvre sur internet les deux ports 4104 et 22 . Est-il possible de
        rediriger seulement le port 4104 vers le port 22 de localhost et que
        toutes les tentatives de connexion depuis internet au port 22 soient
        ignorées ?</title>

        <para><emphasis role="bold">Réponse: </emphasis>avec l'aimable
        autorisation de Ryan: en supposant que l'adresse de l'interface locale
        de votre firewall soit 192.168.1.1, si vous configurez SSHD pour qu'il
        n'écoute que sur cette interface et que vous ajoutez la règle
        suivante, le port 4104 sera en écoute sur internet et le port 22 sera
        en écoute sur votre LAN.</para>

        <programlisting>#ACTION SOURCE  DEST                    PROTO   DEST PORT(S)
DNAT    net     fw:192.168.1.1:22       tcp     4104</programlisting>
      </section>
    </section>

    <section id="faq30">
      <title>(FAQ 30) Quand doit-on utiliser des règles DNAT et quand doit-on
      utiliser des règles ACCEPT ?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Je vous suggère de
      revenir au <ulink url="shorewall_quickstart_guide.htm">guides de
      démarrage rapide</ulink> adapté à votre configuration. Ces guides
      couvrent ce sujet sous un angle didactique. Vous devriez utiliser des
      règles DNAT pour les connexions qui doivent aller dans le sens inverse
      de celles en provenance de la SNAT/Masquerade. Ainsi, si vous utilisez
      la SNAT ou Masquerade depuis votre réseau local vers internet, vous
      aurez besoin d'utiliser des règles DNAT pour autoriser les connexions
      d'internet vers votre réseau local. Vous utiliserez également des règles
      DNAT si vous voulez ré-écrire l'adresse IP ou le numéro de port
      destination. Si vous avez besoin d'intercepter des connexions
      lorsqu'elles arrivent sur le firewall et que vous voulez les traiter sur
      le firewall lui-même, vous utiliserez une règle REDIRECT. Dans tous les
      autres cas, vous utiliserez ACCEPT.</para>
    </section>

    <section>
      <title>(FAQ 38) Où trouver plus d'information sur la DNAT?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Ian Allen a écrit cet
      article au sujet de la <ulink url="http://ian.idallen.ca/dnat.txt">DNAT
      et Linux</ulink>.</para>
    </section>

    <section id="faq48">
      <title>(FAQ 48) Comment configurer un proxy transparent avec
      Shorewall?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Vous pouvez voir <ulink
      url="Shorewall_Squid_Usage.html">Shorewall et Squid</ulink>.</para>
    </section>
  </section>

  <section>
    <title>DNS et Transfert de Port/Traduction d'Adresses Réseau NAT</title>

    <section id="faq2">
      <title>(FAQ 2) Je transfère (port forward) toutes les requêtes web
      soumises à www.mondomaine.com (IP 130.151.100.69) vers le système
      192.168.1.5 de mon réseau local. Les clients externes peuvent accéder à
      http://www.mondomaine.com mais les clients internes ne le peuvent
      pas.</title>

      <para><emphasis role="bold">Réponse:</emphasis> j'ai deux objections à
      cette configuration.</para>

      <itemizedlist>
        <listitem>
          <para>Avoir un serveur sur votre réseau local accessible depuis
          internet est comme élever des loups à coté de votre poulailler. Si
          le serveur est compromis, il n'y a rien entre ce serveur et vos
          autres systèmes locaux. Pour le prix d'un adaptateur ethernet et
          d'un câble croisé, vous pouvez mettre votre serveur en DMZ de telle
          façon qu'il soit isolé de vos systèmes locaux - en supposant que le
          serveur puisse être installé à coté de votre firewall, bien entendu
          :-)</para>
        </listitem>

        <listitem>
          <para>La meilleure solutions pour l'accessibilité à votre serveur
          est d'utiliser les <quote>vues</quote> de <ulink
          url="shorewall_setup_guide_fr.htm#DNS">Bind Version 9</ulink> (ou
          bien d'utiliser un serveur DNS séparé pour les clients locaux) afin
          que www.mondomaine.com soit résolu en 130.141.100.69 pour les
          clients externes et en 192.168.1.5 pour les clients internes. C'est
          ce que je fait ici à shorewall.net pour mes systèmes locaux qui
          utilisent la NAT un-à-un (one-to-one NAT).</para>
        </listitem>
      </itemizedlist>

      <para>Supposons que votre interface externe soit eth0, que votre
      interface interne soit eth1 et que eth1 ait l'adresse 192.168.1.254 sur
      le sous-réseau 192.168.1.0/24:<warning>
          <para>tout le trafic redirigé par cette bidouille sera vu par le
          serveur comme provenant du firewall (192.168.1.254) au lieu de venir
          du client d'origine! Ce qui fait que les logs d'accès du serveur
          seront inutilisables pour déterminer quels hôtes locaux accèdent au
          serveur.</para>
        </warning></para>

      <itemizedlist>
        <listitem>
          <para>Dans <filename>/etc/shorewall/interfaces</filename>:</para>

          <programlisting>#ZONE    INTERFACE    BROADCAST    OPTIONS
loc      eth1         detect       <emphasis role="bold">routeback</emphasis>    </programlisting>
        </listitem>

        <listitem>
          <para>Dans <filename>/etc/shorewall/masq</filename>:</para>

          <programlisting>#INTERFACE              SUBNET          ADDRESS         PROTO   PORT(S)
eth1:192.168.1.5        eth1            192.168.1.254   tcp     www</programlisting>
        </listitem>

        <listitem>
          <para>Dans <filename>/etc/shorewall/rules</filename>:</para>

          <programlisting>#ACTION    SOURCE       DEST               PROTO    DEST PORT   SOURCE    ORIGINAL
#                                                               PORT      DEST.
DNAT       loc          loc:192.168.1.5    tcp      www         -         130.151.100.69</programlisting>

          <para>Bien entendu, cette règle ne fonctionnera que si vous avez une
          adresse IP externe statique. Si vous avez une adresse dynamique vous
          devez inclure ceci dans
          <filename>/etc/shorewall/param</filename>s:</para>

          <programlisting><command>ETH0_IP=`find_first_interface_address eth0`</command>        </programlisting>

          <para>et votre règle DNAT deviendra:</para>

          <programlisting>#ACTION    SOURCE        DEST               PROTO    DEST PORT   SOURCE    ORIGINAL
#                                                                PORT      DEST.
DNAT       loc           loc:192.168.1.5    tcp      www         -         $ETH0_IP</programlisting>

          <para>Lorsque vous utilisez cette technique, il vous faudra
          configurer votre client DHCP/PPPoE de façon à ce qu'il relance
          shorewall chaque fois qu'il obtient une nouvelle adresse IP.</para>
        </listitem>
      </itemizedlist>

      <section id="faq2a">
        <title>(FAQ 2a) J'ai une zone <quote>Z</quote> avec un sous-réseau RFC
        1918 et j'utilise la NAT un-à-un (one-to-one NAT) pour assigner des
        adresses non-RFC1918 aux hôtes de la zone <quote>Z</quote>. Les hôtes
        dans la zone <quote>Z</quote> ne peuvent pas communiquer entre eux en
        utilisant leur adresse externe (adresses non-FRC1918) et donc ils ne
        peuvent pas communiquer en utilisant leurs noms DNS.</title>

        <note>
          <para>Si la colonne ALL INTERFACES dans le fichier
          /etc/shorewall/nat est vide ou contient <quote>Yes</quote>, vous
          verrez aussi dans votre journal des messages comme celui-ci à chaque
          fois que vous tenterez d'accéder à un hôte de la zone Z depuis un
          autre hôte de la zone Z en utilisant son adresse publique:</para>

          <programlisting>Oct 4 10:26:40 netgw kernel:
          Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=192.168.118.200
          DST=192.168.118.210 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1342 DF
          PROTO=TCP SPT=1494 DPT=1491 WINDOW=17472 RES=0x00 ACK SYN URGP=0</programlisting>
        </note>

        <para><emphasis role="bold">Réponse:</emphasis> C'est encore un
        problème très bien résolu par l'utilisation des <quote>vues</quote> de
        <ulink url="shorewall_setup_guide_fr.htm#DNS">Bind Version 9</ulink>.
        Les clients internes comme les clients externes peuvent alors accéder
        aux hôtes <quote>NATés</quote> en utilisant leur nom réseau.</para>

        <para>Une autre bonne façon d'approcher le problème est d'abandonner
        la NAT un-à-un au profit du Proxy ARP. De cette façon, les machines
        dans Z ont des adresses non-RFC1918 et on peut y accéder aussi bien
        depuis l'intérieur que depuis l'extérieur en utilisant la même
        adresse.</para>

        <para>Si vous n'aimez pas ces solutions et que vous préférez bêtement
        router tout le trafic de Z vers Z par votre firewall:</para>

        <orderedlist>
          <listitem>
            <para>Activez l'option routeback sur l'interface vers Z.</para>
          </listitem>

          <listitem>
            <para>Mettez <quote>Yes</quote> dans la colonne ALL INTERFACES du
            fichier nat.</para>
          </listitem>
        </orderedlist>

        <example>
          <title>Exemple:</title>

          <literallayout>Zone: dmz Interface: eth2 Ssous-réseau: 192.168.2.0/24 Addresse: 192.168.2.254</literallayout>

          <para>Dans le fichier
          <filename>/etc/shorewall/interfaces</filename>:</para>

          <programlisting>#ZONE    INTERFACE    BROADCAST       OPTIONS
dmz      eth2         192.168.2.255   <emphasis role="bold">routeback</emphasis> </programlisting>

          <para>Dans le fichier <filename>/etc/shorewall/na</filename>t,
          assurez-vous d'avoir <quote>Yes</quote> dans la colonne ALL
          INTERFACES.</para>

          <para>Dans le fichier
          <filename>/etc/shorewall/masq</filename>:</para>

          <programlisting>#INTERFACE    SUBNETS     ADDRESS
eth2          eth2        192.168.2.254</programlisting>

          <para>Tout comme dans la bidouille présentée dans la FAQ2 ci-dessus,
          le trafic de la dmz vers la dmz semblera provenir du firewall et non
          du véritable hôte source.</para>
        </example>
      </section>

      <section id="faq2b">
        <title>(FAQ 2b) J'ai un serveur web dans ma DMZ et je me sers du
        transfert de port pour le rendre accessible sur internet en tant que
        www.mondomaine.com. Cela marche très bien sauf pour mes utilisateurs
        locaux lorsqu'ils tentent de se connecter à
        www.mondomaine.com.</title>

        <para><emphasis role="bold">Réponse</emphasis>: Supposons que:</para>

        <itemizedlist>
          <listitem>
            <para>L'adresse externe IP soit 206.124.146.176 sur <filename
            class="devicefile">eth0</filename> (www.mondomaine.com).</para>
          </listitem>

          <listitem>
            <para>L'adresse IP du serveur soit 192.168.2.4</para>
          </listitem>
        </itemizedlist>

        <para>Vous pouvez autoriser les machines du réseau local à accéder à
        votre serveur en utilisant l'adresse IP externe du firewall. Il suffit
        d'ajouter cette règle:</para>

        <programlisting>#ACTION    SOURCE   DEST                PROTO    DEST PORT(S)    SOURCE      ORIGINAL
#                                                                PORT        DEST                 
DNAT       loc      dmz:192.168.2.4     tcp      80              -           206.124.146.176</programlisting>

        <para>Si votre adresse IP externe vous est allouée dynamiquement, vous
        devez faire comme suit:</para>

        <para>Dans le fichier
        <filename>/etc/shorewall/params</filename>:</para>

        <programlisting><command>ETH0_IP=`find_first_interface_address eth0`</command>  </programlisting>

        <para>Et votre règle DNAT deviendra:</para>

        <programlisting>#ACTION    SOURCE        DEST               PROTO    DEST PORT   SOURCE    ORIGINAL
#                                                                PORT      DEST.
DNAT       loc           dmz:192.168.2.4    tcp      80          -         $ETH0_IP</programlisting>

        <warning>
          <para>Avec des adresses IP dynamiques, vous n'utiliserez pas
          <command>shorewall[-lite] save</command> ni
          <command>shorewall[-lite] restore</command>.</para>
        </warning>
      </section>

      <section id="faq2c">
        <title>(FAQ 2c) J'ai essayé d'appliquer la réponse à la FAQ 2 à mon
        interface externe et à la zone net. Cela ne marche pas. Pourquoi
        ?</title>

        <para><emphasis role="bold">Réponse</emphasis>: Avez-vous activé
        <emphasis role="bold">IP_FORWARDING=On</emphasis> dans
        <filename>shorewall.conf</filename>?</para>
      </section>
    </section>
  </section>

  <section>
    <title>Netmeeting/MSN</title>

    <section id="faq3">
      <title>(FAQ 3) Je veux utiliser Netmeeting ou la messagerie instantanée
      MSN avec Shorewall. Que faire ?</title>

      <para><emphasis role="bold">Réponse:</emphasis> Il existe un <ulink
      url="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/">module de
      suivi de connexion H.323</ulink> qui est d'un grand secours avec
      Netmeeting. Prenez cependant en compte cet article récent d'un des
      développeurs de Netfilter:</para>

      <blockquote>
        <para><programlisting>&gt; Je sais que PoM -ng va traiter ce problème, mais en attendant qu'il soit prêt,
&gt; et que tous les extras y soient portés, existe-t-il un moyen d'utiliser le patch
&gt; noyau pour le module de suivi de connexion H.323 avec un noyau 2.6 ?
&gt; j'utilise un noyau 2.6.1 et le noyau 2.4 n'est pas installé sur le système, c'est 
&gt; pourquoi je ne peux pas envisager de revenir en 2.4 ... et le module n'a pas
&gt; encore été porté en 2.6, dommage.
&gt; Quelles options ai-je à part d'installer une application gatekeeper (qui ne 
&gt; fonctionne pas dans mon réseau) ou un proxy (ce que je préférerais éviter) ?

Je suggère à tous de configurer un proxy (gatekeeper): le module est vraiment 
nul et ne mérite pas d'exister. Ça a été un très bon outil de développement et
de deboguage de l'interface newnat.</programlisting></para>
      </blockquote>

      <para>Vous pouvez aller voir <ulink url="UPnP.html">ici</ulink> une
      solution pour la messagerie instantanée MSN. Vous devez avoir conscience
      que cette solution comporte des risques de sécurité significatifs. Vous
      pouvez également vérifier auprès de la liste de diffusion de Netfilter à
      <ulink
      url="http://www.netfilter.org">http://www.netfilter.org</ulink>.</para>
    </section>
  </section>

  <section>
    <title>Ports ouverts</title>

    <section id="faq51">
      <title>(FAQ 51) Comment ouvrir des ports dans Shorewall?</title>

      <para><emphasis role="bold">Réponse:</emphasis> Aucune personne ayant
      installé Shorewall en utilisant un des <ulink
      url="shorewall_quickstart_guide.htm">Guides de Démarrage Rapide</ulink>
      ne devrait avoir à poser cette question.</para>

      <para>Quel que soit le guide que vous avez utilisé, toutes les
      communications sortantes sont ouvertes par défaut. Vous n'avez donc pas
      à "ouvrir de port" en sortie.</para>

      <para>En entrée:</para>

      <itemizedlist>
        <listitem>
          <para>Si vous avez installé en utilisant le guide Firewall Monoposte
          (une interface), <ulink url="standalone_fr.htm#Open">relisez cette
          section SVP</ulink>.</para>
        </listitem>

        <listitem>
          <para>Si vous avez utilisé le guide Firewall à deux interfaces pour
          installer merci de relire ces sections: <ulink
          url="two-interface_fr.htm#DNAT">Transfert de ports (DNAT)</ulink>,
          et <ulink url="two-interface_fr.htm#Open">Autres
          connexions</ulink></para>
        </listitem>

        <listitem>
          <para>Si vous avez utilisé le guide Firewall à trois interfaces pour
          installer merci de relire ces sections: <ulink
          url="three-interface.htm#DNAT">Transfert de ports (DNAT)</ulink> et
          <ulink url="three-interface.htm#Open">Autres
          Connexions</ulink></para>
        </listitem>

        <listitem>
          <para>Si vous avez installé en utilisant le <ulink
          url="shorewall_setup_guide_fr.htm">Guide de configuration
          Shorewall</ulink> vous feriez mieux de lire le guide à nouveau --
          vous avez vraiment raté beaucoup de choses.</para>
        </listitem>
      </itemizedlist>

      <para>Voyez également la <link linkend="PortForwarding">section
      Transfert de Ports de cette FAQ</link>.</para>
    </section>

    <section id="faq4">
      <title>(FAQ 4) Je viens juste d'utiliser un scanner de port en ligne
      pour vérifier le paramètrage de mon firewall et certains ports
      apparaissent <quote>fermés</quote> (closed) alors que d'autres sont
      <quote>bloqués</quote> (blocked). Pourquoi ?</title>

      <para><emphasis role="bold">Réponse:</emphasis> La configuration par
      défaut de Shorewall invoque l'action <emphasis
      role="bold">Drop</emphasis> avant de mettre en oeuvre une politique
      DROP, et la politique par défaut d'internet vers toutes les zones est
      DROP. L'action Drop est définie dans le fichier
      <filename>/usr/share/shorewall/action.Drop</filename> qui invoque
      lui-même la macro <emphasis role="bold">Auth</emphasis> (définie dans le
      fichier <filename>/usr/share/shorewall/macro.Auth</filename>) qui
      spécifie l'action <emphasis role="bold">REJECT</emphasis> (c.a.d.,
      <emphasis role="bold">Auth/REJECT</emphasis>). Cela est nécessaire pour
      éviter les problèmes de connexion sortante à des services qui utilisent
      le mécanisme <quote>Auth</quote> pour identifier les utilisateurs. C'est
      le seul service configuré par défaut pour rejeter (REJECT) les
      paquets.</para>

      <para>Si vous voyez d'autres ports TCP fermés autres que le port 113
      (auth) c'est que vous avez ajouté des règles REJECT pour ces ports ou
      bien qu'un routeur à l'extérieur de votre firewall répond aux requêtes
      de connexion sur ce port.</para>

      <section id="faq4a">
        <title>(FAQ 4a) Je viens d'exécuter un scan UDP de mon firewall avec
        nmap et il trouve des centaines de ports ouverts!!!!</title>

        <para><emphasis role="bold">Réponse:</emphasis> Respirez à fond et
        lisez la section man de nmap au sujet des scans UDP. Si nmap n'a
        <emphasis role="bold">aucun</emphasis> retour de votre firewall, il
        donnera ce port comme étant ouvert. Si vous voulez voir quels sont les
        ports UDP réellement ouverts, modifiez temporairement votre politique
        net-&gt;all pour REJECT, relancez Shorewall et refaites le scan UDP
        nmap.</para>
      </section>

      <section id="faq4b">
        <title>(FAQ 4b) Quoi que je change dans mes règles, Il y a un port que
        je n'arrive pas à fermer.</title>

        <para>J'avais une règle qui autorisait telnet de mon réseau local vers
        mon firewall. Je l'ai enlevée et j'ai relancé Shorewall mais ma
        session telnet fonctionne encore!!!</para>

        <para><emphasis role="bold">Réponse:</emphasis> Les règles traitent de
        l'établissement de nouvelles connexions. Lorsqu'une connexion est
        établie par le firewall, elle restera utilisable jusqu'à la
        déconnexion tcp ou jusqu'au time out pour les autres protocoles. Si
        vous fermez votre session telnet et que vous essayez d'établir un
        nouvelle session, votre firewall bloquera cette tentative.</para>
      </section>

      <section id="faq4c">
        <title>(FAQ 4c) Comment utiliser Shorewall avec PortSentry?</title>

        <para><ulink
        url="http://www.shorewall.net/pub/shorewall/contrib/PortsentryHOWTO.txt"><emphasis
        role="bold">Answer:</emphasis> Vous trouverez ici la
        description</ulink> d'une bonne intégration de Shorewall et
        PortSentry.</para>
      </section>
    </section>

    <section>
      <title>(FAQ 4d) Comment utiliser Shorewall avec Snort-Inline?</title>

      <para><emphasis role="bold">Réponse:</emphasis> <ulink
      url="http://www.catherders.com/tiki-view_blog_post.php?blogId=1&amp;postId=71">Allez
      voir cette contribution</ulink> de Michael Cooke.</para>
    </section>
  </section>

  <section>
    <title>Problèmes de connexion</title>

    <section id="faq5">
      <title>(FAQ 5) J'ai installé Shorewall et je ne peux plus
      <quote>pinger</quote> à travers le firewall</title>

      <para><emphasis role="bold">Réponse:</emphasis> Pour une description
      complète de la gestion du <quote>ping</quote> par Shorewall, voyez
      <ulink url="ping.html">cette page</ulink>.</para>
    </section>

    <section id="faq15">
      <title>(FAQ 15) Mes systèmes locaux ne peuvent rien voir sur
      internet</title>

      <para><emphasis role="bold">Réponse:</emphasis> Chaque fois que je lis
      <quote>mes systèmes ne peuvent rien voir sur internet</quote>, je me
      demande où l'auteur a bien pu acheter des ordinateurs avec des yeux et
      ce que ces ordinateurs peuvent bien <quote>voir</quote> lorsque tout
      fonctionne convenablement. Ceci mis à part, les causes habituelles à ce
      type de problèmes sont:</para>

      <orderedlist>
        <listitem>
          <para>L'adresse de la passerelle par défaut n'est pas configurée à
          l'adresse de l'interface locale du firewall sur chacun des systèmes
          locaux.</para>
        </listitem>

        <listitem>
          <para>L'entré pour le réseau local dans le fichier
          <filename>/etc/shorewall/masq</filename> est erronée ou
          manquante.</para>
        </listitem>

        <listitem>
          <para>La configuration du DNS sur les systèmes locaux est mauvaise
          ou bien l'utilisateur fait tourner un serveur DNS sur le firewall et
          il n'a pas autorisé le port 53 UDP et TCP de son firewall vers
          internet.</para>
        </listitem>

        <listitem>
          <para>Le forwarding n'est pas activé (ceci est souvent le cas pour
          les utilisateurs Debian). Exécutez cette commande:</para>

          <programlisting>cat /proc/sys/net/ipv4/ip_forward</programlisting>

          <para>Si la valeur est 0 (zéro) mettez <emphasis
          role="bold">IP_FORWARDING=On</emphasis> dans le fichier
          <filename>/etc/shorewall/shorewall.conf</filename> et relancez
          Shorewall.</para>
        </listitem>
      </orderedlist>
    </section>

    <section id="faq29">
      <title>(FAQ 29) FTP ne fonctionne pas</title>

      <para><emphasis role="bold">Réponse</emphasis>: Voir la page <ulink
      url="FTP.html">Shorewall et FTP</ulink>.</para>
    </section>

    <section id="faq33">
      <title>(FAQ 33) Depuis mes clients derrière le firewall les connexions
      vers certains sites échouent. Les connexions vers les mêmes sites, mais
      depuis le firewall fonctionnent. Qu'est-ce qui ne va pas ?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Très probablement, il
      vous faudra mettre CLAMPMSS=Yes dans le fichier <ulink
      url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>.</para>
    </section>

    <section id="faq35">
      <title>(FAQ 35) J'ai deux interfaces ethernet vers mon réseau local que
      j'ai montées en pont (bridge). Quand Shorewall est démarré, je n'arrive
      pas à faire passer le trafic à travers le pont. J'ai défini l'interface
      pont (br0) comme interface locale dans /etc/shorewall/interfaces. Les
      interfaces ethernet <quote>pontées</quote> ne sont pas définies pour
      Shorewall. Comment demander à Shorewall d'autoriser le trafic à travers
      le pont ?</title>

      <para><emphasis role="bold">Réponse</emphasis>: ajouter l'option
      <firstterm>routeback</firstterm> à l'interface <filename
      class="devicefile">br0</filename> dans le fichier <ulink
      url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink>.</para>

      <para>Pour plus d'information sur ce type de configuration, voir la
      documentation pour <ulink url="SimpleBridge.html">un pont simple avec
      Shorewall</ulink>.</para>
    </section>
  </section>

  <section>
    <title>Journalisation</title>

    <section id="faq6">
      <title>(FAQ 6) Où sont enregistrés les messages de journalisation et
      comment modifier leur destination ?</title>

      <para><emphasis role="bold">Réponse:</emphasis> NetFilter utilise
      l'équivalent noyau de syslog (voir <quote>man syslog</quote>) pour
      journaliser les messages. Il utilise toujours le dispositif LOG_KERN
      (voir <quote>man openlog</quote>) et vous devez choisir le niveau de
      journalisation (log level, voir <quote>man syslog</quote>) dans vos
      <ulink url="Documentation.htm#Policy">politiques</ulink> et dans vos
      <ulink url="Documentation.htm#Rules">règles</ulink>. La destination des
      messages journalisés par syslog est contrôlée avec
      <filename>/etc/syslog.conf</filename> (voir <quote>man
      syslog.conf</quote>). Lorsque vous avez modifié
      <filename>/etc/syslog.conf</filename>, assurez-vous de redémarrer
      syslogd (sur un système RedHat, <quote>service syslog
      restart</quote>).</para>

      <para>Par défaut, les versions plus anciennes de Shorewall limitaient le
      taux de journalisation des messages grâce à des <ulink
      url="Documentation.htm#Conf">paramètres</ulink> du fichier
      <filename>/etc/shorewall/shorewall.conf</filename> -- Si vous voulez
      journaliser tous les messages, positionnez ces paramètres comme
      suit:</para>

      <programlisting>LOGLIMIT=""
LOGBURST=""</programlisting>

      <para>On peut également <ulink url="shorewall_logging.html">paramétrer
      Shorewall pour qu'il enregistre les messages de journalisation dans un
      fichier séparé</ulink>.</para>

      <section id="faq6a">
        <title>(FAQ 6a) Existe-t-il des analyseur de journal qui fonctionnent
        avec Shorewall?</title>

        <para><emphasis role="bold">Réponse:</emphasis> Voilà plusieurs liens
        qui peuvent vous aider:</para>

        <literallayout>
          <ulink url="http://www.shorewall.net/pub/shorewall/parsefw/">http://www.shorewall.net/pub/shorewall/parsefw/</ulink>
          <ulink url="http://www.fireparse.com">http://www.fireparse.com</ulink>
          <ulink url="http://cert.uni-stuttgart.de/projects/fwlogwatch">http://cert.uni-stuttgart.de/projects/fwlogwatch</ulink>
          <ulink url="http://www.logwatch.org">http://www.logwatch.org</ulink>
          <ulink url="http://gege.org/iptables">http://gege.org/iptables</ulink>
          <ulink url="http://home.regit.org/ulogd-php.html">http://home.regit.org/ulogd-php.html</ulink>
        </literallayout>

        <para>Personnellement, j'utilise Logwatch. Il m'envoie chaque jour par
        courriel un rapport pour chacun de mes différents systèmes. Chaque
        rapport résume l'activité journalisée sur le système
        correspondant.</para>
      </section>

      <section id="faq6b">
        <title>(FAQ 6b) Mes journaux sont inondés de messages DROP pour des
        requêtes de connections sur le port 10619. Puis-je exclure
        temporairement de la journalisation Shorewall les messages d'erreur
        pour ce port ?</title>

        <para><emphasis role="bold">Réponse</emphasis>: Ajoutez temporairement
        la règle suivante:</para>

        <programlisting>#ACTION   SOURCE    DEST    PROTO    DEST PORT(S)
DROP      net       fw      udp      10619</programlisting>

        <para>Sinon, si vous ne mettez pas le paramètre BLACKLIST_LOGLEVEL et
        que vous avez spécifié l'option 'blacklist' sur votre interface
        externe dans le fichier
        <filename>/etc/shorewall/interfaces</filename>, vous pouvez
        blacklister le port. Dans le fichier
        <filename>/etc/shorewall/blacklist</filename>:</para>

        <programlisting>#ADDRESS/SUBNET         PROTOCOL        PORT
-                       udp             10619</programlisting>
      </section>

      <section id="faq6d">
        <title>(FAQ 6d) Pourquoi l'adresse MAC dans les messages de
        journalisation Shorewall est-elle si longue ? Je pensais que l'adresse
        MAC ne faisait que 6 octets.</title>

        <para><emphasis role="bold">Réponse</emphasis>: Ce qui est labelisé
        comme adresse MAC dans les messages de journalisation Shorewall est en
        fait l'entête de la trame ethernet. Elle contient:</para>

        <itemizedlist>
          <listitem>
            <para>l'adresse MAC de destination (6 octets)</para>
          </listitem>

          <listitem>
            <para>l'adresse MAC source (6 octets)</para>
          </listitem>

          <listitem>
            <para>le type de trame ethernet (2 octets)</para>
          </listitem>
        </itemizedlist>

        <para><example>
            <title>Exemple</title>

            <para><programlisting>MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00</programlisting>
            <itemizedlist>
                <listitem>
                  <para>adresse MAC de destination = 00:04:4c:dc:e2:28</para>
                </listitem>

                <listitem>
                  <para>adresse MAC source = 00:b0:8e:cf:3c:4c</para>
                </listitem>

                <listitem>
                  <para>type de trame ethernet = 08:00 (IP Version 4)</para>
                </listitem>
              </itemizedlist></para>
          </example></para>
      </section>
    </section>

    <section id="faq16">
      <title>(FAQ 16) Shorewall écrit ses messages de journalisation
      directement sur ma console et la rend inutilisable!</title>

      <para><emphasis role="bold">Réponse:</emphasis></para>

      <itemizedlist>
        <listitem>
          <para>Trouvez où klogd est démarré (ce sera depuis un des fichiers
          du répertoire <filename class="directory">/etc/init.d</filename> --
          sysklogd, klogd, ...). Modifiez ce fichier ou le fichier de
          configuration approprié de telle manière que klogd soit démarré avec
          <quote>-c <emphasis>&lt;n&gt;</emphasis> </quote> avec
          <emphasis>&lt;n&gt;</emphasis> étant un niveau de journalisation
          inférieur ou égal à 5; ou alors</para>
        </listitem>

        <listitem>
          <para>Voir la page man de <quote>dmesg</quote> (<quote>man
          dmesg</quote>). Vous devez ajouter une commande <quote>dmesg</quote>
          adaptée dans vos scripts de démarrage ou la placer dans le fichier
          <filename>/etc/shorewall/start</filename>.</para>
        </listitem>
      </itemizedlist>

      <tip>
        <para>Sous RedHat et Mandriva, le <ulink
        url="shorewall_logging.html">niveau de journalisation</ulink> maximum
        envoyé à la console est spécifié par la variable LOGLEVEL du fichier
        <filename>/etc/sysconfig/init</filename>. Positionnez
        <quote>LOGLEVEL=5</quote> pour éliminer de la console les messages de
        niveau info.</para>
      </tip>

      <tip>
        <para>Sous Debian, vous pouvez mettre KLOGD=<quote>-c 5</quote> dans
        le fichier <filename>/etc/init.d/klogd</filename> afin d'éliminer de
        la console les messages de niveau info (log level 6).</para>
      </tip>

      <tip>
        <para>Sous SUSE, ajoutez <quote>-c 5</quote> à KLOGD_PARAMS dans le
        fichier <filename>/etc/sysconfig/syslog</filename> fin d'éliminer de
        la console les messages de niveau info (log level 6).</para>
      </tip>
    </section>

    <section id="faq17">
      <title>(FAQ 17) Pourquoi ces paquets sont-ils ignorés/rejetés
      (dropped/rejected)? Comment décode-t-on les messages de journalisation
      Shorewall?</title>

      <para><emphasis role="bold">Réponse:</emphasis> Avec Shorewall, les
      paquets ignorés/rejetés peuvent avoir été journalisés en sortie d'un
      certain nombre de chaînes (comme indiqué dans le message):</para>

      <variablelist>
        <varlistentry>
          <term>man1918 or logdrop</term>

          <listitem>
            <para>L'adresse destination est listée dans le fichier
            <filename>/usr/share/shorewall/rfc1918</filename> avec une cible
            <emphasis role="bold">logdrop</emphasis> -- voir <filename> <ulink
            url="Documentation.htm#rfc1918">/usr/share/shorewall/rfc1918</ulink></filename>.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>rfc1918 or logdrop</term>

          <listitem>
            <para>L'adresse source ou destination est listée dans le fichier
            <filename>/usr/share/shorewall/rfc1918</filename> avec un cible
            <emphasis role="bold">logdrop</emphasis> -- voir <filename> <ulink
            url="Documentation.htm#rfc1918">/usr/share/shorewall/rfc1918</ulink></filename>.</para>

            <note>
              <para>Si vous voyez des paquets rejetés par la chaîne rfc1918 et
              que ni l'adresse IP source ni l'adresse IP de destination ne
              sont réservées par la RFC 1918, cela provient la plupart du
              temps d'un ancien fichier <filename>rfc1918</filename> dans
              <filename class="directory">/etc/shorewall</filename> (ceci
              arrive le plus fréquemment lorsque vous utilisez une Debian ou
              un de ses dérivés). Le fichier <filename>rfc1918</filename>
              incluait aussi bien les <emphasis>bogons</emphasis> que les
              trois plages réservées par la RFC 1918. Il était installé dans
              le répertoire <filename
              class="directory">/etc/shorewall</filename>. Maintenant le
              fichier ne contient que les trois plages d'adresse de la RFC
              1918 et il est installé dans le répertoire <filename
              class="directory">/usr/share/shorewall</filename>. Retirez le
              fichier rfc1918 périmé de votre répertoire <filename
              class="directory">/etc/shorewall</filename>.</para>
            </note>
          </listitem>
        </varlistentry>

        <varlistentry id="all2all">
          <term>all2&lt;zone&gt;, &lt;zone&gt;2all or all2all</term>

          <listitem>
            <para>Vous avez une <ulink
            url="Documentation.htm#Policy">politique</ulink> qui spécifie un
            niveau de journalisation et ce paquet a été journalisé par cette
            politique. Si vous voulez autoriser (ACCEPT) ce trafic, il vous
            faudra une <ulink url="Documentation.htm#Rules">règle</ulink> à
            cette fin.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>&lt;zone1&gt;2&lt;zone2&gt;</term>

          <listitem>
            <para>Ou bien vous avez une <ulink
            url="Documentation.htm#Policy">politique</ulink> pour le trafic de
            la <emphasis role="bold">&lt;zone1&gt;</emphasis> vers la
            <emphasis role="bold">&lt;zone2&gt;</emphasis> qui spécifie un
            niveau de journalisation et ce paquet a été journalisé par cette
            politique ou alors ce paquet correspond à une <ulink
            url="Documentation.htm#Rules">règle</ulink> incluant un niveau de
            journalisation.</para>

            <para>A partir de Shorewall 3.3.3, les paquets loggés par ces
            chaines peuvent avoir une source et/ou une destination
            n'appartenant à aucune zone définie (voir le résultat de la
            commande <command>shorewall[-lite] show zones</command>).
            Souvenez-vous que l'appartenance à une zone nécessite à la fois
            une interface du firewall et une adresse ip.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>@&lt;source&gt;2&lt;dest&gt;</term>

          <listitem>
            <para>Vous avez une politique pour le trafic de &lt;<emphasis
            role="bold">source</emphasis>&gt; vers &lt;<emphasis
            role="bold">dest</emphasis>&gt; dans laquelle vous avez spécifié
            un taux de limitation des connexions TCP (les valeurs dans la
            colonne LIMIT:BURST). Les paquet journalisé dépassait cette limite
            et a été ignoré (DROP). Il faut noter que ces messages au journal
            sont eux-même sévèrement limités afin qu'une inondation SYN
            (syn-flood) ne provoque pas un déni de service (DOS) secondaire
            par un nombre excessif de messages de journalisation. Ces messages
            ont été introduits dans Shorewall 2.2.0 Beta 7.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>&lt;interface&gt;_mac</term>

          <listitem>
            <para>Ce paquet a été journalisé par l'<ulink
            url="Documentation.htm#Interfaces">option d'interface</ulink>
            <emphasis role="bold">maclist</emphasis> .</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>logpkt</term>

          <listitem>
            <para>Ce paquet a été journalisé par l'<ulink
            url="Documentation.htm#Interfaces">option d'interface</ulink>
            <emphasis role="bold">logunclean</emphasis>.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>badpkt</term>

          <listitem>
            <para>Ce paquet a été journalisé par l'<ulink
            url="Documentation.htm#Interfaces">option d'interface</ulink>
            <emphasis role="bold">dropunclean</emphasis> tel que spécifié dans
            le paramètre <emphasis role="bold">LOGUNCLEAN</emphasis> du
            fichier <ulink url="Documentation.htm#Conf">
            <filename>/etc/shorewall/shorewall.conf</filename>
            </ulink>.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>blacklst</term>

          <listitem>
            <para>Ce paquet a été journalisé parce que l'adresse IP source est
            inscrite dans la liste noire <filename><ulink
            url="Documentation.htm#Blacklist">/etc/shorewall/blacklist</ulink></filename>.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>INPUT or FORWARD</term>

          <listitem>
            <para>Ce paquet a une adresse IP source qui n'est définie dans
            aucune de vos zones (<quote><command>shorewall[-lite] show
            zones</command></quote> et regardez les définitions de zones) ou
            alors la chaîne est FORWARD et l'adresse IP de destination ne
            figure dans aucune de vos zones définies. Si la chaîne est FORWARD
            et les interfaces IN et OUT sont identiques, vous avez sans doute
            besoin de l'option <emphasis role="bold">routeback</emphasis> sur
            cette interface dans le fichier <filename><ulink
            url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink></filename>
            ou bien vous avez besoin de l'option <emphasis
            role="bold">routeback</emphasis> pour l'entrée adéquate dans le
            fichier<filename> <ulink
            url="Documentation.htm#Hosts">/etc/shorewall/hosts</ulink>
            </filename>.</para>

            <para>A partir de 3.3.3, de tels paquets peuvent aussi être loggés
            par les chaines &lt;zone&gt;2all et all2all.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>OUTPUT</term>

          <listitem>
            <para>Ce paquet a une adresse IP destination qui n'est définie
            dans aucune de vos zones (<quote>shorewall check</quote> et
            regardez les définitions de zones).</para>

            <para>A partir Shorewall 3.3.3, de tels paquets peuvent aussi être
            loggés par les chaines fw2all et all2all.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>logflags</term>

          <listitem>
            <para>Ce paquet a été journalisé parce qu'il a échoué aux
            contrôles mis en oeuvre par l'<ulink
            url="Documentation.htm#Interfaces">option d'interface</ulink>
            <emphasis role="bold">tcpflags</emphasis>.</para>
          </listitem>
        </varlistentry>
      </variablelist>

      <example>
        <title>Exemple:</title>

        <programlisting>Jun 27 15:37:56 gateway kernel:
        Shorewall:<emphasis role="bold">all2all:REJECT</emphasis>:<emphasis
            role="bold">IN=eth2</emphasis>
          <emphasis role="bold">OUT=eth1</emphasis>
          <emphasis role="bold">SRC=192.168.2.2</emphasis>
          <emphasis role="bold">DST=192.168.1.3 </emphasis>LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF <emphasis
            role="bold">PROTO=UDP</emphasis>
        SPT=1803 <emphasis role="bold">DPT=53</emphasis> LEN=47</programlisting>

        <para>Examinons les partie importantes de ce message:</para>

        <variablelist>
          <varlistentry>
            <term>all2all:REJECT</term>

            <listitem>
              <para>Ce paquet a été rejeté (REJECT) par la chaîne <emphasis
              role="bold">all2all</emphasis> -- le paquet a été rejeté par la
              politique <quote>all</quote>-&gt;<quote>all</quote> REJECT (voir
              <link linkend="all2all">all2all</link> ci-dessus).</para>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>IN=eth2</term>

            <listitem>
              <para>Le paquet est arrivé dans le firewall par eth2. Lorsque
              vous voyez <quote>IN=</quote> sans aucun nom d'interface, c'est
              que le paquet provient du firewall lui-même.</para>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>OUT=eth1</term>

            <listitem>
              <para>Si il avait été autorisé, ce paquet aurait été transmis à
              eth1. Lorsque vous voyez <quote>OUT=</quote> sans aucun nom
              d'interface, c'est que le paquet aurait été traité par le
              firewall lui-même.</para>

              <note>
                <para>Lorsqu'une règle DNAT est journalisée, on n'a jamais de
                OUT= parce que le paquet est journalisé avant d'être routé.
                Par ailleurs, la journalisation DNAT donnera l'adresse IP
                destination et le numéro de port destination
                d'<emphasis>origine</emphasis>.</para>
              </note>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>SRC=192.168.2.2</term>

            <listitem>
              <para>Ce paquet a été envoyé par 192.168.2.2</para>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>DST=192.168.1.3</term>

            <listitem>
              <para>Ce paquet a pour destination 192.168.1.3</para>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>PROTO=UDP</term>

            <listitem>
              <para>Le protocole est UDP</para>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>DPT=53</term>

            <listitem>
              <para>Le port de destination est le port 53 (DNS)</para>
            </listitem>
          </varlistentry>
        </variablelist>

        <para>Pour plus d'informations concernant les messages de
        journalisation, voir <ulink
        url="http://logi.cc/linux/netfilter-log-format.php3">http://logi.cc/linux/netfilter-log-format.php3</ulink>.</para>

        <para>Dans ce cas, 192.168.2.2 était dans la zone <quote>dmz</quote>
        et 192.168.1.3 était dans la zone <quote>loc</quote>. Il me manquait
        la règle suivante:</para>

        <programlisting>ACCEPT dmz loc udp 53</programlisting>
      </example>
    </section>

    <section id="faq21">
      <title>(FAQ 21) Je vois occasionnellement ces étranges messages dans mon
      journal. De quoi s'agit-il?</title>

      <programlisting>Nov 25 18:58:52 linux kernel:
      Shorewall:net2all:DROP:IN=eth1 OUT=
      MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00 SRC=206.124.146.179
      DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP
      TYPE=3 CODE=3 [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00
      TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]</programlisting>

      <para>192.0.2.3 est externe à mon firewall... mon réseau local est
      172.16.0.0/24</para>

      <para><emphasis role="bold">Réponse:</emphasis> Bien que la plupart des
      gens associent ICMP (Internet Control Message Protocol) à
      <quote>ping</quote>, ICMP est une pièce clé de IP. ICMP sert à informer
      l'expéditeur d'un paquet des problèmes rencontrés. C'est ce qui se
      produit ici. Malheureusement, de nombreuses implémentations ne
      fonctionnent pas dès lors que la traduction d'adresses est impliquée (y
      compris SNAT, DNAT et Masquerade). C'est ce que vous voyez avec à
      travers ces messages. Quand Netfilter renvoie ces messages, la partie
      précédent le "[" décrit le paquet ICMP, et la partie entre "[" et "]"
      décrit le paquet pour lequel ICMP répond.</para>

      <para>Voici mon interprétation de ce qui se passe -- pour confirmer
      l'analyse, il faudrait avoir un <quote>sniffeur</quote> de paquets à
      chacune des extrémités de la connexion.</para>

      <para>L'hôte 172.16.1.10 placé derrière la passerelle NAT
      206.124.146.179 a envoyé une requête DNS UDP à 192.0.2.3 et votre
      serveur DNS a tenté d'envoyer un réponse (l'information en réponse est
      entre les crochets -- remarquez le port source 53 qui indique qu'il
      s'agit d'une réponse DNS). Quand la réponse a été envoyée à
      206.124.146.179, le firewall a réécrit l'adresse IP destination à
      172.16.1.10 puis a fait suivre le paquet à 172.16.1.10 qui n'avait plus
      de connexion UDP sur le port 2857. Ceci provoque la génération d'un
      message ICMP port unreachable (type 3, code 3) en retour vers 192.0.2.3.
      Ce paquet est renvoyé par 206.124.146.179 qui change correctement
      l'adresse source dans le paquet pour 206.124.146.179 mais ne modifie pas
      de la même façon l'IP destination dans la réponse DNS d'origine. Lorsque
      le paquet ICMP atteint votre firewall (192.0.2.3), celui-ci n'a aucun
      enregistrement lui indiquant qu'il a envoyé une réponse DNS à
      172.16.1.10 et par conséquent ce paquet ICMP semble n'être associé à
      rien de ce qui a été envoyé. Le résultat est que ce paquet est
      journalisé et ignoré (DROP) par la chaîne all2all. J'ai également vu des
      cas dans lesquels la source IP dans le paquet ICMP lui-même n'est pas
      ré-écrite à l'adresse externe de la passerelle NAT distante. Dans ce cas
      votre firewall va journaliser et ignorer (DROP) le paquet par la chaîne
      rfc1918 cas son IP source est réservée par la RFC 1918.</para>
    </section>

    <section id="faq52">
      <title>(FAQ 52) Quand je blackliste une adresse IP avec
      "shorewall[-lite] drop www.xxx.yyy.zzz", pourquoi est-ce qu'il y a
      toujours des entrées REDIRECT et DNAT en provenance de cette adresse
      dans mon journal ?</title>

      <para>J'ai blacklisté l'adresse 130.252.100.59 avec la commande
      <command>shorewall drop 130.252.100.59</command> mais je vois toujours
      ces messages dans le journal:</para>

      <programlisting>Jan 30 15:38:34 server Shorewall:net_dnat:REDIRECT:IN=eth1 OUT= MAC=00:4f:4e:14:97:8e:00:01:5c:23:24:cc:08:00
                       SRC=130.252.100.59 DST=206.124.146.176 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=42444 DF
                       PROTO=TCP SPT=2215 DPT=139 WINDOW=53760 RES=0x00 SYN URGP=0</programlisting>

      <para><emphasis role="bold">Réponse</emphasis>: Veuillez vous référer à
      <ulink url="NetfilterOverview.html">Shorewall Netfilter
      Documentation</ulink>. La journalisation des règles REDIRECT et DNAT se
      produit dans la chaîne PREROUTING de la table nat dans laquelle
      l'adresse est toujours valide. Le blacklistage se produit dans les
      chaînes INPUT et FORWARD de la table filter qui ne sont traversées que
      plus tard.</para>
    </section>

    <section id="faq56">
      <title>(FAQ 56) Quand je démarre ou redémarre Shorewall, je vois ces
      messages dans mon fichier log. Est-ce grave ?</title>

      <blockquote>
        <programlisting>modprobe: Can't locate module ipt_physdev
modprobe: Can't locate module iptable_raw</programlisting>
      </blockquote>

      <para><emphasis role="bold">Réponse:</emphasis> Non. Ceci se produit
      lorsque shorewall teste votre système pour déterminer les fonctions
      qu'il supporte. Ils ne présentent aucun risque.</para>
    </section>
  </section>

  <section>
    <title>Routage</title>

    <section id="faq32">
      <title>(FAQ 32) J'ai deux connexions internet avec deux FAI différents
      sur mon firewall. Comment le configurer avec Shorewall?</title>

      <para><emphasis role="bold">Réponse</emphasis>: voir cet article sur
      <ulink url="MultiISP.html">Shorewall et le routage</ulink>.</para>
    </section>

    <section id="faq49">
      <title>(FAQ 49) Quand je démarre Shorewall, ma table de routage est
      détruite. Pourquoi Shorewall fait-il cela?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Ceci est en général la
      conséquence d'une bêtise dans la configuration du NAT un-à-un
      (one-to-one NAT):</para>

      <orderedlist>
        <listitem>
          <para>Vous spécifiez l'adresse IP primaire d'une interface dans la
          colonne EXTERNAL du fichier <filename>/etc/shorewall/nat</filename>
          alors que la documentation et les commentaires dans le fichier vous
          mettent en garde contre une telle configuration.</para>
        </listitem>

        <listitem>
          <para>Vous spécifiez ADD_IP_ALIASES=Yes et RETAIN_ALIASES=No dans le
          fichier <filename>/etc/shorewall/shorewall.conf</filename>.</para>
        </listitem>
      </orderedlist>

      <para>Cette combinaison fait détruire par Shorewall l'adresse primaire
      de l'interface réseau spécifiée dans la colonne INTERFACE, ce qui a en
      général pour conséquence de détruire routes les routes sortantes de
      cette interface. La solution est de <emphasis role="bold">ne pas
      spécifier l'adresse primaire d'une interface dans la colonne
      EXTERNAL</emphasis>.</para>
    </section>
  </section>

  <section>
    <title>Démarrer et arrêter Shorewall</title>

    <section id="faq7">
      <title>(FAQ 7) Quand j'arrête Shorewall avec la commande
      <quote>shorewall[-lite] stop</quote>, je ne peux plus me connecter à
      quoi que ce soit. Pourquoi cette commande ne fonctionne-t-elle
      pas?</title>

      <para><emphasis role="bold">Réponse</emphasis>: La commande <quote>
      <command>stop</command> </quote> est prévue pour mettre votre firewall
      dans un état de sécurité où seuls les hôtes listés dans le fichier
      <filename>/etc/shorewall/routestopped</filename> sont activés. Si vous
      voulez ouvrir complètement votre firewall, il vous faut utiliser la
      commande <quote><command>shorewall clear</command></quote>.</para>
    </section>

    <section id="faq8">
      <title>(FAQ 8) Quand je tente de lancer Shorewall sur RedHat, je reçois
      des messages d'erreur insmod -- qu'est-ce qui ne va pas?</title>

      <para><emphasis role="bold">Réponse:</emphasis> La sortie que vous avez
      ressemble à ceci:</para>

      <programlisting>/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.</programlisting>

      <para>En général, ce problème est corrigé par la séquence de commandes
      qui suit:</para>

      <programlisting><command>service ipchains stop
chkconfig --delete ipchains
rmmod ipchains</command></programlisting>

      <para>Par ailleurs, assurez-vous d'avoir vérifié dans l'<ulink
      url="errata.htm">errata</ulink> que vous n'avez pas de problèmes lié à
      la version d'iptables (v1.2.3) distribuée avec RH7.2.</para>

      <section id="faq8a">
        <title>(FAQ 8a) Quand je tente de lancer Shorewall sur une RedHat, je
        reçois un message qui me renvoie à la FAQ #8</title>

        <para><emphasis role="bold">Réponse:</emphasis> Ceci se traite en
        général avec la séquence de commandes présentée ci-dessus dans la
        <xref linkend="faq8" />.</para>
      </section>
    </section>

    <section id="faq9">
      <title>(FAQ 9) Pourquoi Shorewall ne réussit-il pas à détecter
      convenablement mes interfaces au démarrage?</title>

      <para>Je viens d'installer Shorewall et quand je lance la commande
      start, voilà ce qui se passe :</para>

      <programlisting>Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
   Zones: net loc
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
    <emphasis role="bold">Net Zone: eth0:0.0.0.0/0
    </emphasis><emphasis role="bold">Local Zone: eth1:0.0.0.0/0</emphasis>
Deleting user chains...
Creating input Chains...
...</programlisting>

      <para>Pourquoi est-ce que Shorewall ne détecte-t-il pas correctement mes
      interfaces?</para>

      <para><emphasis role="bold">Réponse:</emphasis> La sortie ci-dessus est
      parfaitement normale. La zone Net est définie comme étant composée de
      toutes les machines connectées à eth0 et la zone Local est définie comme
      étant composée de toutes celles connectées à eth1. Si vous utilisez
      Shorewall 1.4.10 ou une version plus récente, vous pouvez envisager de
      paramétrer l'<ulink url="Documentation.htm#Interfaces">option
      d'interface</ulink> <emphasis role="bold">detectnet</emphasis> pour
      votre interface locale (eth1 dans l'exemple ce-dessus). Ceci forcera
      Shorewall à restreindre la zone locale aux seuls réseaux routés par
      cette interface.</para>
    </section>

    <section id="faq22">
      <title>(FAQ 22) Je voudrais exécuter certaines commandes iptables au
      démarrage de Shorewall. Dans quel fichier les mettre?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Vous pouvez placer ces
      commandes dans une des <ulink
      url="shorewall_extension_scripts.htm">Scripts d'Extension
      Shorewall</ulink>. Assurez-vous de bien examiner le contenu des chaînes
      que vos commandes vont modifier afin d'être certain que ces commandes
      feront bien ce qu'elles sont censées faire. De nombreuses commandes
      publiées dans des guides (HOWTOs) ainsi que dans d'autres modes
      opératoires font usage de la commande -A qui ajoute les règles en fin de
      chaîne. La plupart des chaînes construites par Shorewall se terminent
      par une règle inconditionnelle DROP, ACCEPT ou REJECT et donc toute
      règle que vous pourriez ajouter après serait ignorée. Consultez
      <quote>man iptables</quote> et prenez connaissance de la commande -I
      (--insert).</para>
    </section>

    <section id="faq34">
      <title>(FAQ 34) Comment accélérer le démarrage (start/restart)?</title>

      <para><emphasis role="bold">Réponse</emphasis>: L'utilisation d'un shell
      léger tel que <command>ash</command> peut diminuer de façon très
      significative le temps nécessaire pour démarrer (<emphasis
      role="bold">start</emphasis>/<emphasis role="bold">restart</emphasis>)
      Shorewall. Voyez la variable SHOREWALL_SHELL dans le fichier
      <filename><ulink url="Documentation.htm#Conf">shorewall.conf</ulink>
      </filename>.</para>

      <para>Utilisez un émulateur de terminal rapide -- en particulier la
      console KDE défile beaucoup plus vite que le terminal Gnome. Vous pouvez
      également utiliser l'option '-q' si vous redémarrez à distance ou depuis
      un terminal lent (ou rediriger la sortie vers un fichier comme dans
      <command>shorewall restart &gt; /dev/null</command>).</para>

      <para>Mettez votre matériel à niveau. De nombreux utilisateurs ont
      constaté que même une amélioration modeste de la CPU et de la vitesse de
      la mémoire (par exemple passer d'un P3 avec de la SDRAM à un P4 avec de
      la DDR) avait des effets très significatifs. Les CPU dotées de la
      technologie EM64T, aussi bien celles d'AMD que celles d'Intel, montrent
      des performances de redémarrage très acceptables, même si vous avez un
      jeu de règles assez complexe.</para>

      <para>Shorewall offre également une fonction de démarrage rapide. Pour
      l'utiliser:</para>

      <orderedlist>
        <listitem>
          <para>Avec Shorewall dans l'<ulink
          url="starting_and_stopping_shorewall.htm">état démarré</ulink>,
          exécutez <command>shorewall save</command>. Cela va créer le script
          <filename>/var/lib/shorewall/restore</filename>.</para>
        </listitem>

        <listitem>
          <para>Utilisez l'option <emphasis role="bold">-f </emphasis>avec la
          commande start (par exemple, <command>shorewall -f start</command>).
          Ceci forcera Shorewall à chercher le script
          <filename>/var/lib/shorewall/restore</filename> et à l'exécuter si
          il existe. Exécuter <filename>/var/lib/shorewall/restore</filename>
          prend beaucoup moins de temps que d'exécuter un <command>shorewall
          start</command> complet.</para>
        </listitem>

        <listitem>
          <para>Le script <filename>/etc/init.d/shorewall</filename> exécuté
          au démarrage du système utilise l'option <emphasis
          role="bold">-f</emphasis>.</para>
        </listitem>

        <listitem>
          <para>Le script <filename>/var/lib/shorewall/restore</filename> peut
          être exécuté à tout moment pour restaurer le firewall. Il peut être
          invoqué directement ou bien indirectement en utilisant la commande
          <command>shorewall restore</command>.</para>
        </listitem>
      </orderedlist>

      <para>Si vous modifiez votre configuration de Shorewall, vous devez
      exécuter un <emphasis role="bold">shorewall start</emphasis> (sans
      <emphasis role="bold">-f</emphasis>) ou un <command>shorewall
      restart</command> avant de refaire un <command>shorewall save</command>.
      La commande <command>shorewall save</command> sauvegarde la
      configuration qui tournait au moment où elle a été exécutée et non celle
      que représentent les fichiers de configuration que vous avez
      modifiés.</para>

      <para>De même, si vous modifiez votre configuration Shorewall et que
      vous êtes satisfait du résultat, vous devez exécuter une commande
      <command>shorewall save</command>, sans quoi vous reviendriez à
      l'ancienne configuration enregistrée dans
      <filename>/var/lib/shorewall/restore</filename> lors du prochain
      démarrage de votre système.</para>

      <para>Finalement, le temps pendant lequel les nouvelles connexions sont
      bloquées durant le redémarrage de Shorewall peut être réduit dans de
      très grande proportions en upgradant vers Shorewall 3.2 ou une version
      ultérieure. A partir de la 3.2, <command>shorewall [re]start</command>
      procède en deux étapes:</para>

      <orderedlist>
        <listitem>
          <para>La configuration courante est compilée afin de produire un
          programme shell conçu pour votre configuration.</para>
        </listitem>

        <listitem>
          <para>Si la compilation se déroule sans erreur, le programme compilé
          est exécuté pour [re]démarrer votre firewall.</para>
        </listitem>
      </orderedlist>
    </section>

    <section id="faq43">
      <title>(FAQ 43) Je viens d'installer le RPM Shorewall et Shorewall ne
      démarre pas au lancement du système (boot).</title>

      <para><emphasis role="bold">Réponse</emphasis>: Quand vous installez
      avec la commande "rpm -U", Shorewall n'exécute pas les outils de votre
      distribution qui configurent le démarrage de Shorewall. Vous devrez
      exécuter cet outils vous-même (insserv, chkconfig, run-level editor,
      &hellip;) pour que Shorewall démarre aux niveaux d'exécutions
      (run-level) auxquels vous voulez l'utiliser.</para>
    </section>

    <section id="faq45">
      <title>(FAQ 45) Pourquoi est-ce que "shorewall[-lite] start" échoue
      lorsque je tente de mettre en place SNAT/Masquerade?</title>

      <para><command>shorewall start</command> produit la sortie
      suivante:</para>

      <programlisting>&hellip;
Processing /etc/shorewall/policy...
   Policy ACCEPT for fw to net using chain fw2net
   Policy ACCEPT for loc0 to net using chain loc02net
   Policy ACCEPT for loc1 to net using chain loc12net
   Policy ACCEPT for wlan to net using chain wlan2net
Masqueraded Networks and Hosts:
iptables: Invalid argument
   ERROR: Command "/sbin/iptables -t nat -A &hellip;" Failed</programlisting>

      <para><emphasis role="bold">Réponse</emphasis>: Dans 99.999% des cas,
      cette erreur provient d'un problème de comptabilité des versions
      d'iptables et du noyau.</para>

      <orderedlist numeration="loweralpha">
        <listitem>
          <para>Votre iptables doit être compilé en utilisant un arbre de
          sources du noyau qui soit compatible au niveau Netfilter avec le
          noyau que vous exécutez sur votre système.</para>
        </listitem>

        <listitem>
          <para>Si vous recompilez iptables avec les paramètres par défaut
          puis que vous l'installez, il sera installé dans
          <filename>/usr/local/sbin/iptables</filename>. Comme on peut le voir
          ci-dessus, votre variable IPTABLES est configurée à
          <filename>/sbin/iptables</filename> dans votre fichier
          <filename>shorewall.conf</filename>.</para>
        </listitem>
      </orderedlist>
    </section>

    <section id="faq59">
      <title>(FAQ 59) Après le démarrage de Shorewall, de nombreux modules
      netfilter inutilisés sont chargés. Comment éviter cela ?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Copiez
      <filename>/usr/share/shorewall/modules</filename> (ou
      <filename>/usr/share/shorewall/xmodules</filename> suivant le cas) vers
      <filename>/etc/shorewall/modules</filename> et modifiez cette copie pour
      qu'elle ne contienne que les modules dont vous avez besoin.</para>
    </section>

    <section id="faq61">
      <title>(FAQ 61) Je viens juste d'installer le nouveau kernel Debian, et
      maintenant "shorewall start" échoue avec le message "ipt_policy:
      matchsize 116 != 308". Qu'est-ce qui ne va pas?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Votre version d'iptables
      est incompatible avec votre kernel.</para>

      <itemizedlist>
        <listitem>
          <para>recompilez iptables en utilisant les headers de votre nouveau
          kernel; ou bien</para>
        </listitem>

        <listitem>
          <para>si vous n'avez pas besoin du support de "policy match" (vous
          n'utilisez pas l'implémentation IPSEC du kernel 2.6) vous pouvez
          renommer <filename>/lib/iptables/libipt_policy.so</filename>.</para>
        </listitem>
      </itemizedlist>
    </section>
  </section>

  <section>
    <title>Multiples FAIs</title>

    <section id="faq57">
      <title>(FAQ 57) J'ai configuré deux FAIs dans Shorewall mais quand
      j'essaye d'utiliser le second, cela ne fonctionne pas.</title>

      <para><emphasis role="bold">Réponse</emphasis>: La documentation
      Multi-ISP vous recommande très fortement d'utiliser l'option
      d'équilibrage<emphasis role="bold"> (balance)</emphasis> pour tous les
      FAIs même si vous voulez spécifier manuellement quel FAI utiliser. Si
      vous ne le faites pas et que votre table principale de routage n'a
      qu'une seule route par défaut, vous devez désactiver le filtrage de
      route. Ne spécifiez pas l'option <emphasis
      role="bold">routefilter</emphasis> sur l'autre interface dans
      <filename>/etc/shorewall/interfaces</filename> et désactivez toute
      protections contre <emphasis>le spoofing d'adresses IP</emphasis> que
      votre distribution pourrait offrir.</para>
    </section>

    <section id="faq58">
      <title>(FAQ 58) Mais si je spécifie 'balance' est-ce que shorewall ne va
      pas équilibrer le trafic entre les interfaces ? Je ne veux pas qu'il le
      fasse !</title>

      <para><emphasis role="bold">Réponse</emphasis>: Supposez que vous
      vouliez que tout le trafic passe par le FAI1 (mark 1) jusqu'à ce que
      vous spécifiez différemment. Dans ce cas, ajoutez simplement ces deux
      règles comme premières règles de marquage dans votre fichier
      <filename>/etc/shorewall/tcrules</filename>:</para>

      <programlisting>#MARK         SOURCE           DEST
1:P           0.0.0.0/0
1:P           $FW
&lt;other MARK rules&gt;</programlisting>

      <para>Maintenant, tout le trafic qui n'est pas marqué par une de vos
      autres règles de marquage aura mark=1 et sera envoyé par le FAI1. Ceci
      fonctionnera que l'option <emphasis role="bold">balance</emphasis> soit
      spécifiée ou pas.</para>
    </section>
  </section>

  <section>
    <title>Au sujet de Shorewall</title>

    <section id="faq10">
      <title>(FAQ 10) Sur quelles distributions Shorewall tourne-t-il?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Shorewall fonctionnera
      sur n'importe quelle distribution GNU/Linux distribution réunissant les
      <ulink url="shorewall_prerequisites.htm">pré-requis Shorewall</ulink>
      indiqués dans ce document.</para>
    </section>

    <section id="faq11">
      <title>(FAQ 11) Quelles sont les caractéristiques de Shorewall ?</title>

      <para><emphasis role="bold">Réponse</emphasis>: voir la <ulink
      url="shorewall_features.htm">liste des caractéristiques de
      Shorewall</ulink>.</para>
    </section>

    <section id="faq12">
      <title>(FAQ 12) Existe-t-il une interface graphique?</title>

      <para><emphasis role="bold">Réponse:</emphasis> Oui. Webmin offre le
      support de Shorewall 3.x à partir dans sa version 1.300. Voir <ulink
      url="http://www.webmin.com">http://www.webmin.com</ulink></para>
    </section>

    <section id="faq13">
      <title>(FAQ 13) Pourquoi l'avez-vous appelé
      <quote>Shorewall</quote>?</title>

      <para><emphasis role="bold">Réponse:</emphasis> Shorewall est le
      résultat de la concaténation de <quote>
      <emphasis>Shore</emphasis>line</quote> (<ulink
      url="http://www.cityofshoreline.com">la ville où je vis</ulink>) et de
      <quote>Fire<emphasis>wall</emphasis> </quote>. En fait le nom complet du
      produit est <quote>Shoreline Firewall</quote> mais on utilise plus
      communément <quote>Shorewall</quote>.</para>
    </section>

    <section id="faq23">
      <title>(FAQ 23) Pourquoi utilisez-vous des polices de caractères aussi
      affreuses sur votre site web?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Le site web de Shorewall
      est presque entièrement neutre en ce qui concerne les polices (à
      l'exception de quelques pages il ne spécifie explicitement aucune
      police). Les polices que vous voyez sont largement celles configurées
      par défaut dans votre navigateur. Si vous ne les aimez pas reconfigurez
      votre navigateur.</para>
    </section>

    <section id="faq25">
      <title>(FAQ 25) Comment savoir quelle version de Shorewall ou de
      Shorewall Lite j'utilise?</title>

      <para><emphasis role="bold">Réponse</emphasis>: A l'invite du système,
      tapez:</para>

      <programlisting><command>/sbin/shorewall[-lite] version</command>      </programlisting>
    </section>

    <section id="faq31">
      <title>(FAQ 31) Est-ce que Shorewall fournit une protection
      contre....</title>

      <variablelist>
        <varlistentry>
          <term>IP Spoofing: envoyer des paquets par l'interface WAN en se
          servant d'adresses IP du réseau local comme adresse source?</term>

          <listitem>
            <para><emphasis role="bold">Réponse</emphasis>: Oui.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>Tear Drop: Envoyer des paquets contenant des fragments qui se
          recouvrent ?</term>

          <listitem>
            <para><emphasis role="bold">Réponse</emphasis>: Ceci est de la
            responsabilité de la pile IP, ce n'est pas celle d'un firewall
            basé sur Netfilter car le ré-assemblage des fragments est fait
            avant que le filtre de paquets ne voie chaque paquet.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>Smurf and Fraggle: Envoyer des paquets qui utilisent comme
          adresse source l'adresse de diffusion (broadcast) du WAN ou du
          LAN?</term>

          <listitem>
            <para><emphasis role="bold">Réponse</emphasis>: On peut configurer
            Shorewall pour le faire avec sa fonction de <ulink
            url="blacklisting_support.htm">liste noire (blacklist)</ulink>. A
            partir de la version 2.0.0, Shorewall filtre ces paquets avec
            l'option d'interface <firstterm>nosmurfs</firstterm> dans le
            fichier <ulink
            url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink>.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>Land Attack: Envoyer des paquets utilisant la même adresse
          comme source et comme destination?</term>

          <listitem>
            <para><emphasis role="bold">Réponse</emphasis>: Oui lorsque
            l'<ulink url="Documentation.htm#Interfaces">option d'interface
            routefilter</ulink> est sélectionnée.</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>DOS: Déni de Service SYN Dos - ICMP Dos - protection DOS par
          hôte</term>

          <listitem>
            <para><emphasis role="bold">Réponse</emphasis>: Shorewall offre la
            possibilité de limiter les paquets SYN les paquets ICMP. Netfilter
            tel qu'il est inclus dans les noyaux Linux standard ne supporte
            pas la mise en oeuvre de limitations par hôte distant sauf en
            utilisant une règle explicite qui spécifie l'adresse IP de l'hôte.
            Cette forme de limitation est supportée par Shorewall.</para>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="faq36">
      <title>(FAQ 36) Est-ce que Shorewall tourne sur le noyau Linux
      2.6?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Shorewall fonctionne
      avec les noyaux 2.6 avec les deux restrictions suivantes:</para>

      <itemizedlist>
        <listitem>
          <para>Dans les noyaux 2.6 jusqu'au 2.6.16, Netfilter/iptables
          n'offre pas un support complet d'IPSEC -- il existe des patch pour
          le noyau et pour iptables. Vous trouverez des détails à la page
          <ulink url="IPSEC-2.6.html">Shorewall IPSEC-2.6</ulink>.</para>
        </listitem>

        <listitem>
          <para>Les noyaux 2.6 n'offrent pas le support des options logunclean
          et dropunclean du fichier
          <filename>/etc/shorewall/interfaces</filename>. Le support de ces
          options a également été retiré de Shorewall dans la version
          2.0.0.</para>
        </listitem>
      </itemizedlist>
    </section>
  </section>

  <section>
    <title>RFC 1918</title>

    <section id="faq14">
      <title>(FAQ 14) Je suis connecté avec un modem câble qui a son propre
      serveur web interne utilisé pour le paramétrage et la supervision. Mais
      bien entendu, si j'active le blocage des adresse de la RFC 1918 sur mon
      interface internet eth0, le serveur web du modem est bloqué lui
      aussi.</title>

      <para>Est-il possible de rajouter une règle avant la règle de blocage
      rfc1918 de façon à autoriser tout le trafic en provenance et à
      destination de 192.168.100.1, adresse de mon modem, tout en continuant à
      filtrer les autres adresses rfc1918?</para>

      <para><emphasis role="bold">Réponse</emphasis>: Ajoutez ce qui suit dans
      le fichier <ulink
      url="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</ulink>
      (Remarque: Si vous utilisez 2.0.0 ou une version ultérieure, il est
      possible que ayez à préalablement à copier le fichier
      <filename>/usr/share/shorewall/rfc1918</filename> vers
      <filename>/etc/shorewall/rfc1918</filename>):</para>

      <para>Assurez-vous d'ajouter l'entrée AU-DESSUS de l'entrée pour
      192.168.0.0/16.</para>

      <programlisting>#SUBNET        TARGET
192.168.100.1  RETURN</programlisting>

      <note>
        <para>Si vous ajoutez une seconde adresse IP à l'interface externe de
        votre firewall qui corresponde à l'adresse du modem, vous devez
        ajouter une entrée pour cette adresse dans le fichier
        <filename>/etc/shorewall/rfc1918</filename>. Par exemple, si vous
        configurez l'adresse 192.168.100.2 sur votre firewall, vous devrez
        ajouter les deux entrées suivantes dans le fichier
        <filename>/etc/shorewall/rfc1918</filename>:</para>

        <programlisting>#SUBNET        TARGET
192.168.100.1  RETURN
192.168.100.2  RETURN</programlisting>
      </note>

      <section id="faq14a">
        <title>(FAQ 14a) Bien qu'il assigne des adresses IP publiques, le
        serveur DHCP de mon FAI a une adresse de la RFC 1918. Si j'active le
        filtrage RFC 1918 sur mon interface externe, mon client DHCP ne peut
        plus renouveler son bail.</title>

        <para><emphasis role="bold">Réponse</emphasis>: La solution est la
        même que dans la <link linkend="faq14">FAQ 14</link> présentée
        au-dessus. Substituez-y simplement l'adresse du serveur DHCP de votre
        FAI.</para>
      </section>

      <section id="faq14b">
        <title>(FAQ 14b) Je me connecte à internet par PPPoE. Quand j'essaye
        de me connecter au serveur web incorporé à mon modem DSL, la connexion
        est refusée.</title>

        <para>Dans mon journal je peux voir ce qui suit:</para>

        <programlisting>Mar  1 18:20:07 Mail kernel: Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=60
TOS=0x00 PREC=0x00 TTL=64 ID=26774 DF PROTO=TCP SPT=32797 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 </programlisting>

        <para><emphasis role="bold">Réponse</emphasis>: Le fait que le message
        soit journalisé par la chaîne OUTPUT signifie que l'adresse de
        destination n'appartient à aucune des zones définies (voir la <link
        linkend="faq17">FAQ 17</link>). Vous devez:</para>

        <orderedlist>
          <listitem>
            <para>Ajouter une zone pour votre modem dans le fichier
            <filename>/etc/shorewall/zones</filename>:</para>

            <programlisting>#ZONE    TYPE          OPTIONS
modem    ipv4</programlisting>
          </listitem>

          <listitem>
            <para>Dans le fichier
            <filename>/etc/shorewall/interfaces</filename>, associer cette
            zone avec l'interface à laquelle votre modem est connecté (eth0
            dans l'exemple):</para>

            <programlisting>#ZONE      INTERFACE   BROADCAST    OPTIONS
modem      eth0        detect</programlisting>
          </listitem>

          <listitem>
            <para>Autoriser le trafic web vers le modem dans le fichier
            <filename>/etc/shorewall/rules</filename>:</para>

            <programlisting>#ACTION    SOURCE      DEST      PROTO     DEST PORT(S)
ACCEPT     fw          modem     tcp       80
ACCEPT     loc         modem     tcp       80</programlisting>
          </listitem>
        </orderedlist>

        <para>Notez qu'un grand nombre de ces modems cable/DSL n'a pas de
        passerelle par défaut ou alors que leur passerelle par défaut est
        fixée à une adresse IP différente de l'adresse que vous avez attribuée
        à votre interface externe. Dans un cas comme dans l'autre, vous pouvez
        avoir des difficultés à naviguer sur votre modem depuis votre réseau
        local, même si toutes les routes sont correctement établies sur votre
        firewall. Pour résoudre ce problème, on <quote>masquerade</quote> le
        trafic depuis réseau local vers le modem.</para>

        <para><filename>/etc/shorewall/masq</filename>:</para>

        <programlisting>#INTERFACE         SUBNET          ADDRESS
eth0               eth1                        # eth1 = interface to local network</programlisting>

        <para>A titre d'exemple lorsque le modem cable/ADSL est
        <quote>ponté</quote> (bridge), vous pouvez aller voir <ulink
        url="XenMyWay.html">ma configuration</ulink>. Dans ce cas, je
        <quote>masquerade</quote> en utilisant l'adresse IP de mon interface
        locale!</para>
      </section>
    </section>
  </section>

  <section>
    <title>Adresses Alias IP/Interfaces virtuelles</title>

    <section id="faq18">
      <title>(FAQ 18) Existe-t-il un moyen d'utiliser des adresses IP aliasées
      avec Shorewall, et de maintenir des jeux de règles séparés pour ces
      différentes adresses IP?</title>

      <para><emphasis role="bold">Réponse:</emphasis> Oui. Voyez <ulink
      url="Shorewall_and_Aliased_Interfaces.html">Shorewall et les interfaces
      aliasées</ulink>.</para>
    </section>
  </section>

  <section>
    <title>Shorewall Lite</title>

    <section id="faq53">
      <title>(FAQ 53) Qu'est-ce que Shorewall Lite?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Shorewall Lite est un
      produit partenaire de Shorewall. Il est conçu pour vous permettre de
      maintenir les informations de toutes vos configurations de Shorewall sur
      un seul système dans votre réseau. Pour plus de détails, voir <ulink
      url="CompiledPrograms.html#Lite">Compiled Firewall script
      documentation</ulink>.</para>
    </section>

    <section id="faq54">
      <title>(FAQ 54) Si je veux installer Shorewall Lite, est-ce que je dois
      aussi installer Shorewall sur le même système ?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Non. En fait, nous
      recommandons que vous n'installiez pas Shorewall sur les systèmes sur
      lesquels vous souhaitez utiliser Shorewall Lite. Vous devez avoir
      installé Shorewall sur au moins un des systèmes de votre réseau pour
      pouvoir utiliser Shorewall Lite.</para>
    </section>

    <section id="faq55">
      <title>(FAQ 55) Comment décider quel produit utiliser - Shorewall ou
      Shorewall Lite?</title>

      <para><emphasis role="bold">Réponse</emphasis>: Si vous prévoyez d'avoir
      un seul firewall, Shorewall est le choix logique. Je pense aussi que
      Shorewall est le choix le plus approprié pour un portable car vous
      pouvez avoir à changer sa configuration lorsque vous êtes en
      déplacement. Dans tous les autres cas, Shorewall Lite fonctionnera très
      bien. A shorewall.net, les deux portables ainsi que mon ordinateur de
      bureau linux sont installés avec la version complète de Shorewall. Tous
      les autres systèmes Linux qui ont un firewall utilisent Shorewall Lite
      et leurs répertoires de configuration sont sur mon ordinateur de
      bureau.</para>
    </section>

    <section id="faq60">
      <title>(FAQ 60) Quelles restrictions de compatibilité existent entre
      Shorewall et Shorewall Lite</title>

      <para><emphasis role="bold">Réponse</emphasis>: Voir le tableau
      ci-dessous (C = Complètement compatible avec toutes les fonctionnalités
      disponibles, P1 = Compatible mais la totalité des fonctions de Shorewall
      ne sont pas disponibles, P2 = Compatible mais la totalité des fonctions
      de Shorewall Lite ne sont pas disponibles, I = incompatible).</para>

      <informaltable align="center">
        <tgroup cols="5">
          <colspec align="center" />

          <thead>
            <row>
              <entry align="center"></entry>

              <entry align="center">Shorewall Lite 3.2.0</entry>

              <entry align="center" morerows="">Shorewall Lite 3.2.1</entry>

              <entry align="center">Shorewall Lite 3.2.2</entry>

              <entry align="center">Shorewall Lite 3.2.3</entry>
            </row>
          </thead>

          <tbody>
            <row>
              <entry><emphasis role="bold">Shorewall 3.2.0</emphasis></entry>

              <entry align="center">C</entry>

              <entry align="center">C</entry>

              <entry align="center">P2</entry>

              <entry align="center">P2</entry>
            </row>

            <row>
              <entry><emphasis role="bold">Shorewall 3.2.1</emphasis></entry>

              <entry align="center">C</entry>

              <entry align="center">C</entry>

              <entry align="center">C</entry>

              <entry align="center">P2</entry>
            </row>

            <row>
              <entry><emphasis role="bold">Shorewall 3.2.2</emphasis></entry>

              <entry align="center">P1</entry>

              <entry align="center">P1</entry>

              <entry align="center">C</entry>

              <entry align="center">C</entry>
            </row>

            <row>
              <entry><emphasis role="bold">Shorewall 3.2.3</emphasis></entry>

              <entry align="center">P1</entry>

              <entry align="center">P1</entry>

              <entry align="center">C</entry>

              <entry align="center">C</entry>
            </row>
          </tbody>
        </tgroup>
      </informaltable>
    </section>
  </section>

  <section>
    <title>Divers</title>

    <section id="faq20">
      <title>(FAQ 20) Je viens d'installer un serveur. Dois-je modifier
      Shorewall pour autoriser les accès internet à mon serveur?</title>

      <para><emphasis role="bold">Réponse </emphasis>: Oui. Consultez le
      <ulink url="shorewall_quickstart_guide.htm">guides de démarrage
      rapide</ulink> que vous avez utilisé pour votre configuration initiale
      afin d'avoir des informations nécessaires à l'écriture des règles pour
      votre serveur.</para>
    </section>

    <section id="faq24">
      <title>(FAQ 24) Comment puis-je autoriser des connexions internet au
      port ssh, par exemple, mais seulement depuis certaines adresses IP
      spécifiques?</title>

      <para><emphasis role="bold">Réponse </emphasis>: Dans la colonne SOURCE
      de la règle, faites suivre <quote>net</quote> de <quote>:</quote> puis
      d'une liste séparée par des virgules d'adresses de machines ou de
      sous-réseaux</para>

      <programlisting>net:&lt;ip1&gt;,&lt;ip2&gt;,...</programlisting>

      <example>
        <title>Exemple:</title>

        <programlisting>ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22</programlisting>
      </example>
    </section>

    <section id="faq26">
      <title>(FAQ 26) Quand j'essaye d'utiliser nmap avec n'importe laquelle
      des options SYN depuis le firewall lui-même ou depuis n'importe quelle
      machine derrière le firewall, j'obtiens une erreur <quote>operation not
      permitted</quote>. Comment utiliser nmap avec Shorewall?"</title>

      <para><emphasis role="bold">Réponse </emphasis>: Retirez temporairement
      les règles rejNotSyn, dropNotSyn and dropInvalid du fichier
      <filename>/etc/shorewall/rules</filename> et relancez Shorewall.</para>
    </section>

    <section id="faq27">
      <title>(FAQ 27) Je compile un nouveau noyau (kernel) pour mon firewall.
      A quoi devrais-je faire attention?</title>

      <para><emphasis role="bold">Réponse </emphasis>: Commencez par regarder
      la page de <ulink url="kernel.htm">configuration du noyau pour
      Shorewall</ulink>. Vous souhaiterez sans doute vous assurer que vous
      avez bien sélectionné <quote> <emphasis role="bold">NAT of local
      connections (READ HELP)</emphasis> </quote> dans le menu de
      configuration de Netfilter. Sans cela, les règles DNAT ayant votre
      firewall comme zone source ne fonctionneraient pas avec votre nouveau
      noyau.</para>

      <section id="faq27a">
        <title>(FAQ 27a) Je viens de compiler (ou j'ai téléchargé ou récupéré
        par n'importe quel autre moyen) et d'installer un nouveau noyau et
        Shorewall ne démarre plus. Je sais que les options de mon noyau sont
        correctes.</title>

        <para>Les dernières lignes de la <ulink url="troubleshoot.htm">trace
        de démarrage</ulink> sont les suivantes:</para>

        <programlisting>+ run_iptables2 -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE
+ '[' 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE' = 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.
0/0 -j MASQUERADE' ']'
+ run_iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE
+ iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE
iptables: Invalid argument
+ '[' -z '' ']'
+ stop_firewall
+ set +x</programlisting>

        <para><emphasis role="bold">Réponse:</emphasis> votre noyau contient
        des entêtes incompatibles avec celles utilisées pour compiler votre
        programme <command>iptables</command>. Vous devez recompiler
        <command>iptables</command> en utilisant l'arbre de sources de votre
        nouveau noyau.</para>
      </section>
    </section>

    <section id="faq28">
      <title>(FAQ 28) Comment utiliser Shorewall en pont filtrant (Bridging
      Firewall)?</title>

      <para><emphasis role="bold">Réponse </emphasis>: Le support Shorewall
      pour les ponts filtrant existe &mdash; <ulink url="bridge_fr.html">voir
      ici pour les détails</ulink>.</para>
    </section>

    <section id="faq39">
      <title>(FAQ 39) Comment bloquer les connexion à un domaine
      particulier?</title>

      <para>J'ai essayé de bloquer Adsense de Google. Adsense est un
      Javascript que les gens ajoutent à leur pages web. J'ai ajouté la règle
      suivante:</para>

      <programlisting>#ACTION   SOURCE        DEST                                 PROTO
REJECT    fw            net:pagead2.googlesyndication.com    all</programlisting>

      <para>Cependant, ceci bloque parfois les accès à "google.com". Pourquoi?
      Avec dig, je trouve les adresses IP suivantes pour le domaine
      googlesyndication.com:<programlisting>216.239.37.99
216.239.39.99</programlisting>Et celles-ci pour google.com:<programlisting>216.239.37.99
216.239.39.99
216.239.57.99</programlisting>Je suppose donc que ce n'est pas le domaine qui
      est bloqué mais plutôt ses adresses IP. Comment bloquer réellement un
      nom de domaine?</para>

      <para><emphasis role="bold">Réponse:</emphasis> Les filtres de paquets
      basent leurs décisions sur le contenu des différents entêtes de
      protocole qui se trouvent au début de chaque paquet. Les filtres de
      paquet à suivi d'états (dont Netfilter est un exemple) utilisent une
      combinaison du contenu de l'entête et de l'état de la connexion créé
      lors du traitement de paquets précédents. Netfilter (et l'usage qui en
      est fait par Shorewall) prend également en compte l'interface réseau sur
      laquelle chaque paquet est entré ou sur laquelle le paquet va quitter le
      routeur/firewall.</para>

      <para>Lorsque vous spécifiez un <ulink
      url="configuration_file_basics.htm#dnsnames">nom de domaine dans une
      règle Shorewall</ulink>, le programme iptables résout ce nom en une ou
      plusieurs adresses IP et les véritables règles qui seront créées sont
      exprimées avec ces adresses IP. C'est pourquoi la règle que vous avez
      entrée est équivalente à:</para>

      <para><programlisting>#ACTION   SOURCE        DEST                 PROTO
REJECT    fw            net:216.239.37.99    all
REJECT    fw            net:216.239.39.99    all</programlisting>Sachant que
      l'hébergement multiple basé sur le nom d'hôte est une pratique courante
      (par exemple, lists.shorewall.net et www1.shorewall.net sont hébergés
      tous les deux sur le même système avec un seule adresse IP), il n'est
      pas possible de filtrer les connexions vers un nom particulier au seul
      examen des entêtes de protocole. Alors que certains protocoles tels que
      <ulink url="FTP.html">FTP</ulink> nécessitent que le firewall examine et
      éventuellement modifie les données (payload) du paquet, analyser les
      données de paquets individuellement ne fonctionne pas toujours car le
      flux de données de niveau application peut être fractionné de manière
      arbitraire entre les paquets. Ceci est une des faiblesses de l'extension
      'string match' de Netfilter que l'on trouve dans le Patch-O-Matic-ng. Le
      seul moyen sûr pour filtrer sur le contenu des paquets est d'utiliser un
      proxy pour les connexions concernées -- dans le cas de HTTP, on pourra
      utiliser une application telle que <ulink
      url="Shorewall_Squid_Usage.html">Squid</ulink>. Lorsqu'on utilise un
      proxy, celui-ci ré-assemble des messages complets de niveau applicatif
      qui peuvent alors être analysés de manière précise.</para>
    </section>

    <section id="faq42">
      <title>(FAQ 42) Comment connaître quelles sont les fonctions supportées
      par mon noyau et ma version d'iptables?</title>

      <para><emphasis role="bold">Réponse</emphasis>: En tant que root,
      utilisez la commande <command>shorewall[-lite] show
      capabilities</command>.</para>

      <programlisting>gateway:~# shorewall show capabilities
Loading /usr/share/shorewall/functions...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Shorewall has detected the following iptables/netfilter capabilities:
   NAT: Available
   Packet Mangling: Available
   Multi-port Match: Available
   Extended Multi-port Match: Available
   Connection Tracking Match: Available
   Packet Type Match: Available
   Policy Match: Available
   Physdev Match: Available
   IP range Match: Available
   Recent Match: Available
   Owner Match: Available
   Ipset Match: Available
   ROUTE Target: Available
   Extended MARK Target: Available
   CONNMARK Target: Available
   Connmark Match: Available
   Raw Table: Available
gateway:~#</programlisting>
    </section>

    <section id="faq19">
      <title>(FAQ 19) Comment ouvrir le firewall pour tout le trafic de/vers
      le LAN?</title>

      <para><emphasis role="bold">Réponse </emphasis>: Ajoutez ces deux
      politiques:</para>

      <programlisting>#SOURCE            DESTINATION             POLICY            LOG              LIMIT:BURST
#                                                            LEVEL
$FW                loc                     ACCEPT
loc                $FW                     ACCEPT           </programlisting>

      <para>Vous pouvez également supprimer toutes les règles ACCEPT de
      $FW-&gt;loc et loc-&gt;$FW car ces règles sont maintenant redondantes
      avec les deux politiques fixées ci-dessus.</para>
    </section>
  </section>
</article>