
Linux VPN Masquerade HOWTO - Version franaise

John D. Hardin <jhardin@wolfenet.com>, version franaise par Yann Hirou
<hirou@linuxfr.org>

   $Revision: 1.1.1.1 $ $Date: 2003/01/03 02:38:54 $

   Ce document dcrit comment configurer un pare-feu Linux pour masquer
   le trafic d'un rseau priv virtuel (NdT: Virtual Private Network,
   VPN) utilisant IPsec ou PPTP, vous permettant ainsi d'tablir une
   connexion VPN sans perdre ni la scurit ni la flexibilit apportes
   par la connexion internet de votre pare-feu Linux, et vous permettant
   de rendre accessible un serveur VPN qui n'a pas d'adresse IP publique.
   Des informations sur la configuration du client et du serveur VPN sont
   galement fournies.
     _________________________________________________________________

   _Table des matires_
   1. Introduction

        1.1. Introduction
        1.2. Avis, Crdits & Ressources
        1.3. Copyright & mise en garde

   2. Connaissances requises

        2.1. Qu'est-ce qu'un VPN ?
        2.2. Qu'est-ce qu'IPsec ?
        2.3. Qu'est-ce que PPTP ?
        2.4. Qu'est-ce que FWZ ?
        2.5. Pourquoi masquer un client VPN ?
        2.6. Plusieurs clients sur mon rseau local peuvent-ils utiliser
                IPsec simultanment ?

        2.7. Plusieurs clients sur mon rseau local peuvent-ils utiliser
                PPTP simultanment ?

        2.8. Puis-je accder au rseau distant depuis l'ensemble de mon
                rseau local ?

        2.9. Pourquoi masquer le serveur VPN ?
        2.10. Pourquoi patcher le noyau Linux ?
        2.11. tat actuel

   3. Configurer le pare-feu Linux

        3.1. Exemple de rseau
        3.2. Dterminer ce qui doit tre fait sur le pare-feu
        3.3. Patcher et configurer le noyau 2.0.x pour le support de
                masquage VPN

        3.4. Patcher et configurer le noyau 2.2.x pour le support de
                masquage VPN

        3.5. Paramtrage de ipfwadm pour un client ou un serveur VPN avec
                une adresse IP prive

        3.6. Paramtrage d'ipchains pour un client ou serveur VPN avec
                une adresse IP prive

        3.7. Une note sur l'adressage IP dynamique
        3.8. Paramtrages additionnels pour un serveur VPN avec une
                adresse IP prive

        3.9. Paramtrage d'ipfwadm pour un serveur VPN avec une adresse
                IP publique

        3.10. Paramtrage d'ipfwadm pour un client VPN avec une adresse
                IP publique

        3.11. Paramtrage d'ipchains pour un serveur VPN avec une adresse
                IP publique

        3.12. Paramtrage d'ipchains pour un client VPN avec une adresse
                IP publique

        3.13. Masquage VPN et LRP
        3.14. Masquage VPN sur un systme tournant avec FreeS/WAN ou
                PoPToP

   4. Configurer le client VPN

        4.1. Configurer un client MS W'95
        4.2. Configurer un client MS W'98
        4.3. Configurer un client MS W'ME
        4.4. Configurer un client MS NT
        4.5. Configuration pour du routage rseau  rseau
        4.6. Masquer des VPNs bass sur SecuRemote de CheckPoint

   5. Dpannage

        5.1. Tests
        5.2. Problmes possibles
        5.3. Dpannage
        5.4. Clients MS PTPP et noms de domaines
        5.5. Clients PPTP MS et IPX Novell
        5.6. Problmes de mots de passe rseau MS
        5.7. Si votre session IPsec meurt automatiquement aprs un
                certain laps de temps

        5.8. Si le masquage VPN ne fonctionne pas aprs le redmarrage
        5.9. Si votre seconde session PPTP tue votre premire session

   6. Notes techniques sur le masquage IPsec et considrations spciales
          sur la scurit

        6.1. Limites et faiblesses du masquage IPsec
        6.2. Routage correct du trafic crypt entrant

1. Introduction

1.1. Introduction

   Ce document dcrit comment configurer le masquage d'un trafic VPN de
   type IPsec ou PPTP. Les VPNs utilisant SSH (comme celui vendu par
   F-Secure, et rfrenc dans le VPN mini-HOWTO) sont fonds sur un
   trafic TCP standard, et ne ncessitent aucune modification
   particulire du noyau.

   Le masquage de VPN vous permet d'tablir une ou plusieurs sessions
   IPsec et/ou PPTP vers des serveurs VPN accessibles sur internet via
   votre pare-feu internet sans que vous deviez connecter la machine sur
   laquelle tourne le client VPN directement  votre FAI (Fournisseur
   d'Accs Internet) - donc en conservant tous les avantages de votre
   pare-feu internet sous Linux. Il vous est galement possible de
   configurer un serveur VPN avec une adresse IP de rseau priv (voir le
   RFC1918) derrire un pare-feu Linux faisant du masquage, vous
   permettant ainsi de fournir de faon assez scurise un accs  un
   rseau priv via seulement une seule adresse IP rfrence - y compris
   si cette adresse IP reprsente celle d'une connexion modem pouvant
   varier.

   Il est trs fortement recommand que vous compreniez, configuriez et
   testiez le masquage IP avant de tenter de mettre en place du masquage
   VPN. Consultez le IP Masquerade HOWTO et la page de ressources sur le
   masquage IP  l'adresse http://ipmasq.cjb.net/ avant de commencer. La
   planification et la mise en place de votre VPN et de votre pare-feu
   dpassent le cadre de ce document. Voici quelques ressources :

     * http://www.linux.org/help/ldp/howto/Firewall-HOWTO.html
     * http://hal2000.hal.vein.hu/~mag/linux-security/VPN-HOWTO.html

   Le patch pour les noyaux de la srie 2.0.x fonctionne bien sur la
   version 2.0.36 du noyau Linux, et a t intgr dans la version
   2.0.37. Il doit galement fonctionner sur les versions antrieures 
   la 2.0.36, et devrait fonctionner sur les noyaux Linux jusqu' la
   version 2.1.102. Le code du masquage IP se trouvant dans le noyau a
   t restructur autour de la version 2.1.103, ncessitant un patch
   diffrent pour les sries de noyaux 2.1.105+ et 2.2.x.. Un patch est
   disponible pour les noyaux de 2.2.5  2.2.17, et il devrait
   fonctionner sur les noyaux antrieurs.
     _________________________________________________________________

1.2. Avis, Crdits & Ressources

   Le site o trouver les patchs du noyau pour le masquage VPN avec Linux
   est http://www.impsec.org/linux/masquerade/ip_masq_vpn.html

   N'hsitez pas  m'envoyer votre avis ou des commentaires sur ce
   document  l'adresse <jhardin@wolfenet.com>. La version actuelle est
   disponible  l'adresse :

     * HTML:
       ftp://ftp.rubyriver.com/pub/jhardin/masquerade/VPN-howto/VPN-Masqu
       erade.html
     * PostScript:
       ftp://ftp.rubyriver.com/pub/jhardin/masquerade/VPN-howto/VPN-Masqu
       erade.ps.gz
     * SGML source:
       ftp://ftp.rubyriver.com/pub/jhardin/masquerade/VPN-Masquerade.sgml

   Si vous travaillez avec un noyau dont le numro de version est
   suprieur  tous ceux mentionns dans ce document, _merci_ de regarder
   s'il n'y a pas une version  jour de ce HOWTO sur le site cit
   ci-dessus avant de me contacter directement.

   Il peut galement tre trouv via le rpertoire HOWTO du Linux
   Documentation Project et le rpertoire /usr/doc/HOWTO/ sur la machine
   Linux la plus proche. Ces copies ne sont pas directement mises  jour
   par moi, donc elles peuvent tre un peu dpasses.

   J'ai personnellement de l'exprience sur le masquage de clients IPsec
   et PPTP tournant sur MS W'98 et NT, sur la configuration d'un serveur
   PPTP avec une adresse IP publique, et sur l'utilisation de PPTP pour
   du routage inter-rseaux.

   Les informations sur le masquage d'un serveur PPTP avec une adresse IP
   prive proviennent de discussions avec Len Bayles <len@isdi.com>,
   Simon Cocking <simon@ibs.com.au> et C. Scott Ananian
   <cananian@lcs.mit.edu>.

   Le site pour le patch du noyau concernant uniquement le masquage PPTP
   pour les sries de noyaux 2.1.105+ et les premiers 2.2.x est
   http://bmrc.berkeley.edu/people/chaffee/linux_pptp.html.

   Le site pour le patch du noyau concernant la redirection de port
   ipportfw et pour l'outil de configuration des noyaux 2.0.x est
   http://www.ox.compsoc.org.uk/~steve/portforwarding.html. La
   redirection de port est incluse dans les noyaux 2.2.x, et l'outil de
   configuration ipmasqadm contrlant la redirection de port des 2.2.x
   peut tre obtenu  l'adresse http://juanjox.kernelnotes.org/.

   Le site pour le redirecteur IP gnrique ipfwd est
   http://www.pdos.lcs.mit.edu/~cananian/Projects/IPfwd/.

   Pleins de remerciements  Gordon Chaffee <chaffee@cs.berkeley.edu>
   pour avoir cod et partag un patch pour traceroute qui permet de
   tracer le trafic GRE. Il va se montrer d'une valeur inestimable pour
   la dtection d'erreurs si votre trafic GRE se trouve bloqu quelque
   part. Le patch est disponible  l'adresse
   http://www.wolfenet.com/~jhardin/pptp-traceroute.patch.gz

   Encore plus de remerciements  Steve Chinatti
   <chinatti@alumni.Princeton.EDU> pour avoir partag sa modification du
   masquage IPsec, d'o j'ai rcupr sans vergogne quelques ides trs
   importantes...

   De plus amples informations sur comment installer des rgles de
   pare-feu s'excutant automatiquement - y compris comment utiliser
   automatiquement la bonne adresse IP dans un environnement d'adressage
   IP dynamique - peuvent se trouver  l'adresse
   http://www.wolfenet.com/~jhardin/ipfwadm/invocation.html

   Le site pour Linux FreeS/WAN (IPsec pour Linux) est
   http://www.xs4all.nl/~freeswan/ - c'est la solution de VPN sous Linux
   conseille.

   Un serveur PPTP Linux natif appel PoPToP est disponible  l'adresse
   http://www.moretonbay.com/vpn/pptp.html - pour les informations les
   plus  jour sur PPTP sous Linux, allez y.

   Paul Cadach <paul@odt.east.telecom.kz> a crit des patchs qui ajoutent
   au pppd de Linux le support MS-CHAP-v2, MPPE et Multilink. Allez voir
   ftp://ftp.east.telecom.kz/pub/src/networking/ppp/ppp-2.3.5-my.tgz pour
   MS-CHAP et MPPE, et
   ftp://ftp.east.telecom.kz/pub/src/networking/ppp/multilink/ppp-2.3.5-m
   p.tgz pour Multilink. Un autre ensemble de patchs (probablement
   intressants) pour pppd est disponible sur le site de tlchargement
   de PoPToP  l'adresse
   http://www.moretonbay.com/vpn/download_pptp.html.

   Le site du projet original PPTP pour Linux est
   http://www.pdos.lcs.mit.edu/~cananian/Projects/PPTP et un patch pour
   ajouter les fonctionnalits de serveur PPTP est disponible  l'adresse
   http://debs.fuller.edu/cgi-bin/display?list=pptp=222

   Merci  Eric Raymond de maintenir Le fichier du Jargon (The Jargon
   File), et  Denis Howe de maintenir Le dictionnaire en ligne gratuit
   de l'informatique (The Free On-line Dictionary of Computing).
     _________________________________________________________________

1.3. Copyright & mise en garde

   Ce document est Coyright  1999-2000 par John D. Hardin. Vous avez la
   permission de le redistribuer sous les termes de la licence LDP,
   disponible  l'adresse http://www.linuxdoc.org/COPYRIGHT.html

   Les informations fournies dans ce document sont correctes dans la
   limite de mon savoir. Le masquage IP est _exprimental_, et il est
   possible que j'aie fait des erreurs en crivant ou testant le patch du
   noyau, ou encore en crivant les instructions dans ce document ; 
   vous de dcider si vous souhaitez effectuer les changements indiqus
   dans ce document.

_L'AUTEUR NE PEUT ETRE TENU RESPONSABLE POUR DES DEGATS CAUSES PAR DES
ACTIONS BASEES SUR LES INFORMATIONS CONTENUES DANS CE DOCUMENT.
SAUVEGARDEZ TOUTES LES DONNEES CRITIQUES AVANT D'EFFECTUER LES
CHANGEMENTS INDIQUES DANS CE DOCUMENT. ASSUREZ VOUS D'AVOIR UN NOYAU
QUI MARCHE, SUR LEQUEL VOUS POUVEZ DEMARRER, AVANT DE PATCHER ET
DE RECOMPILER VOTRE NOYAU COMME INDIQUE DANS CE DOCUMENT._

   En d'autres mots, prenez des prcautions.
     _________________________________________________________________

2. Connaissances requises

2.1. Qu'est-ce qu'un VPN ?

   Un Rseau Priv Virtuel (Virtual Private Network), ou "VPN", est un
   tunnel qui vhicule le trafic d'un rseau priv d'un systme terminal
   vers un autre, en empruntant un rseau public (comme l'internet), sans
   que les intermdiaires entre les deux machines terminales soient
   visibles du point de vue du trafic vhicul, et sans que les
   quipements intermdiaires voient les paquets qui sont en train de
   transiter dans le tunnel. Le tunnel peut en option compresser et/ou
   crypter les donnes, fournissant des performances accrues et quelques
   mesures de scurit.

   La partie "Virtuelle" vient du fait que vous construisez une liaison
   prive au dessus d'un rseau public, plutt que d'acheter une liaison
   en dur sur une ligne loue. Le VPN vous permet de considrer que vous
   utilisez une ligne loue ou une ligne tlphonique pour communiquer
   entre les deux points terminaux.

   Pour information, vous pouvez trouver la FAQ sur le VPN  l'adresse
   http://kubarb.phsx.ukans.edu/~tbird/vpn/FAQ.html.
     _________________________________________________________________

2.2. Qu'est-ce qu'IPsec ?

   _IPsec_ est un ensemble de protocoles standards pour implmenter des
   communications scurises ainsi que l'change de cls de cryptage
   entre ordinateurs. Il peut tre utilis pour mettre en place un VPN.

   Un rseau priv virtuel IPsec consiste gnralement en deux canaux de
   communication entre les machines terminales : un canal d'change de
   cls, par lequel les informations sur l'authentification et les cls
   de cryptage transitent, et un ou plusieurs canaux de donnes par
   lesquels le trafic du rseau priv est vhicul.

   Le canal d'change de cls est une connexion UDP standard en
   provenance de et vers le port 500. Le canal de donnes transportant le
   trafic entre le client et le serveur utilise le protocole IP numro 50
   (ESP).

   Vous pouvez trouver de plus amples informations dans la FAQ IPsec de
   F-Secure,  l'adresse
   http://www.Europe.F-Secure.com/support/vpn+/faq/techfaq.html, et dans
   les RFC2402 (le protocole AH, protocole IP numro 51), RFC2406 (le
   protocole ESP, protocole IP numro 50), et RFC2408 (le protocole
   d'change de cls ISAKMP).

   IPsec est un protocole de communication symtrique. Cependant, vu que
   la plupart des gens vont s'y trouver confront uniquement sous la
   forme d'un client Windows accdant  une passerelle centrale de
   scurit rseau, le terme "client" va tre utilis pour dsigner la
   machine devant laquelle l'utilisateur est assis, et le terme "serveur"
   va tre utilis pour dsigner la passerelle centrale de scurit
   rseau.

   Note importante : si votre VPN est bas sur le protocole AH (y compris
   AH+ESP), il ne peut pas tre masqu. Le protocole AH utilise un
   contrleur d'intgrit cryptographique sur des parties de l'entte IP,
   y compris l'adresse IP. Le masquage IP modifie l'adresse source pour
   les paquets sortants, et l'adresse destination pour les paquets
   entrants. La passerelle de masquage ne pouvant pas participer 
   l'change de cls, elle ne peut pas rgnrer correctement les
   contrleurs d'intgrit cryptographiques pour les enttes IP modifis.
   Les paquets IP modifis seront donc rejets par le destinataire comme
   des paquets invalides, car ils ne passeront pas le test d'intgrit
   cryptographique.
     _________________________________________________________________

2.3. Qu'est-ce que PPTP ?

   _PPTP_ signifie _P_oint-to-_P_oint _T_unnelling _P_rotocol. C'est un
   protocole propos par Microsoft pour raliser un VPN.

   Le protocole VPN PPTP consiste en deux canaux de communication entre
   le client et le serveur : un canal de contrle par lequel les
   informations de gestion du lien transitent, et un canal de donnes par
   lequel le trafic (ventuellement crypt) du rseau priv est vhicul.

   Le canal de contrle est une connexion TCP standard vers le port 1723
   du serveur. Le canal de donnes vhiculant le trafic du rseau priv
   utilise le protocole IP numro 47, un protocole d'encapsulation
   gnrique dcrit dans le RFC1701. La transmission transparente des
   donnes sur le canal de donnes est ralise par la ngociation d'une
   connexion PPP standard sur ce canal, simplement comme s'il s'agissait
   d'une connexion modem directement du client vers le serveur. Les
   options ngocies sur le tunnel via le protocole PPP contrlent si les
   donnes sont compresses et/ou cryptes, et donc PPTP n'a rien  voir
   avec le cryptage.

   Les dtails du protocole PPTP sont documents dans le RFC2637.

   L'implmentation du protocole PPTP par Microsoft n'est pas considre
   comme trs scurise. Si vous tes intresss par les dtails, voici
   trois analyses diffrentes :

   http://www.counterpane.com/pptp.html

   http://www.geek-girl.com/bugtraq/1999_1/0664.html

   http://oliver.efri.hr/~crv/security/bugs/NT/pptp2.html
     _________________________________________________________________

2.4. Qu'est-ce que FWZ ?

   _FWZ_ est un protocole de cryptage propritaire dvelopp par Check
   Point Software Technologies. Il est utilis dans les VPNs qui sont
   construits autour de leur produit Firewall-1.

   Un pare-feu Checkpoint peut tre configur avec diffrents modes. Le
   mode d' "encapsulation FWZ" _ne peut pas_ tre masqu. Le mode "IKE",
   qui utilise les protocoles standards IPsec, peut tre masqu avec des
   changements de configuration minimes sur la passerelle VPN.
     _________________________________________________________________

2.5. Pourquoi masquer un client VPN ?

   La plupart des clients VPN actuels partent du principe que vous allez
   connecter l'ordinateur client directement  internet. Faire cela
   lorsque vous n'avez qu'une seule connexion d'accs internet contourne
   votre pare-feu Linux, la scurit, ainsi que les capacits de partage
   d'accs qu'il fournit. tendre le pare-feu Linux pour aussi masquer le
   trafic VPN vous permet de conserver la scurit pare-feu fournie par
   le pare-feu Linux, ainsi que d'autoriser d'autres systmes de votre
   rseau local  accder  internet, sans avoir  prendre en compte le
   fait que la connexion VPN soit active ou non.

   Si votre pare-feu est utilis en environnement professionnel, vous
   pouvez galement souhaiter imposer aux utilisateurs clients du VPN de
   traverser ce pare-feu pour des raisons de scurit, plutt que de leur
   fournir des modems pour qu'ils puissent se connecter tout seuls 
   l'extrieur quand ils ont besoin d'utiliser le VPN. Le masquage VPN
   vous permet de le faire mme si les machines clientes n'ont pas des
   adresses IP publiques.
     _________________________________________________________________

2.6. Plusieurs clients sur mon rseau local peuvent-ils utiliser IPsec
simultanment ?

   Oui, bien qu'il puisse y avoir parfois quelques problmes mineurs.

   Les protocoles IPsec dfinissent une mthode pour identifier les flux
   de trafic appele _Index des Paramtres de Scurit (Security
   Parameters Index) _("SPI"). Malheureusement le SPI utilis pour le
   trafic sortant est diffrent du SPI utilis pour le trafic entrant, et
   il n'y a pas d'autre information permettant l'identification qui ne
   soit pas crypte, donc l'association entre le flux entrant et le flux
   sortant est difficile et pas parfaitement fiable.

   Le masquage IPsec tente d'associer les trafics ESP entrant et sortant
   en mettant en srie les nouvelles connexions. Alors que ceci
   fonctionne bien pendant les tests, on ne peut pas garantir que ce soit
   parfaitement fiable, et la srialisation des nouveaux trafics peut
   aboutir  des fins d'attente (timeouts) si la liaison est sature ou
   si plusieurs machines locales faisant de l'IPsec tentent d'initier des
   communications ou de rchanger leurs cls simultanment, avec la mme
   machine distante faisant de l'IPsec.

   Il est galement reconnu que ce schma associatif peut ne pas arriver
    associer les flux de trafic correctement, les machines faisant de
   l'IPsec ne vont alors pas prendre en compte le trafic mal dirig, car
   il aura de mauvaises valeurs SPI. Ce comportement est requis par le
   RFC sur IPsec.

   Ces problmes auraient pu tre supprims s'il y avait eu un moyen
   d'couter les nouvelles valeurs SPI provenant de l'change de cls
   ISAKMP avant que le moindre trafic ESP n'apparaisse, mais
   malheureusement cette partie de l'change de cls est crypte.

   Afin de minimiser les problmes associs  cela, il est recommand
   d'ouvrir une fentre de commandes sur votre machine IPsec masque, et
   de lancer le programme "ping" vers une machine du rseau distant pour
   maintenir le tunnel actif.

   Regardez les notes techniques sur IPsec  la fin du document pour de
   plus amples dtails.
     _________________________________________________________________

2.7. Plusieurs clients sur mon rseau local peuvent-ils utiliser PPTP
simultanment ?

   Oui.

   Vous devez mettre en place le masquage d'identifiant d'appel PPTP
   (PPTP Call ID) lors de la configuration de votre noyau, afin de
   distinguer les diffrents flux de donnes en provenance du mme
   serveur. Le masquage PPTP avec le masquage d'identifiant d'appel
   activ va permettre d'avoir plusieurs sessions masques simultanes
   sans restriction sur le choix du serveur que le client appelle.

   Le RFC sur PPTP spcifie dans la section 3.1.3 qu'il ne peut y avoir
   qu'un seul canal de contrle entre deux systmes. Ceci _devrait_
   signifier que vous pouvez masquer seulement une session PPTP  la fois
   avec un serveur distant donn, mais dans la pratique l'implmentation
   PPTP de MS ne tient pas compte de a, tout du moins pas dans le
   Service Pack 4 de NT 4.0. Si le serveur PPTP que vous cherchez 
   atteindre n'autorise qu'une seule connexion  la fois, il suit
   correctement le protocole. Notez que cela n'affecte pas un serveur
   masqu, mais seulement plusieurs clients masqus cherchant  se
   connecter au mme serveur distant.

   Pour d'autres alternatives, voir la question suivante...
     _________________________________________________________________

2.8. Puis-je accder au rseau distant depuis l'ensemble de mon rseau local
?

   Oui. Cependant, votre client VPN doit pouvoir faire suivre un trafic
   IP (IP forwarding).

   Ceci signifie que vous devrez utiliser soit un client VPN Linux ou un
   client VPN MS NT. La pile IP de W'95 et W'98 ne permet pas de faire
   suivre un trafic IP. NT Workstation le gre, et est moins cher que NT
   Server si vous ne l'utilisez que pour router un trafic crypt.

   Si vous ne pouvez pas installer un client Linux ou NT, alors vous
   devrez activer le masquage d'identifiant d'appel PPTP si vous utilisez
   PPTP, et installer un logiciel client VPN sur toutes les machines
   auxquelles vous voulez fournir un accs. Ceci est peu efficace,
   esthtiquement rvoltant, scuritairement mauvais, et peut ne pas
   fonctionner si le serveur PPTP implmente correctement le protocole,
   mais c'est moins cher que d'acheter des licences NT.

   Le routage rseau  rseau avec cette mthode fonctionne trs bien.
   C'est comme a que j'ai install mon rseau  la maison. Cela requiert
   un petit peu plus de connaissances rseau que de simplement donner 
   tout le monde son client VPN.

   De par mon exprience, le routage de rseau  rseau dans un
   environnement purement MS requiert l'installation de RRAS des deux
   cts du tunnel.
     _________________________________________________________________

2.9. Pourquoi masquer le serveur VPN ?

   Si votre serveur VPN a une adresse IP publique, vous n'avez pas besoin
   de le masquer, configurez simplement votre pare-feu pour router le
   trafic VPN correctement, comme indiqu plus bas.

   Si votre serveur VPN a une adresse IP de rseau priv, vous aurez
   besoin de rediriger vers lui le trafic entrant, et de masquer son
   trafic sortant. Le masquage vous permet de rendre le serveur VPN
   accessible depuis internet mme si vous n'avez qu'une seule adresse IP
   publique. Ceci devrait aussi fonctionner mme si votre adresse IP est
   assigne dynamiquement : rendez simplement publique l'adresse IP pour
   les clients au travers de l'utilisation d'un service de DNS dynamique
   externe, comme par exemple celui fourni par DDNS.ORG ou CJB.NET et
   configurez les clients pour se connecter  une machine appele
   notre-entreprise.ddns.org ou quelque chose du genre. Notez que ceci
   est une faille de scurit, car il est possible que le client rcupre
   du serveur DNS dynamique une mauvaise adresse IP  cause d'une
   mauvaise synchronisation, suite  un problme lors de l'enregistrement
   de l'adresse IP actuelle, ou suite  l'enregistrement d'une adresse IP
   diffrente avec le mme nom par une tierce partie.
     _________________________________________________________________

2.10. Pourquoi patcher le noyau Linux ?

   Le plus gros problme dans le masquage de trafic VPN vient du fait que
   le masquage IP Linux de base n'a aucune connaissance des protocoles IP
   autres que TCP, UDP et ICMP.

   Tout le trafic peut tre redirig et filtr par adresse IP, mais le
   masquage de protocoles IP autres que TCP, UDP et ICMP ncessite une
   modification du noyau.

   Le canal de contrle PPTP est du TCP pur, et ne ncessite aucune
   configuration particulire autre que de le laisser passer au travers
   du pare-feu et de le masquer.

   Masquer les canaux de donnes IPsec et PPTP ncessite une modification
   qui ajoute le support des protocoles ESP et GRE au code de masquage,
   et le masquage du protocole d'change de cls ISAKMP ncessite une
   modification qui empche l'opration de masquage de modifier le numro
   de port UDP source et qui remplace le suivi des valeurs de cookies
   ISAKMP par le suivi du numro de port.
     _________________________________________________________________

2.11. tat actuel

   Le patch pour les noyaux 2.0.x fonctionne sur le noyau 2.0.36 et est
   inclus dans les versions standards des noyaux 2.0.37 et suprieurs. Il
   devrait fonctionner sur les noyaux antrieurs, mais je n'ai pas test,
   et je vous recommande, si vous utilisez un noyau plus ancien, de
   passer au noyau 2.0.38 pour des questions de scurit.

   Le patch pour les noyaux 2.2.x fonctionne sur les noyaux de 2.2.5 
   2.2.17, et devrait fonctionner sur les noyaux plus rcents, mais a
   n'a pas t test. Il a t soumis pour tre inclus dans la version
   standard 2.2.18.

   Je n'ai pas les moyens de suivre les noyaux de dveloppement, donc
   actuellement aucun travail n'a t fait sur le masquage VPN pour les
   2.3.x et 2.4.x. Si vous connaissez quelqu'un qui _travaille_ dessus,
   merci de me le faire savoir.

   Le patch pour les noyaux 2.0.x a t test et fonctionne sur les
   machines  base de x86 et sparc, et le patch pour les noyaux 2.2.x a
   t test et fonctionne sur les machines  base de x86 et PowerPC,
   mais il ne devrait pas y avoir de problme majeur pour le porter sur
   d'autres architectures. Je crois que les dpendances vis--vis des
   architectures proviennent seulement de la reprsentation interne des
   nombres dans la dfinition de l'entte GRE utilis pour formater les
   messages du journal et de dboguage. Si quelqu'un porte ce patch pour
   une architecture autre qu'Intel, j'apprcierais d'en avoir un cho,
   afin que je puisse intgrer les changements  la version d'origine.

   Un patch noyau spcifique  PPTP pour les noyaux 2.1.105+ et les
   premiers 2.2.x est disponible  l'adresse
   http://bmrc.berkeley.edu/people/chaffee/linux_pptp.html.

   Allez voir le site sur le masquage VPN  l'adresse
   http://www.impsec.org/linux/masquerade/ip_masq_vpn.html pour l'tat
   des patchs de masquage VPN, et
   http://bmrc.berkeley.edu/people/chaffee/linux_pptp.html pour l'tat du
   patch de masquage spcifique pour PPTP s'appliquant aux
   2.1.105+/2.2.x.
     _________________________________________________________________

3. Configurer le pare-feu Linux

3.1. Exemple de rseau

   Pour les exemples de configuration avec des adresses IP prives de ce
   document, nous allons utiliser cet exemple de rseau :
Internet-------- 200.200.200.*   ppp0 ou  200.200.200.200 eth1
                                 Pare-feu Linux  deux cartes
            .--- 10.0.0.1        eth0
            |
            |--- 10.0.0.2        Client ou serveur VPN
            |

   Pour les exemples de configuration avec des adresses IP publiques de
   ce document, nous allons utiliser cet exemple de rseau :
Internet-------- 200.200.200.200 eth1
                                 Pare-feu Linux  deux cartes
            .--- 222.0.0.1       eth0
            |
            |--- 222.0.0.2       Client ou serveur VPN
            |

   Le serveur VPN auquel les clients des exemples se connecteront sera
   199.0.0.1

   Les clients VPN qui se connecteront au serveur des exemples seront
   199.0.0.2 et 199.0.0.3
     _________________________________________________________________

3.2. Dterminer ce qui doit tre fait sur le pare-feu

   Si votre client ou serveur VPN a une adresse IP publique, vous n'avez
   _pas_ besoin de faire du masquage ni de modifier votre noyau - le noyau
   de base va correctement router tout trafic VPN. Vous pouvez
   directement passer aux sections ci-dessous sur la mise en place avec
   adresse IP publique.

   Si votre client ou serveur VPN a une adresse IP de rseau priv comme
   dcrit dans le RFC1918 vous avez besoin de patcher votre noyau (
   moins que ce ne soit un noyau 2.0.37 ou suprieur, dans la srie
   2.0.x).

   Si vous installez un serveur VPN masqu, vous allez aussi devoir
   rcuprer les deux paquetages suivants.

     * Pour rediriger le trafic TCP/UDP entrant (le canal de contrle
       PPTP 1723/tcp ou le canal ISAKMP 500/udp), vous avez besoin du
       patch noyau de redirection de port appropri ipportfw rcuprable
       sur http://www.ox.compsoc.org.uk/~steve/portforwarding.html. La
       redirection de port a t incorpore dans les noyaux 2.2.x.
       Regardez man ipmasqadm pour les dtails de configuration. Si
       ipmasqadm n'est pas inclus dans votre distribution, il peut tre
       obtenu  l'adresse http://juanjox.kernelnotes.org/.
     * Pour rediriger le tunnel contenant le trafic initial entrant (GRE
       pour PPTP et ESP pour IPsec), vous avez besoin du redirecteur IP
       gnrique ipfwd, qui se trouve sur
       http://www.pdos.lcs.mit.edu/~cananian/Projects/IPfwd/.

   Vous n'avez _pas_ besoin de redirection de port ni d'ipfwd si vous ne
   masquez que les clients.
     _________________________________________________________________

3.3. Patcher et configurer le noyau 2.0.x pour le support de masquage VPN

    1. Installez les sources du noyau (de prfrence version 2.0.37), que
       vous pouvez obtenir sur http://www.kernel.org/ ou un site miroir.
       Les sources doivent se dcompacter automatiquement dans le
       rpertoire /usr/src/linux.
    2. Configurer et tester le masquage IP standard (regardez le IP
       Masquerade HOWTO). Ceci va vous permettre de vous familiariser
       avec la recompilation de votre noyau, et plus largement, vous
       faire aborder le masquage IP.
    3. _Sauvegardez les sources de votre noyau._
    4. Rcuprez le patch noyau si ncessaire.
       Si la version de votre noyau est 2.0.36 ou infrieure, rcuprez
       le patch du masquage VPN pour noyau 2.0.x sur le site du masquage
       VPN list dans la section "Ressources" plus haut.
       Si la version de votre noyau est 2.0.37 ou plus dans la srie
       2.0.x, vous n'avez pas besoin d'appliquer de patch. Le code du
       masquage VPN est inclus dans le noyau. Passez la discussion sur le
       le patch du noyau.
       Pour les besoins de ce document, nous supposerons que vous avez
       sauvegard le patch appropri sous le chemin
       /usr/src/ip_masq_vpn.patch.gz.
    5. Appliquez le patch de masquage VPN  votre noyau, si ncessaire :
          + Allez dans le rpertoire des sources du noyau :

cd /usr/src/linux

          + Appliquez le patch :

zcat ../ip_masq_vpn.patch.gz | patch -l -p0 > vpn-patch.log 2>&1

Notez que les options sont "tiret L minuscule, tiret P minuscule
zero".
Vous pourriez avoir des rsultats tranges si vous changez l'ordre des
arguments, car la commande patch semble sensible  l'ordre dans lequel
ils apparaissent sur la ligne de commande.

          + Vrifiez le contenu du fichier vpn-patch.log pour voir si
            certaines tapes ont chou. Si certaines tapes n'ont pas
            fonctionn, alors vous avez srement oubli des options, ou
            lanc le programme patch depuis le mauvais rpertoire.
            Utilisez votre sauvegarde pour rcuprer votre noyau, et
            recommencez.
    6. Si vous masquez un serveur VPN, rcuprez et installez le patch
       ipportfw depuis le site indiqu plus haut.
       Il existe un conflit connu entre le patch de masquage VPN et deux
       autres patchs rseau : le patch de chanes pare-feu IP (ipchains),
       et le patch ipportfw. Ils cherchent tous  ajouter des options au
       mme endroit dans net/ipv4/Config.in, et les changements effectus
       par un patch altrent le contexte recherch par les autres patchs.
       Si vous appliquez le patch de masquage VPN et les patchs de
       chanes pare-feu IP ou ipportfw sur votre noyau 2.0.x, vous allez
       devoir diter  la main le fichier net/ipv4/Config.in et ajouter
       le bloc des options de configuration du fichier patch qui n'ont
       pas t appliques. En regardant le fichier patch vous devez
       trouver o les nouvelles options doivent tre ajoutes dans le
       fichier net/ipv4/Config.in.
       La syntaxe des fichiers patch est simple. Pour chaque bloc de
       changements  effectuer, il y a 2 parties : la premire indique
       l'tat "avant" avec une indication des lignes devant tre changes
       ou effaces ; la seconde indique l'tat "aprs", avec une
       indications des lignes qui ont t changes ou ajoutes. Utilisez
       la premire partie pour trouver o ajouter les lignes, et ajoutez
       les lignes qui sont indiques dans la seconde partie.
       Ceci ne devrait pas tre un problme, ces patchs tant  jour pour
       les noyaux 2.0.37+.
    7. Configurez votre noyau et slectionnez les options suivantes -
       rpondez _YES_  ce qui suit :

  * Prompt for development and/or incomplete code/drivers
    CONFIG_EXPERIMENTAL
        - Vous devez l'activer pour voir les options de masquage VPN

  * Networking support
    CONFIG_NET

  * Network firewalls
    CONFIG_FIREWALL

  * TCP/IP networking
    CONFIG_INET

  * IP: forwarding/gatewaying
    CONFIG_IP_FORWARD

  * IP: firewalling
    CONFIG_IP_FIREWALL

  * IP: masquerading (EXPERIMENTAL)
    CONFIG_IP_MASQUERADE
        - Option ncessaire.

  * IP: PPTP masq support (EXPERIMENTAL)
    CONFIG_IP_MASQUERADE_PPTP
        - Active le masquage de canal de donnes PPTP, si vous
          masquez un client ou un serveur PPTP.

  * IP: PPTP Call ID masq support (EXPERIMENTAL)
    CONFIG_IP_MASQUERADE_PPTP_MULTICLIENT
        - Active le masquage d'identifiant d'appel PPTP; ncessaire
          uniquement si vous comptez masquer plusieurs clients
          se connectant au mme serveur distant. N'activez PAS
          cette option si vous masquez un serveur PPTP.

  * IP: IPsec ESP & ISAKMP masq support (EXPERIMENTAL)
    CONFIG_IP_MASQUERADE_IPSEC
        - Active le masquage IPsec, si vous masquez une machine
          IPsec.

  * IP: IPSEC masq table lifetime (minutes)
        - Voyez avec votre administrateur rseau pour dterminer
          quel est "l'intervalle de renouvellement des cls"
          ou la "dure de validit d'une cl".
          La dure de validit par dfaut pour les entres de la
          table de masquage est de trente minutes.
          Si l'intervalle de renouvellement des cls est suprieur
           trente minutes, vous devez alors augmenter la dure
          de validit jusqu' une valeur lgrement suprieure
           l'intervalle de renouvellement des cls.

  * IP: always defragment
    CONFIG_IP_ALWAYS_DEFRAG
        - Trs fortement recommand pour un pare-feu.

       _NOTE :_ ce ne sont que les lments dont vous avez besoin pour le
       masquage. Slectionnez galement toutes les autres options dont
       vous avez besoin pour votre configuration spcifique.
    8. Recompilez le noyau, et installez-le pour le tester. Ne remplacez
       pas un noyau qui marche par votre nouveau noyau tant que vous
       n'avez pas vrifi qu'il fonctionnait.

   Pour dterminer si le noyau qui tourne inclut ou non le support du
   masquage VPN, lancez la commande suivante :
   grep -i masq /proc/ksyms

   ...et cherchez les entres suivantes :

     * Masquage IPsec : ip_masq_out_get_isakmp, ip_masq_in_get_isakmp,
       ip_fw_masq_esp et ip_fw_demasq_esp
     * Masquage PPTP : ip_fw_masq_gre et ip_fw_demasq_gre
     * Masquage d'identifiant d'appel PPTP : ip_masq_pptp

   Si vous ne trouvez pas ces entres, le masquage VPN n'est probablement
   pas support. Si vous avez des messages d'erreurs sur
   l'indisponibilit de /proc/ksyms ou de /proc, assurez-vous d'avoir
   activ le systme de fichiers /proc dans la configuration de votre
   noyau.

   Regardez le Kernel HOWTO pour plus de dtails sur la configuration et
   la recompilation de votre noyau.

   Si vous utilisez le masquage IPsec et que votre systme gnre des
   erreurs de protection gnrale (regardez /var/log/messages) ou bien se
   bloque, regardez le site du masquage VPN pour une mise  jour. Ce
   patch est pour le noyau 2.0.38, mais devrait fonctionner sur les
   noyaux antrieurs. Il a t soumis  Alan Cox pour tre inclus dans le
   noyau 2.0.39.
     _________________________________________________________________

3.4. Patcher et configurer le noyau 2.2.x pour le support de masquage VPN

    1. Installez les sources du noyau (de prfrence version 2.2.17 ou
       plus), que vous pouvez obtenir sur http://www.kernel.org/ ou un
       miroir. Les sources doivent tre automatiquement extraites dans le
       rpertoire /usr/src/linux.
    2. Configurez et testez le masquage IP standard (regardez le IP
       Masquerade HOWTO). Ceci va vous permettre de vous familiariser
       avec la recompilation de votre noyau, et plus largement, vous
       faire aborder le masquage IP.
    3. _Sauvegardez les sources de votre noyau._
    4. Rcuprez le patch noyau depuis le site du masquage VPN indiqu
       dans la section "Ressources" plus haut.
       Pour les besoins de ce document, nous supposerons que vous avez
       sauvegard le patch appropri sous /usr/src/ip_masq_vpn.patch.gz.
    5. Appliquez le patch de masquage VPN  votre noyau, si ncessaire.
          + Allez dans le rpertoire des sources :

cd /usr/src

          + Appliquez le patch :

zcat ip_masq_vpn.patch.gz | patch -l -p0 > vpn-patch.log 2>&1

Notez que les options sont "tiret L minuscule, tiret P minuscule zro".
Vous pourriez avoir des rsultats tranges si vous changez l'ordre des argument
s,
car la commande patch semble sensible  l'ordre dans lequel ils apparaissent su
r
la ligne de commande.

Notez galement que le rpertoire depuis lequel vous lancez la commande
patch est diffrent pour le patch noyau 2.2.x.

          + Vrifiez le contenu du fichier vpn-patch.log pour voir si
            certaines tapes ont chou. Si des tapes ont chou, alors
            vous avez srement oubli des options, ou lanc la commande
            patch depuis le mauvais rpertoire. Utilisez votre sauvegarde
            pour rcuprer votre noyau, et recommencez.
    6. Si vous masquez un serveur VPN, vous n'avez _pas_ besoin du patch
       ipportfw car la redirection de port est maintenant de base.
       Regardez la page de manuel de ipmasqadm pour de plus amples
       dtails. Si ipmasqadm n'est pas inclus dans votre distribution,
       vous pouvez l'obtenir  l'adresse http://juanjox.kernelnotes.org/.
    7. Configurez votre noyau et slectionnez les options suivantes -
       rpondez _YES_  ce qui suit :

  * Prompt for development and/or incomplete code/drivers
    CONFIG_EXPERIMENTAL
        - Vous devez l'activer pour voir les options de masquage VPN.

  * Networking support
    CONFIG_NET

  * Network firewalls
    CONFIG_FIREWALL

  * TCP/IP networking
    CONFIG_INET

  * IP: firewalling
    CONFIG_IP_FIREWALL

  * IP: always defragment
    CONFIG_IP_ALWAYS_DEFRAG
        - Ncessaire pour le masquage. Cette option peut tre
          ou ne pas tre dans la configuration de votre
          noyau. Si elle n'est pas prsente, vous
          devez excuter ceci dans vos scripts de dmarrage :
        echo 1 > /proc/sys/net/ipv4/ip_always_defrag

  * IP: masquerading (EXPERIMENTAL)
    CONFIG_IP_MASQUERADE
        - Option ncessaire.

  * IP: masquerading special modules support
    CONFIG_IP_MASQUERADE_MOD
        - Option ncessaire.

  * IP: ipportfw masq support (EXPERIMENTAL)
    CONFIG_IP_MASQUERADE_IPPORTFW
        - Activer cette option va vous permettre de masquer un serveur VPN.

  * IP: PPTP masq support
    CONFIG_IP_MASQUERADE_PPTP
        - Active le masquage de canal de donnes PPTP, si vous
          masquez un client ou un serveur PPTP. Cette option
          est maintenant disponible en module.
          Notez que vous n'avez plus besoin de spcifier
          le masquage d'identifiant d'appel.

  * IP: IPsec ESP & ISAKMP masq support (EXPERIMENTAL)
    CONFIG_IP_MASQUERADE_IPSEC
        - Active le masquage IPsec, si vous masquez une machine
          IPsec. Cette option est maintenant disponible en module.

  * IP: IPsec masq table lifetime (minutes)
        - Voyez avec votre administrateur rseau pour dterminer
          quel est "l'intervalle de renouvellement des cls"
          ou "la dure de validit d'une cl".
          La dure de validit par dfaut pour les entres de la
          table de masquage est de trente minutes.
          Si l'intervalle de renouvellement des cls est suprieur
           trente minutes, vous devez alors augmenter la dure
          de validit jusqu' une valeur lgrement suprieure
           l'intervalle de renouvellement des cls.

  * IP: Enable parallel sessions (possible security risk - see help)
    CONFIG_IP_MASQUERADE_IPSEC_PAROK
        - Regardez les notes techniques sur le masquage IPsec et
          la section spciale sur les informations sur la scurit de ce HOWTO
          pour tre au courant des problmes de scurit lorsque
          vous faites du masquage. Si vous ne masquez qu'un seul client
          IPsec, cette option n'a aucun effet.

       Rpondez _NO_  ce qui suit :

  * IP: GRE tunnels over IP
    CONFIG_NET_IPGRE
        - Cette option n'a, contrairement aux apparences,
          *RIEN*  voir avec PPTP. Elle active le support
          pour les tunnels GRE tels qu'ils sont utiliss
          par les routeurs Cisco. Le fait que vous voyiez
          cette option n'implique pas que le support de
          PPTP est disponible. Vous devez toujours appliquer
          le patch pour le masquage VPN si les options
          PPTP listes ci-dessus n'apparaissent pas lorsque
          vous configurez votre noyau. N'activez PAS cette
          option, sauf si vous implmentez un tunnel GRE
          vers un routeur Cisco.

       _NOTE :_ ce ne sont que les options dont vous avez besoin pour
       faire du masquage. Slectionnez galement toutes les autres
       options dont vous avez besoin pour votre configuration spcifique.
    8. Recompilez le noyau et installez-le pour le tester. Ne remplacez
       jamais un noyau qui fonctionne par votre nouveau noyau tant que
       vous n'avez pas la preuve qu'il fonctionne.

   Pour savoir si le noyau qui tourne contient le support de masquage
   VPN, lancez la commande suivante :
   grep -i masq /proc/ksyms

   ...et cherchez les entres suivantes :

     * Masquage IPsec : ip_masq_esp et ip_demasq_esp
     * Masquage PPTP : ip_masq_pptp_tcp et ip_demasq_pptp_tcp

   Ou lancez :
   lsmod

   ...et cherchez les entres suivantes :

     * Masquage IPsec : ip_masq_ipsec
     * Masquage PPTP : ip_masq_pptp

   Si vous ne voyez pas ces entres, le support de masquage VPN n'est
   probablement pas activ - avez-vous bien tap modprobe ip_masq_pptp.o
   ou modprobe ip_masq_ipsec.o si vous les avez compils en modules ? Si
   le masquage VPN ne fonctionne plus aprs le redmarrage de la machine,
   avez-vous insr les commandes modprobe dans votre fichier de
   dmarrage /etc/rc.d/rc.local ?

   Si vous avez des messages d'erreur sur l'indisponibilit de
   /proc/ksyms ou de /proc, assurez-vous d'avoir activ le systme de
   fichiers /proc lors de la configuration de votre noyau.

   Allez voir le Kernel HOWTO pour de plus amples informations sur la
   configuration et la recompilation de votre noyau.
     _________________________________________________________________

3.5. Paramtrage de ipfwadm pour un client ou un serveur VPN avec une
adresse IP prive

   Le pare-feu doit maintenant tre configur pour masquer le trafic VPN
   sortant. Vous pouvez souhaiter jeter un coup d'oeil sur
   http://www.wolfenet.com/~jhardin/ipfwadm.html pour voir une interface
   graphique pour la commande ipfwadm qui automatise une grande partie du
   paramtrage du filtrage de paquets au niveau de la scurit.

   Les rgles pare-feu minimales sont :
# Met la politique par dfaut de transmission des paquets  REFUS
ipfwadm -F -p deny
# Autorise le trafic sur le rseau local
ipfwadm -I -a accept    -S 10.0.0.0/8 -D 0.0.0.0/0  -W eth0
ipfwadm -O -a accept    -S 0.0.0.0/0  -D 10.0.0.0/8 -W eth0
# Masque le trafic pour les adresses internet et autorise le trafic internet
ipfwadm -F -a accept -m -S 10.0.0.0/8 -D 0.0.0.0/0  -W ppp0
ipfwadm -O -a accept    -S 0.0.0.0/0  -D 0.0.0.0/0  -W ppp0
ipfwadm -I -a accept    -S 0.0.0.0/0  -D 0.0.0.0/0  -W ppp0
ou, si vous avez une connexion permanente,
ipfwadm -F -a accept -m -S 10.0.0.0/8 -D 0.0.0.0/0  -W eth1
ipfwadm -O -a accept    -S 0.0.0.0/0  -D 0.0.0.0/0  -W eth1
ipfwadm -I -a accept    -S 0.0.0.0/0  -D 0.0.0.0/0  -W eth1

   Mais ce paramtrage est compltement ouvert. Il va permettre de
   masquer _tous_ les trafics en provenance de _toutes_ les machines du
   rseau interne destin  _n'importe quelle_ machine sur internet, et
   ne met en place absolument _aucune_ scurit.

   Un paramtrage de pare-feu rigoureux n'autoriserait que le trafic
   entre le client et le serveur, et bloquerait tout le reste :
# Met la politique par dfaut  REFUS :
ipfwadm -I -p deny
ipfwadm -O -p deny
ipfwadm -F -p deny
# Autorise le trafic sur le rseau local
ipfwadm -I -a accept -S 10.0.0.0/8 -D 0.0.0.0/0  -W eth0
ipfwadm -O -a accept -S 0.0.0.0/0  -D 10.0.0.0/8 -W eth0
# Masque uniquement le trafic VPN entre le client VPN et le serveur VPN
ipfwadm -F -a accept -m -P udp -S 10.0.0.2/32 500 -D 199.0.0.1/32 500  -W ppp0
ipfwadm -F -a accept -m -P tcp -S 10.0.0.2/32     -D 199.0.0.1/32 1723 -W ppp0
ipfwadm -F -a deny      -P tcp -S 10.0.0.2/32     -D 199.0.0.1/32      -W ppp0
ipfwadm -F -a deny      -P udp -S 10.0.0.2/32     -D 199.0.0.1/32      -W ppp0
ipfwadm -F -a accept -m -P all -S 10.0.0.2/32     -D 199.0.0.1/32      -W ppp0
ipfwadm -O -a accept    -P udp -S 200.200.200.0/24 500 -D 199.0.0.1/32 500  -W
ppp0
ipfwadm -O -a accept    -P tcp -S 200.200.200.0/24     -D 199.0.0.1/32 1723 -W
ppp0
ipfwadm -O -a deny      -P tcp -S 200.200.200.0/24     -D 199.0.0.1/32      -W
ppp0
ipfwadm -O -a deny      -P udp -S 200.200.200.0/24     -D 199.0.0.1/32      -W
ppp0
ipfwadm -O -a accept    -P all -S 200.200.200.0/24     -D 199.0.0.1/32      -W
ppp0
ipfwadm -I -a accept    -P udp -S 199.0.0.1/32 500     -D 200.200.200.0/24 500
-W ppp0
ipfwadm -I -a accept    -P tcp -S 199.0.0.1/32 1723    -D 200.200.200.0/24
-W ppp0
ipfwadm -I -a deny      -P tcp -S 199.0.0.1/32         -D 200.200.200.0/24
-W ppp0
ipfwadm -I -a deny      -P udp -S 199.0.0.1/32         -D 200.200.200.0/24
-W ppp0
ipfwadm -I -a accept    -P all -S 199.0.0.1/32         -D 200.200.200.0/24
-W ppp0
ou, si vous avez une connexion permanente
ipfwadm -F -a accept -m -P udp -S 10.0.0.2/32 500 -D 199.0.0.1/32 500  -W eth1
ipfwadm -F -a accept -m -P tcp -S 10.0.0.2/32     -D 199.0.0.1/32 1723 -W eth1
ipfwadm -F -a deny      -P tcp -S 10.0.0.2/32     -D 199.0.0.1/32      -W eth1
ipfwadm -F -a deny      -P udp -S 10.0.0.2/32     -D 199.0.0.1/32      -W eth1
ipfwadm -F -a accept -m -P all -S 10.0.0.2/32     -D 199.0.0.1/32      -W eth1
ipfwadm -O -a accept    -P udp -S 200.200.200.200/32 500 -D 199.0.0.1/32 500  -
W eth1
ipfwadm -O -a accept    -P tcp -S 200.200.200.200/32     -D 199.0.0.1/32 1723 -
W eth1
ipfwadm -O -a deny      -P tcp -S 200.200.200.200/32     -D 199.0.0.1/32      -
W eth1
ipfwadm -O -a deny      -P udp -S 200.200.200.200/32     -D 199.0.0.1/32      -
W eth1
ipfwadm -O -a accept    -P all -S 200.200.200.200/32     -D 199.0.0.1/32      -
W eth1
ipfwadm -I -a accept    -P udp -S 199.0.0.1/32 500  -D 200.200.200.200/32 500 -
W eth1
ipfwadm -I -a accept    -P tcp -S 199.0.0.1/32 1723 -D 200.200.200.200/32     -
W eth1
ipfwadm -I -a deny      -P tcp -S 199.0.0.1/32      -D 200.200.200.200/32     -
W eth1
ipfwadm -I -a deny      -P udp -S 199.0.0.1/32      -D 200.200.200.200/32     -
W eth1
ipfwadm -I -a accept    -P all -S 199.0.0.1/32      -D 200.200.200.200/32     -
W eth1

   Note : ces rgles n'autorisent que le trafic VPN et bloquent _tout le
   reste_. Vous devez ajouter des rgles pour tous les autres flux que
   vous voulez autoriser, comme par exemple DNS, HTTP, POP, IMAP, etc...
     _________________________________________________________________

3.6. Paramtrage d'ipchains pour un client ou serveur VPN avec une adresse
IP prive

   Les rgles pare-feu ipchains minimales sont :
# Met la politique par dfaut de transmission des paquets  REFUS
ipchains -P forward DENY
# Autorise le trafic sur le rseau local
ipchains -A input   -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0  -i eth0
ipchains -A output  -j ACCEPT -s 0.0.0.0/0  -d 10.0.0.0/8 -i eth0
# Masque le trafic vers les adresses internet et autorise le trafic internet
ipchains -A forward -j MASQ   -s 10.0.0.0/8 -d 0.0.0.0/0  -i ppp0
ipchains -A output  -j ACCEPT -s 0.0.0.0/0  -d 0.0.0.0/0  -i ppp0
ipchains -A input   -j ACCEPT -s 0.0.0.0/0  -d 0.0.0.0/0  -i ppp0
ou, si vous avez une connexion permanente,
ipchains -A forward -j MASQ   -s 10.0.0.0/8 -d 0.0.0.0/0  -i eth1
ipchains -A output  -j ACCEPT -s 0.0.0.0/0  -d 0.0.0.0/0  -i eth1
ipchains -A input   -j ACCEPT -s 0.0.0.0/0  -d 0.0.0.0/0  -i eth1

   Mais ce paramtrage est compltement ouvert. Il va permettre de
   masquer _tous_ les trafics en provenance de _toutes_ les machines du
   rseau interne destin  _n'importe quelle_ machine sur internet, et
   ne met en place absolument _aucune_ scurit.

   Un paramtrage de pare-feu rigoureux n'autoriserait que le trafic
   entre le client et le serveur, et bloquerait tout le reste :
# Met la politique par dfaut  REFUS :
ipchains -P input   DENY
ipchains -P output  DENY
ipchains -P forward DENY
# Autorise le trafic sur le rseau local
ipchains -A input  -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0  -i eth0
ipchains -A output -j ACCEPT -s 0.0.0.0/0  -d 10.0.0.0/8 -i eth0
# Masque uniquement le trafic VPN entre le client VPN et le serveur VPN
# IPsec
ipchains -A forward -j MASQ   -p udp -s 10.0.0.2/32 500      -d 199.0.0.1/32 50
0     -i ppp0
ipchains -A output  -j ACCEPT -p udp -s 200.200.200.0/24 500 -d 199.0.0.1/32 50
0     -i ppp0
ipchains -A input   -j ACCEPT -p udp -s 199.0.0.1/32 500     -d 200.200.200.0/2
4 500 -i ppp0
ipchains -A forward -j MASQ   -p 50  -s 10.0.0.2/32          -d 199.0.0.1/32
      -i ppp0
ipchains -A output  -j ACCEPT -p 50  -s 200.200.200.0/24     -d 199.0.0.1/32
      -i ppp0
ipchains -A input   -j ACCEPT -p 50  -s 199.0.0.1/32         -d 200.200.200.0/2
4     -i ppp0
# PPTP
ipchains -A forward -j MASQ   -p tcp -s 10.0.0.2/32       -d 199.0.0.1/32 1723
-i ppp0
ipchains -A output  -j ACCEPT -p tcp -s 200.200.200.0/24  -d 199.0.0.1/32 1723
-i ppp0
ipchains -A input   -j ACCEPT -p tcp -s 199.0.0.1/32 1723 -d 200.200.200.0/24
-i ppp0
ipchains -A forward -j MASQ   -p 47  -s 10.0.0.2/32       -d 199.0.0.1/32
-i ppp0
ipchains -A output  -j ACCEPT -p 47  -s 200.200.200.0/24  -d 199.0.0.1/32
-i ppp0
ipchains -A input   -j ACCEPT -p 47  -s 199.0.0.1/32      -d 200.200.200.0/24
-i ppp0
ou, si vous avez une connexion permanente,
# IPsec
ipchains -A forward -j MASQ   -p udp -s 10.0.0.2/32 500        -d 199.0.0.1/32
500       -i eth1
ipchains -A output  -j ACCEPT -p udp -s 200.200.200.200/32 500 -d 199.0.0.1/32
500       -i eth1
ipchains -A input   -j ACCEPT -p udp -s 199.0.0.1/32 500       -d 200.200.200.2
00/32 500 -i eth1
ipchains -A forward -j MASQ   -p 50  -s 10.0.0.2/32            -d 199.0.0.1/32
          -i eth1
ipchains -A output  -j ACCEPT -p 50  -s 200.200.200.200/32     -d 199.0.0.1/32
          -i eth1
ipchains -A input   -j ACCEPT -p 50  -s 199.0.0.1/32           -d 200.200.200.2
00/32     -i eth1
# PPTP
ipchains -A forward -j MASQ   -p tcp -s 10.0.0.2/32        -d 199.0.0.1/32 1723
  -i eth1
ipchains -A output  -j ACCEPT -p tcp -s 200.200.200.200/32 -d 199.0.0.1/32 1723
  -i eth1
ipchains -A input   -j ACCEPT -p tcp -s 199.0.0.1/32 1723  -d 200.200.200.200/3
2 -i eth1
ipchains -A forward -j MASQ   -p 47  -s 10.0.0.2/32        -d 199.0.0.1/32
  -i eth1
ipchains -A output  -j ACCEPT -p 47  -s 200.200.200.200/32 -d 199.0.0.1/32
  -i eth1
ipchains -A input   -j ACCEPT -p 47  -s 199.0.0.1/32       -d 200.200.200.200/3
2 -i eth1

   Note : ces rgles n'autorisent que le trafic VPN. Vous devrez ajouter
   des rgles pour tous les autres flux que vous souhaitez autoriser,
   comme par exemple DNS, HTTP, POP, IMAP, etc...

   Notez galement combien ces rgles sont plus propres et plus faciles 
   comprendre que les rgles ipfwadm quivalentes. C'est parce que
   ipchains autorise la spcification de tous les protocoles IP, et pas
   seulement TCP, UDP, ICMP, ou ALL.
     _________________________________________________________________

3.7. Une note sur l'adressage IP dynamique

   Si votre pare-feu se voit attribuer une adresse IP dynamique par votre
   FAI (les comptes modems fonctionnent comme a, ainsi que certains
   cablo-oprateurs), alors vous devez ajouter ce qui suit au script de
   dmarrage /etc/rc.d/rc.local:
   echo 7 > /proc/sys/net/ipv4/ip_dynaddr

   Ceci active le suivi d'adresse IP dynamique, ce qui signifie que si
   votre connexion tombe et remonte, toutes les sessions actives seront
   mises  jour avec la nouvelle adresse IP plutt que de continuer 
   essayer d'utiliser l'ancienne adresse IP. Cela ne veut pas dire que
   les sessions resteront actives malgr l'interruption, mais plutt
   qu'elles se fermeront rapidement.

   Si vous ne le faites pas, il peut y avoir une "priode de latence"
   aprs la reconnexion et avant l'expiration des anciennes entres de la
   table de masquage pendant laquelle vous serez masqu avec la mauvaise
   adresse IP, ce qui vous empchera d'tablir une connexion.

   Ceci est particulirement utile si vous utilisez un dmon de demande
   de connexion comme diald pour grer votre connexion modem.

   Regardez le fichier
   /usr/src/linux/Documentation/networking/ip_dynaddr.txt pour de plus
   amples dtails.
     _________________________________________________________________

3.8. Paramtrages additionnels pour un serveur VPN avec une adresse IP
prive

   Si vous mettez en place le masquage VPN pour un serveur VPN avec une
   adresse IP prive (c'est  dire que vous voulez faire du masquage
   aussi bien pour les connexions _entrantes_ que _sortantes_), vous avez
   galement besoin d'installer deux outils de transmission de paquets.
   L'un(ipportfw) fait suivre le trafic TCP ou UDP entrant adress  un
   port spcifique du pare-feu vers une machine sur le rseau local
   derrire le pare-feu. Il est utilis pour rediriger le canal de
   contrle PPTP initial 1723/tcp en entre, ou le trafic ISAKMP 500/udp
   vers le serveur VPN. L'autre (ipfwd) est un outil de transmission de
   paquets plus gnrique, qui peut tre utilis pour tous les protocoles
   IP. Il est utilis pour faire suivre le trafic entrant initial 47/ip
   (GRE) ou 50/ip (ESP) du canal de donnes vers le serveur VPN.

   Les sorties en rponse au trafic entrant 1723/tcp ou 500/udp sont
   masques grce aux fonctionnalits standard de masquage IP du noyau
   Linux. Le trafic sortant 47/ip ou 50/ip est masqu grce au patch du
   noyau pour le masquage VPN que vous avez install prcdemment.

   Une fois que ces outils sont installs, vous devez les configurer pour
   faire suivre le trafic vers le serveur VPN.

     * Paramtrer ipportfw pour les noyaux 2.0.x
       Les commandes suivantes vont paramtrer ipportfw pour faire suivre
       le trafic 500/udp entrant vers le serveur IPsec :

# Paramtrage d'ipportfw pour IPsec avec une adresse IP statique
# Vide la table de redirection d'ipportfw
/sbin/ipportfw -C
# Fait suivre le trafic adress au port 500/udp du pare-feu
# au port 500/udp du serveur IPsec
/sbin/ipportfw -A -u 200.200.200.200/500 -R 10.0.0.2/500

       Les commandes suivantes vont paramtrer ipportfw pour faire suivre
       le trafic entrant 1723/tcp initial vers le serveur PPTP :

# Paramtrage d'ipportfw pour PPTP avec une adresse IP statique
# Vide la table de redirection d'ipportfw
/sbin/ipportfw -C
# Fait suivre le trafic adress au port 1723/tcp du pare-feu
# vers le port 1723/tcp du serveur PPTP
/sbin/ipportfw -A -t 200.200.200.200/1723 -R 10.0.0.2/1723

       Notez que les paramtres d'ipportfw contiennent l'adresse IP
       internet du pare-feu, et que vous ne pouvez pas spcifier
       l'interface (par exemple ppp0) contrairement  ipfwadm. Ceci veut
       dire que dans le cas d'une connexion IP dynamique (comme pour une
       connexion PPP par modem) vous devez lancer ces commandes  chaque
       fois que vous vous connectez  internet, et qu'une nouvelle
       adresse IP vous est attribue. Vous pouvez le faire assez
       facilement - ajoutez simplement les lignes suivantes  votre
       script /etc/ppp/ip-up ou /etc/ppp/ip-up.local :

# Paramtrage d'ippportfw pour IPsec avec une adresse IP dynamique
# Vide la table de redirection d'ipportfw
/sbin/ipportfw -C
# Fait suivre le trafic adress au port 500/udp du pare-feu
# vers le port 500/udp du serveur IPsec
/sbin/ipportfw -A -u ${4}/500 -R 10.0.0.2/500

       ou :

# Paramtrage d'ipportfw pour PPTP avec une adresse IP dynamique
# Vide la table de redirection d'ipportfw
/sbin/ipportfw -C
# Fait suivre le trafic adress au port 1723/tcp du pare-feu
# vers le port 1723 du serveur PPTP
/sbin/ipportfw -A -t ${4}/1723 -R 10.0.0.2/1723

       Allez voir
       http://www.wolfenet.com/~jhardin/ipfwadm/invocation.html pour de
       plus amples dtails sur la mise en place d'un pare-feu avec une
       adresse IP dynamique.
     * Configurer ipfwd pour les noyaux 2.0.x et 2.2.x
       La commande suivante va paramtrer ipfwd pour faire suivre le
       trafic entrant 50/ip initial au le serveur IPsec :

/sbin/ipfwd --masq 10.0.0.2 50 &

       La commande suivante va paramtrer ipfwd pour faire suivre le
       trafic entrant 47/ip initial au serveur PPTP :

/sbin/ipfwd --masq 10.0.0.2 47 &

       Cette commande n'a besoin d'tre excute qu'une seule fois,
       depuis votre script /etc/rc.d/rc.local.

   Les techniques dcrites ici peuvent tre gnralises pour autoriser
   le masquage de la plupart des serveurs - HTTP, FTP, SMTP, etc. Les
   serveurs qui sont bass uniquement sur TCP ou UDP n'ont pas besoin de
   ipfwd.

   Si vous masquez un serveur PPTP, vous avez aussi besoin de vous
   assurer que vous n'avez _pas_ activ le masquage d'identifiant d'appel
   PPTP dans le noyau. L'activation du masquage d'identifiant d'appel
   PPTP fait croire que vous masquez uniquement des clients PPTP,
   l'activer risque donc de vous empcher de masquer correctement le
   trafic du serveur PPTP. Cela signifie galement qu'avec la version
   2.0.x du patch, vous ne pouvez pas masquer simultanment un serveur
   PPTP et des clients PPTP.
     _________________________________________________________________

3.9. Paramtrage d'ipfwadm pour un serveur VPN avec une adresse IP publique

   Mettre en place un serveur VPN avec une adresse IP publique se
   trouvant derrire un pare-feu Linux est un simple problme de routage
   et de filtrage de paquets. Le masquage n'est pas ncessaire.

   Malheureusement les noyaux 2.0.x ne nous permettent pas de prciser le
   protocole IP 47 ou 50, donc ce pare-feu est moins sr que ce qu'il
   aurait pu tre. Si cela vous pose un problme, alors installez le
   patch noyau pour les chanes pare-feu IP ou passez  un noyau de la
   srie 2.1.x ou 2.2.x, avec lesquels vous pouvez faire du filtrage par
   protocole IP.

   Les rgles pare-feu vont avoir un peu cette tte l :
# Cette section doit se trouver aprs vos autres rgles pare-feu

# Prcisez explicitement les clients potentiels pour plus de scurit
# Autorise le trafic ISAKMP IPsec entrant et sortant.
ipfwadm -I -a accept -W eth1 -V 200.200.200.200 -P udp -S 199.0.0.2/32 500 -D 2
22.0.0.2/32 500
ipfwadm -O -a accept -W eth1 -V 200.200.200.200 -P udp -D 199.0.0.2/32 500 -S 2
22.0.0.2/32 500
ipfwadm -I -a accept -W eth1 -V 200.200.200.200 -P udp -S 199.0.0.3/32 500 -D 2
22.0.0.2/32 500
ipfwadm -O -a accept -W eth1 -V 200.200.200.200 -P udp -D 199.0.0.3/32 500 -S 2
22.0.0.2/32 500
# Autorise le canal de contrle PPTP en entre et en sortie
ipfwadm -I -a accept -W eth1 -V 200.200.200.200 -P tcp -S 199.0.0.2/32 -D 222.0
.0.2/32 1723
ipfwadm -O -a accept -W eth1 -V 200.200.200.200 -P tcp -D 199.0.0.2/32 -S 222.0
.0.2/32 1723
ipfwadm -I -a accept -W eth1 -V 200.200.200.200 -P tcp -S 199.0.0.3/32 -D 222.0
.0.2/32 1723
ipfwadm -O -a accept -W eth1 -V 200.200.200.200 -P tcp -D 199.0.0.3/32 -S 222.0
.0.2/32 1723

# Bloque tous les autres trafics TCP et UDP en provenance d'internet
# Ceci est principalement une rgle "dfaut refus TCP/UDP" qui
# ne s'applique qu' l'interface internet.
ipfwadm -I -a deny -W eth1 -V 200.200.200.200 -P tcp
ipfwadm -I -a deny -W eth1 -V 200.200.200.200 -P udp

# Prcisez explicitement les clients potentiels pour plus de scurit
# Notez que ce paramtrage est trop large, car nous sommes
# obligs de prciser "-P all" au lieu de "-P 47" ou "-P 50"...
# Autorise le canal de donnes PPTP et le trafic ESP IPsec entrant et sortant.
ipfwadm -I -a accept -W eth1 -V 200.200.200.200 -P all -S 199.0.0.2/32 -D 222.0
.0.2/32
ipfwadm -0 -a accept -W eth1 -V 200.200.200.200 -P all -D 199.0.0.2/32 -S 222.0
.0.2/32
ipfwadm -I -a accept -W eth1 -V 200.200.200.200 -P all -S 199.0.0.3/32 -D 222.0
.0.2/32
ipfwadm -O -a accept -W eth1 -V 200.200.200.200 -P all -D 199.0.0.3/32 -S 222.0
.0.2/32

# Bloque tous les autres trafics en provenance d'internet.
# Ceci est principalement une rgle du type "par dfaut, refus"
# qui ne s'applique qu' l'interface internet.
ipfwadm -I -a deny -W eth1 -V 200.200.200.200

   Si vous installez des rgles pare-feu ou des rgle de transmission de
   paquets sur l'interface interne, vous aurez  faire quelque chose de
   semblable. L'exemple ci-dessus ne concerne que le trafic VPN ; il vous
   faut l'insrer dans votre paramtrage pare-feu actuel pour autoriser
   les autres trafics dont vous avez besoin.
     _________________________________________________________________

3.10. Paramtrage d'ipfwadm pour un client VPN avec une adresse IP publique

   La mise en place d'un client VPN avec une adresse IP publique derrire
   un pare-feu Linux est similaire  celle d'un serveur VPN avec une
   adresse IP publique.

   Les rgles pare-feu auront cette allure :
# Autorise le trafic ISAKMP IPsec entrant et sortant.
ipfwadm -O -a accept -W eth1 -V 200.200.200.200 -P udp -S 222.0.0.2/32 500 -D 1
99.0.0.1/32 500
ipfwadm -I -a accept -W eth1 -V 200.200.200.200 -P udp -D 222.0.0.2/32 500 -S 1
99.0.0.1/32 500
# Autorise le canal de contrle PPTP en entre et en sortie.
ipfwadm -O -a accept -W eth1 -V 200.200.200.200 -P tcp -S 222.0.0.2/32 -D 199.0
.0.1/32 1723
ipfwadm -I -a accept -W eth1 -V 200.200.200.200 -P tcp -D 222.0.0.2/32 -S 199.0
.0.1/32 1723

# Bloque tous les autres trafics TCP et UDP en provenance d'internet.
# Ceci est principalement une rgle "par dfaut, refus de TCP/UDP" qui
# ne s'applique qu' l'interface internet.
ipfwadm -I -a deny -W eth1 -V 200.200.200.200 -P tcp
ipfwadm -I -a deny -W eth1 -V 200.200.200.200 -P udp

# Notez que ce paramtrage est trop large, car nous sommes
# obligs de prciser "-P all" au lieu de "-P 47" ou "-P 50"...
# Autorise le canal de donnes PPTP et le trafic ESP IPsec entrant et sortant.
ipfwadm -O -a accept -W eth1 -V 200.200.200.200 -P all -S 222.0.0.2/32 -D 199.0
.0.1/32
ipfwadm -I -a accept -W eth1 -V 200.200.200.200 -P all -D 222.0.0.2/32 -S 199.0
.0.1/32

# Bloque tous les autres trafics en provenance d'internet.
# Ceci est principalement une rgle du type "par dfaut, refus"
# qui ne s'applique qu' l'interface internet.
ipfwadm -I -a deny -W eth1 -V 200.200.200.200
     _________________________________________________________________

3.11. Paramtrage d'ipchains pour un serveur VPN avec une adresse IP
publique

   Mettre en place un serveur VPN avec une adresse IP publique derrire
   un pare-feu Linux correspond  vrifier que les commandes de routage
   et de filtrage de paquet appropries sont bien en place. Le masquage
   n'est pas ncessaire.

   Les rgles pare-feu auront cette allure :
# Spcifiez explicitement les clients potentiels pour plus de scurit.
# Autorise le trafic ISAKMP IPsec entrant et sortant.
ipchains -A input  -j ACCEPT -p udp -s 199.0.0.2/32 500 -d 222.0.0.2/32 500 -i
eth1
ipchains -A output -j ACCEPT -p udp -d 199.0.0.2/32 500 -s 222.0.0.2/32 500 -i
eth1
ipchains -A input  -j ACCEPT -p udp -s 199.0.0.3/32 500 -d 222.0.0.2/32 500 -i
eth1
ipchains -A output -j ACCEPT -p udp -d 199.0.0.3/32 500 -s 222.0.0.2/32 500 -i
eth1
# Autorise le trafic ESP IPsec entrant et sortant.
ipchains -A input  -j ACCEPT -p 50  -s 199.0.0.2/32     -d 222.0.0.2/32     -i
eth1
ipchains -A output -j ACCEPT -p 50  -d 199.0.0.2/32     -s 222.0.0.2/32     -i
eth1
ipchains -A input  -j ACCEPT -p 50  -s 199.0.0.3/32     -d 222.0.0.2/32     -i
eth1
ipchains -A output -j ACCEPT -p 50  -d 199.0.0.3/32     -s 222.0.0.2/32     -i
eth1
# Autorise le canal de contrle PPTP en entre et en sortie.
ipchains -A input  -j ACCEPT -p tcp -s 199.0.0.2/32 -d 222.0.0.2/32 1723 -i eth
1
ipchains -A output -j ACCEPT -p tcp -d 199.0.0.2/32 -s 222.0.0.2/32 1723 -i eth
1
ipchains -A input  -j ACCEPT -p tcp -s 199.0.0.3/32 -d 222.0.0.2/32 1723 -i eth
1
ipchains -A output -j ACCEPT -p tcp -d 199.0.0.3/32 -s 222.0.0.2/32 1723 -i eth
1
# Autorise le tunnel PPTP en entre et en sortie.
ipchains -A input  -j ACCEPT -p 47  -s 199.0.0.2/32 -d 222.0.0.2/32      -i eth
1
ipchains -A output -j ACCEPT -p 47  -d 199.0.0.2/32 -s 222.0.0.2/32      -i eth
1
ipchains -A input  -j ACCEPT -p 47  -s 199.0.0.3/32 -d 222.0.0.2/32      -i eth
1
ipchains -A output -j ACCEPT -p 47  -d 199.0.0.3/32 -s 222.0.0.2/32      -i eth
1

   Si vous installez des rgles pare-feu ou des rgles de transmission de
   paquets sur l'interface interne, vous aurez  faire quelque chose de
   semblable. L'exemple ci-dessus ne concerne que le trafic VPN ; il vous
   faut l'insrer dans votre paramtrage pare-feu actuel pour autoriser
   les autres trafics dont vous avez besoin.
     _________________________________________________________________

3.12. Paramtrage d'ipchains pour un client VPN avec une adresse IP publique

   La mise en place d'un client VPN avec une adresse IP publique derrire
   un pare-feu Linux est identique  celle d'un serveur VPN avec une
   adresse IP publique.

   Les rgles pare-feu auront cette allure :
# Autorise le trafic ISAKMP IPsec entrant et sortant.
ipchains -A output -j ACCEPT -p udp -s 222.0.0.2/32 500 -d 199.0.0.1/32 500 -i
eth1
ipchains -A input  -j ACCEPT -p udp -d 222.0.0.2/32 500 -s 199.0.0.1/32 500 -i
eth1
# Autorise le trafic ESP IPsec entrant et sortant.
ipchains -A output -j ACCEPT -p 50  -s 222.0.0.2/32     -d 199.0.0.1/32     -i
eth1
ipchains -A input  -j ACCEPT -p 50  -d 222.0.0.2/32     -s 199.0.0.1/32     -i
eth1
# Autorise le canal de contrle PPTP en entre et en sortie.
ipchains -A output -j ACCEPT -p tcp -s 222.0.0.2/32 -d 199.0.0.1/32 1723 -i eth
1
ipchains -A input  -j ACCEPT -p tcp -d 222.0.0.2/32 -s 199.0.0.1/32 1723 -i eth
1
# Autorise le tunnel PPTP en entre et en sortie.
ipchains -A output -j ACCEPT -p 47  -s 222.0.0.2/32 -d 199.0.0.1/32      -i eth
1
ipchains -A input  -j ACCEPT -p 47  -d 222.0.0.2/32 -s 199.0.0.1/32      -i eth
1
     _________________________________________________________________

3.13. Masquage VPN et LRP

   Le projet de routeur Linux (Linux Router Project), qui se trouve 
   l'adresse http://www.linuxrouter.org/, fournit un kit
   pare-feu-sur-disquette bas sur Linux. Avec un PC '386, deux cartes
   rseaux, et un lecteur de disquette, vous pouvez mettre en place un
   pare-feu masquant avec toutes les fonctionnalits. Aucun disque dur
   n'est ncessaire.

   Le masquage VPN est cens tre inclus dans la version 2.2.9 de LRP -
   pour vrifier s'il est disponible, regardez si ip_masq_ipsec ou
   ip_masq_pptp sont dans la liste des modules chargeables dans Package
   Settings -> Modules, ou faites un grep sur /proc/ksyms comme dcrit
   plus haut. Si vous voulez ajouter le masquage VPN  une version
   antrieure du LRP, alors quelqu'un sur la liste de diffusion du LRP
   pourra vous fournir une image de disquette, ou bien vous pouvez faire
   votre propre noyau en utilisant les instructions qui se trouvent sur
   la page du LRP.

   Les rgles pare-feu seront ajoutes au script de dmarrage dans
   Network Settings -> Direct Network Setup.
     _________________________________________________________________

3.14. Masquage VPN sur un systme tournant avec FreeS/WAN ou PoPToP

   Si vous souhaitez utiliser le pare-feu en tant que passerelle IPsec
   avec FreeS/WAN, vous _ne devez pas_ activer le masquage IPsec. Si vous
   souhaitez utiliser le pare-feu comme serveur PPTP avec PoPToP, ou
   comme client PPTP en utilisant le logiciel client PPTP pour Linux,
   vous _ne devez pas_ activer le masquage PPTP.

   Le masquage VPN et le client ou serveur VPN utilisant les mmes
   protocoles, ils ne peuvent pas cohabiter sur le mme ordinateur.

   Votre pare-feu _peut_, cependant, tre une passerelle VPN IPsec
   FreeS/WAN et faire du masquage PPTP, ou vice-versa.
     _________________________________________________________________

4. Configurer le client VPN

4.1. Configurer un client MS W'95

    1. Configurez votre routage pour que votre pare-feu Linux soit votre
       passerelle par dfaut :
         a. Ouvrez Panneau de configuration/Rseau ou faites un clic
            droit sur "Voisinage Rseau" et cliquez sur Proprits.
         b. Cliquez sur l'onglet Configuration.
         c. Dans la liste des composants rseaux installs, faites un
            double-clic sur la ligne "TCP/IP -> votre-carte-rseau".
         d. Cliquez sur l'onglet Passerelle.
         e. Entrez l'adresse IP locale de votre pare-feu Linux. Enlevez
            les autres passerelles.
         f. Cliquez sur le bouton "OK".
    2. Testez le masquage. Par exemple, lancez "telnet
       le.serveur.de.mail.de.mon.fai smtp" et vous devriez voir la
       bannire d'accueil du serveur de mail.
    3. Installez et configurez le logiciel de VPN. Pour le logiciel
       IPsec, suivez les instructions de l'diteur. Pour PPTP de MS :
         a. Ouvrez Panneau de Configuration/Rseau ou faites un clic
            droit sur "Voisinage Rseau" et cliquez sur Proprits.
         b. Cliquez sur l'onglet Configuration.
         c. Cliquez sur le bouton "Ajouter", et cliquez ensuite sur la
            ligne "Carte".
         d. Slectionnez "Microsoft" comme constructeur, et ajoutez
            l'adaptateur "Carte de Rseau Priv Virtuel Microsoft".
         e. Redmarrez lorsque l'ordinateur vous le demande.
         f. Si vous avez besoin de cryptage fort (128 bits), tlchargez
            la mise  jour pour cryptage fort de DUN 1.3 sur le site
            scuris de MS  l'adresse
            http://mssecure.www.conxion.com/cgi-bin/ntitar.pl et
            installez la, redmarrez ensuite quand l'ordinateur vous le
            demande.
         g. Crez une nouvelle entre dans votre carnet d'adresse d'appel
            distant pour votre serveur PPTP.
         h. Slectionnez l'adaptateur VPN comme priphrique  utiliser,
            et entrez l'adresse IP internet du serveur PPTP comme numro
            de tlphone.
         i. Slectionnez l'onglet Types de Serveur, et cochez les cases
            Activer la compression logicielle et Demander un mot de passe
            crypt.
         j. Cliquez sur le bouton "Paramtrages TCP/IP".
         k. Renseignez les informations concernant l'adresse IP
            dynamique/statique de votre client comme prcis par
            l'administrateur de votre serveur PPTP.
         l. Si vous souhaitez avoir accs  votre rseau local pendant
            que votre connexion PPTP est active, dcochez la case
            "Utiliser la passerelle par dfaut pour le rseau distant".
         m. Redmarrez encore quelques fois, juste par habitude... :-)
     _________________________________________________________________

4.2. Configurer un client MS W'98

    1. Configurez le routage pour que le pare-feu Linux soit votre
       passerelle par dfaut, et testez le masquage comme indiqu plus
       haut.
    2. Installez et configurez le logiciel de VPN. Pour un logiciel
       IPsec, suivez les instructions de l'diteur. Pour PPTP de MS :
         a. Ouvrez Panneau de Configuration/Ajout/Suppression de
            programme et cliquez sur l'ongletInstallation de Windows.
         b. Cliquez sur l'option Communications et cliquez sur le bouton
            "Dtails...".
         c. Assurez vous que l'option "Rseau Priv Virtuel (VPN)" est
            coche. Cliquez alors sur le bouton "OK".
         d. Redmarrez la machine lorsqu'on vous le demande.
         e. Si vous avez besoin d'utiliser du cryptage fort (128 bits),
            tlchargez la mise  jour scurit pour le cryptage fort VPN
            sur le site scuris de MS  l'adresse :
            http://mssecure.www.conxion.com/cgi-bin/ntitar.pl et
            installez-la, et ensuite redmarrez encore lorsqu'on vous le
            demande.
    3. Crez et testez une nouvelle entre pour votre serveur VPN dans
       votre carnet d'adresse d'appel distant, comme dcrit plus haut.
     _________________________________________________________________

4.3. Configurer un client MS W'ME

   Je n'en ai pas vu pour l'instant. Je suppose que la procdure est trs
   proche de celle pour W'98. Quelqu'un pourrait-il me dire quelles sont
   les diffrences, s'il y en a ? Merci.
     _________________________________________________________________

4.4. Configurer un client MS NT

Note: cette section peut tre incomplte car a fait
un petit moment que je n'ai pas install PPTP sur un systme NT.

    1. Configurez votre routage pour que le pare-feu Linux soit votre
       passerelle par dfaut :
         a. Ouvrez Panneau de Configuration/Rseau ou faites un clic
            droit sur "Voisinage Rseau" et cliquez sur Proprits.
         b. Cliquez sur l'onglet Protocoles et faites un double-clic sur
            la ligne "Protocole TCP/IP".
         c. Entrez l'adresse IP locale de votre pare-feu Linux dans la
            zone de dialogue "Passerelle par dfaut".
         d. Cliquez sur le bouton "OK".
    2. Testez le masquage. Par exemple, lancez "telnet
       le.serveur.de.mail.de.mon.fai smtp" et vous devriez voir
       apparatre la bannire d'accueil du serveur de mails.
    3. Installez et configurez le logiciel VPN. Pour un logiciel IPsec,
       suivez les instructions de l'diteur. Pour PPTP de MS :
         a. Ouvrez Panneau de Configuration/Rseau ou faites un clic
            droit sur "Voisinage Rseau" et cliquez sur Proprits.
         b. Cliquez sur l'onglet Protocoles.
         c. Cliquez sur le bouton "Ajouter", et faites ensuite un
            double-clic sur la ligne "Point to Point Tunneling Protocol".
         d. Quand on vous demande les numros de Rseaux Virtuels Privs,
            entrez les numros des serveurs PPTP que vous pouvez
            potentiellement joindre.
         e. Redmarrez lorsqu'on vous le demande.
         f. Si vous avez besoin d'utiliser du cryptage fort (128 bits),
            tlchargez la mise  jour de PPTP pour cryptage fort sur le
            site scuris de MS  l'adresse
            http://mssecure.www.conxion.com/cgi-bin/ntitar.pl et
            installez la, puis redmarrez lorsqu'on vous le demande.
         g. Crez une nouvelle entre dans votre carnet d'adresse d'appel
            distant pour votre serveur PPTP.
         h. Slectionnez l'adaptateur VPN comme priphrique  utiliser,
            et entrez l'adresse IP internet du serveur PPTP comme numro
            de tlphone.
         i. Slectionnez l'onglet Types de Serveur et cochez les cases
            Activer la compression logicielle et Demander un mot de passe
            crypt.
         j. Cliquez sur le bouton "Paramtres TCP/IP".
         k. Renseignez les informations concernant l'adresse IP
            dynamique/statique de votre client comme prcis par
            l'administrateur de votre serveur PPTP.
         l. Si vous souhaitez avoir accs  votre rseau local pendant
            que la connexion PPTP est active, regardez L'article de la
            Base de Connaissances MS Q143168 pour modifier la base de
            registres. (_Hum_.)
         m. Assurez vous d'avoir r-appliqu le dernier Service Pack,
            pour tre sr que les librairies RAS et PPTP sont  jour en
            ce qui concerne la scurit et les performances.
     _________________________________________________________________

4.5. Configuration pour du routage rseau  rseau

   _A crire._

   Vous devriez vraiment jeter un oeil sur FreeS/WAN (IPsec pour Linux) 
   l'adresse http://www.xs4all.nl/~freeswan/ plutt que de faire du
   masquage.
     _________________________________________________________________

4.6. Masquer des VPNs bass sur SecuRemote de CheckPoint

   Il est possible de masquer le trafic VPN bas sur SecuRemote de
   Checkpoint  certaines conditions.

   Pour commencer, vous devez configurer le pare-feu SecuRemote pour
   autoriser les sessions masques. Sur le pare-feu SecuRemote, faites ce
   qui suit.

    1. Excutez fwstop
    2. ditez $FWDIR/conf/objects.C et aprs la ligne ":props (", ajoutez
       ou modifiez les lignes suivantes pour avoir

:userc_NAT (true)
:userc_IKE_NAT (true)

    3. Excutez fwstart
    4. Rinstallez votre politique de scurit.
    5. Vrifiez que les changements ont t pris en compte en vrifiant
       $FWDIR/conf/objects.C et $FWDIR/database/objects.C

   Si vous utilisez les protocoles IPsec (appels "IKE" par CheckPoint)
   vous n'avez pas besoin de faire autre chose pour masquer le trafic
   VPN. Configurez simplement votre passerelle de masquage pour masquer
   le trafic IPsec comme dcrit plus haut.

   Le protocole propritaire FWZ de CheckPoint est plus compliqu. Il y a
   deux modes dans lesquels FWZ peut tre utilis : le mode encapsul, et
   le mode de transport. En mode encapsul, la vrification d'intgrit
   est faite sur l'ensemble du paquet IP, comme avec le protocole AH
   d'IPsec. Changer l'adresse IP casse cette garantie d'intgrit, donc
   les tunnels FWZ encapsuls _ne peuvent pas_ tre masqus.

   En mode transport, seule la portion du paquet contenant les donnes
   est crypte, et les enttes IP ne sont pas vrifis pour voir s'ils
   ont t modifis. Dans ce mode, le masquage doit fonctionner avec les
   modifications indiques plus haut.

   La configuration pour choisir entre le mode encapsul ou le mode
   transport se fait via l'IHM FireWall-1. Dans l'objet rseau
   correspondant au pare-feu, sur l'onglet VPN, ditez les proprits
   FWZ. Le troisime onglet dans les proprits FWZ vous permet de
   choisir le mode encapsul.

   Vous ne pourrez masquer qu'un seul client  la fois.

   Vous trouverez de plus amples informations aux adresses :

     * http://www.phoneboy.com/fw1/nat.html,
     * http://www.phoneboy.com/fw1/faq/0141.html
     * http://www.phoneboy.com/fw1/faq/0372.html
     _________________________________________________________________

5. Dpannage

5.1. Tests

   Pour tester le masquage VPN :

    1. Activez la connexion  votre FAI depuis votre machine Linux, et
       vrifiez qu'elle fonctionne correctement.
    2. Vrifiez que le masquage fonctionne correctement, par exemple en
       utilisant une machine de votre rseau local masque pour aller
       surfer sur un site web, ou pour accder  un serveur FTP.
    3. PPTP : vrifiez que vous avez correctement configur le masquage
       du canal de contrle PPTP : essayez de faire un telnet depuis la
       machine cliente PPTP vers le port 1723 de votre serveur PPTP. Ne
       vous attendez pas  voir quelque chose, mais si vous avez une
       erreur disant que la connexion a chou ou si vous n'avez pas de
       rponse, jetez un coup d'oeil aux rgles de masquage sur votre
       machine Linux, pour vous assurer que vous masquez bien le trafic
       en provenance du poste client PPTP vers le port TCP 1723 du
       serveur PPTP.
    4. PPTP : essayez d'tablir une connexion PPTP. Je vous recommande de
       lancer galement RASMON s'il est disponible, car il va vous donner
       un minimum d'informations sur l'tat de la connexion. Si vous
       tablissez une connexion PPTP lors de votre premire tentative,
       flicitations ! Vous avez russi !
    5. IPsec : essayez d'tablir une connexion IPsec.
     _________________________________________________________________

5.2. Problmes possibles

   Il y a plusieurs lments qui peuvent empcher d'tablir une session
   VPN. Nous allons les considrer en partant du client vers le serveur,
   puis dans l'autre sens. Pour les exemples, nous partirons du principe
   que le client est un client Windows, ce qui correspond au cas le plus
   courant.

    1. Information sur la connexion : le "numro de tlphone" dans
       l'cran de configuration VPN distant doit tre l'adresse IP
       internet du serveur VPN, ou l'adresse du pare-feu si le serveur
       est masqu.
    2. PPTP et cryptage fort : si le client et le serveur n'ont pas le
       fichier NDISWAN.SYS ou le logiciel PPTP pour W'95/'98 128 bits,
       vous n'arriverez pas  tablir une session avec cryptage fort.
       Malheureusement, au cours de mon exprience j'ai constat que ce
       problme ne gnre pas de message d'erreur, et que le client
       cherche  se connecter sans cesse... Vous pouvez rcuprer la mise
        jour pour le cryptage fort sur le site scuris de Microsoft
       dont l'URL est donne dans la section"Configurer un client MS".
       Ceci va galement affecter les clients IPsec, s'ils utilisent les
       librairies de cryptage fournies par MS plutt que leurs propres
       librairies.
    3. Routage : vrifiez que la route par dfaut sur votre client VPN
       pointe bien vers la machine de masquage Linux. Lancez la commande
       route print et cherchez l'entre 0.0.0.0.
       Si d'autres services masqus (comme HTTP, FTP, IRC, etc...)
       fonctionnent sur votre machine cliente VPN, alors ce n'est pas un
       problme de routage.
    4. Masquage : il y a deux parties dans la session VPN.
       Pour IPsec, le service d'authentification et d'change de cls
       (ISAKMP), qui est une session UDP sur le port 500 de la machine
       IPsec distante, le pare-feu doit tre configur pour le masquage
       comme pour tout autre service UDP (par exemple DNS).
       Pour PPTP, le canal de contrle, qui est une session TCP normale
       vers le port 1723 du serveur PPTP, le pare-feu doit tre configur
       pour le masquage comme pour tout autre service TCP (par exemple
       HTTP).
       Le canal de donnes crypt avec IPsec est transport au dessus
       d'ESP, le protocole IP 50. Le canal de donnes crypt avec PPTP
       est transport au dessus de GRE, le protocole IP 47. (Notez que ce
       ne sont _pas_ des numros de ports TCP ou UDP !) Le noyau Linux
       2.0 ne vous permettant de prciser que les protocoles IP TCP, UDP,
       ICMP et ALL lors de la cration des rgles de masquage, vous devez
       masquer le trafic du protocole ALL mme si vous masquez uniquement
       des services spcifiques. Si vous masquez tout, ne vous en
       inquitez pas.
       Afin d'isoler les problmes issus des rgles du pare-feu de ceux
       provenant du code de masquage du noyau, essayez d'tablir une
       connexion VPN avec votre pare-feu compltement ouvert, et si a
       marche, resserrez alors les rgles du pare-feu.
       Pare-feu compltement ouvert avec ipfwadm et un noyau 2.0.x :

ipfwadm -I -p accept
ipfwadm -O -p accept
ipfwadm -F -a accept -m

       Pare-feu compltement ouvert avec ipchains et un noyau 2.2.x :

ipchains -P input   ACCEPT
ipchains -P output  ACCEPT
ipchains -P forward MASQ

       Ne laissez _pas_ votre pare-feu compltement ouvert plus de temps
       qu'il n'en faut pour prouver qu'une connexion VPN masque peut
       tre tablie !
    5. quipements intermdiaires et Internet : Tous les routeurs entre
       votre pare-feu Linux et la machine IPsec distante doivent
       autoriser le passage des paquets porteurs du protocole IP 50. Tous
       les routeurs entre votre pare-feu Linux et le serveur PPTP doivent
       autoriser le passage des paquets porteurs du protocole IP 47. Si
       IPsec ou PPTP fonctionne lorsque votre client VPN est directement
       connect  votre FAI, alors le problme ne vient probablement pas
       de l.
       Pour savoir si un quipement intermdiaire bloque le trafic GRE,
       utilisez un traceroute patch pour suivre la progression des
       paquets GRE. Regardez la section des ressources pour de plus
       amples informations sur le patch de traceroute. Un patch similaire
       pour ESP est en cours de codage.
    6. Le pare-feu distant : le pare-feu du ct du serveur doit
       autoriser une machine ayant la mme adresse IP que celle attribue
        votre machine Linux par votre FAI  se connecter au port 500/udp
       de la machine IPsec ou sur le port 1723/tcp du serveur PPTP. Si le
       VPN fonctionne lorsque votre client VPN est connect directement 
       votre FAI, alors le problme ne vient probablement pas de l.
    7. Le pare-feu ct serveur et ESP : les donnes cryptes IPsec sont
       transportes au dessus du protocole IP 50. Si le pare-feu derrire
       lequel se trouve la machine IPsec distante ne fait pas suivre le
       trafic ESP dans les deux sens, IPsec ne pourra pas marcher. Une
       fois de plus, si IPsec fonctionne lorsque votre client IPsec est
       connect directement  votre FAI, alors le problme ne vient
       probablement pas de l.
    8. Le pare-feu ct serveur et GRE : le canal de donnes PPTP est
       transport comme une session PPP encapsule dans GRE (protocole IP
       47). Si le pare-feu derrire lequel votre serveur PPTP se trouve
       ne fait pas suivre le trafic GRE dans les deux sens, PPTP ne
       pourra pas fonctionner. Une fois de plus, si PPTP fonctionne
       lorsque votre client IPsec est connect directement  votre FAI,
       alors le problme ne vient probablement pas de l.
    9. Le patch : si votre client IPsec s'authentifie correctement mais
       ne peut pas tablir de connexion rseau, le patch peut ne pas
       masquer le trafic ESP correctement. Si votre client PPTP tablit
       le canal de contrle (RASMON bipe et le petit tlphone clignote)
       et qu'un trafic GRE est gnr (la lumire en haut de RASMON
       clignote) mais qu'il n'y a pas de trafic GRE en retour (la lumire
       en bas de RASMON ne clignote pas en rponse), le patch peut ne pas
       masquer le trafic GRE correctement.
       Regardez dans /var/log/messages pour trouver les entres des
       journaux qui montrent que le trafic VPN a t vu. Activez le
       dboguage du VPN pour vous aider  dterminer si le patch est
       responsable ou non. Faites aussi tourner un sniffeur sur votre
       connexion internet en cherchant le trafic VPN sortant _(voir plus
       bas)_.
   10. Clients multiples : l'ancien patch PPTP ne supporte PAS le
       masquage de plusieurs clients PPTP cherchant  accder au _mme_
       serveur PPTP. Si vous essayez de le faire, vous devriez
       reconsidrer votre architecture rseau et voir si vous ne devriez
       pas installer un routeur PPTP pour vos clients locaux. Le patch
       2.0 inclus le masquage d'identifiant d'appel, qui permet plusieurs
       sessions simultanes. _Note :_ n'activez pas le masquage
       d'identifiant d'appel PPTP si vous masquez un serveur PPTP. Cela
       empcherait le trafic sortant en provenance du serveur d'tre
       masqu.
     _________________________________________________________________

5.3. Dpannage

   La plupart des problmes peuvent tre identifis en faisant tourner un
   sniffeur de paquets (par exemple tcpdump avec l'option -v) sur votre
   pare-feu passerelle VPN. Si tout fonctionne correctement, vous allez
   voir le trafic suivant.

     * Rseau local du client :
       IPsec : le trafic UDP (destination UDP port 500) et ESP (protocole
       IP 50) en provenance de votre client local IPsec  destination de
       l'adresse IP internet de la machine IPsec distante. Si vous ne le
       voyez pas, votre client IPsec est mal configur.
       PPTP : le trafic TCP (destination TCP port 1723) et GRE (protocole
       IP 47) en provenance de votre client local PPTP  destination de
       l'adresse IP internet du serveur PPTP. Si vous ne le voyez pas,
       votre client PPTP est mal configur.
     * Du ct FAI de votre pare-feu client : un trafic UDP et ESP ou TCP
       et GRE en provenance de l'adresse IP internet du pare-feu client
       (souvenez vous, on fait du masquage) vers l'adresse IP internet du
       serveur VPN. Si vous ne le voyez pas, votre masquage est mal
       configur, ou bien le patch ne fonctionne pas.
     * Du ct FAI de votre pare-feu serveur : un trafic UDP et ESP ou
       TCP et GRE en provenance de l'adresse IP internet de votre client
       vers l'adresse IP internet du serveur VPN. Si vous ne le voyez
       pas, internet ne marche pas :) ou des quipements intermdiaires
       bloquent le trafic ESP ou GRE.
     * Du ct DMZ de votre pare-feu serveur : un trafic UDP et ESP ou
       TCP et GRE en provenance de l'adresse IP internet du client vers
       l'adresse IP du serveur. Si vous ne le voyez pas, vrifiez les
       rgles pare-feu concernant le suivi de paquets UDP port 500 ainsi
       que ceux porteurs du protocole IP 50 ou TCP port 1723 et protocole
       IP 47, ainsi que la configuration d'ipportfw et de ipfwd si vous
       masquez le serveur.
     * Du ct interne du pare-feu serveur : un trafic UDP (port source
       500) et ESP ou TCP (port source 1723) et GRE en provenance de
       l'adresse IP du serveur VPN et  destination de l'adresse IP
       internet du client. Si vous ne le voyez pas, vrifiez la
       configuration du serveur VPN, y compris les rgles de filtrage de
       paquets sur le serveur VPN.
     * Du ct FAI du pare-feu serveur : un trafic UDP et ESP ou TCP et
       GRE en provenance de l'adresse IP du serveur VPN (ou l'adresse IP
       du pare-feu si le serveur est masqu) vers l'adresse IP internet
       du client. Si vous ne le voyez pas, vrifiez les rgles de votre
       pare-feu concernant la transmission de paquets UDP port 500 ainsi
       que de ceux porteurs du protocole IP 50 ou TCP port 1723 et
       protocole IP 47.
     * Du ct FAI de votre pare-feu client : un trafic UDP et ESP ou TCP
       et GRE en provenance de l'adresse IP du serveur VPN et 
       destination de l'adresse IP internet du pare-feu client. Si vous
       ne le voyez pas, internet se rvolte encore.
     * Du ct rseau local client : un trafic UDP et ESP ou TCP et GRE
       en provenance de l'adresse IP internet du serveur VPN 
       destination de l'adresse IP sur le rseau local du client VPN. Si
       vous voyez le trafic UDP mais pas le trafic ESP, ou bien le trafic
       TCP mais pas le trafic GRE, le patch ne fonctionne pas ou n'a pas
       t install correctement.

   Vous pouvez trouver utile d'activer le dboguage du VPN et de
   recompiler votre noyau. Ajoutez ce qui suit au fichier
   /etc/syslog.conf
# dboguage
*.=debug           /var/log/debug

   et regardez /var/log/messages et /var/log/debug pour les messages
   concernant le trafic VPN. Notez que l'enregistrement -
   particulirement l'enregistrement bavard (verbose log) - va engendrer
   une grande activit disque et va faire grossir trs rapidement les
   journaux. N'activez pas le dboguage si vous n'en avez pas besoin, et
   coupez le quand vous avez fini.
     _________________________________________________________________

5.4. Clients MS PTPP et noms de domaines

   Merci  Charles Curley <ccurley@trib.com> pour ce qui suit :

Si vous utilisez PPTP (Point to Point Tunneling Protocol)
pour accder  un environnement Rseau Microsoft (SMB) et que
vous avez votre propre environnement Rseau Microsoft sur votre
rseau local (Samba ou Windows), donnez  votre groupe de travail
local un nom qui n'est pas connu dans l'environnement distant.
La raison est que tant que votre client PPTP est connect
 l'environnement distant, il va voir les serveurs de noms de
domaine de l'environnement distant, et il ne va voir que les machines
distantes appartenant  ce groupe de travail.

Vous devez viter l'option paresseuse. Microsoft livre Windows
pr-configur pour un groupe de travail par dfaut nomm WORKGROUP.
Il y a des gens paresseux qui vont garder ce nom pour leur groupe
de travail quand ils installeront leurs ordinateurs.
Donc il y a une bonne chance pour que l'environnement distant ait
un groupe de travail appel WORKGROUP, que cela plaise ou non aux
administrateurs.

   Je pense que ceci s'applique indpendamment de l'utilisation du VPN,
   car les services de nommage sont indpendants du transport. Si votre
   (ou vos) client peut voir les serveurs WINS sur le rseau distant,
   vous aurez le problme, avec ou sans PPTP.
     _________________________________________________________________

5.5. Clients PPTP MS et IPX Novell

   Si vous avez des problmes avec le trafic IPX sur votre liaison PPTP,
   lisez les sections 3.5 et 5.2 de cet article de la base de
   connaissances MS :
   http://microsoft.com/ntserver/nts/downloads/recommended/dun13win95/Rel
   easeNotes.asp

   Les mmes considrations s'appliquent probablement galement  W'98.

   Merci  David Griswold <dgriswol@ix.netcom.com>
     _________________________________________________________________

5.6. Problmes de mots de passe rseau MS

   Lorsque vous utilisez un VPN pour accder  un rseau MS,
   souvenez-vous qu'il vous faut fournir deux jetons d'authentification
   diffrents - un pour se connecter au serveur VPN (le mot de passe VPN)
   et l'autre pour accder aux ressources du rseau distant une fois que
   la connexion est tablie (le mot de passe rseau).

   Le mot de passe VPN - le nom d'utilisateur et le mot de passe que vous
   avez entr dans votre client VPN lorsque vous avez initi la connexion
   au serveur VPN - n'est utilis que par le serveur VPN pour vous
   autoriser  vous connecter au rseau via le VPN. Il n'est utilis pour
   rien d'autre une fois que vous tes connect.

   Le mot de passe VPN n'est _pas_ utilis pour prouver votre identit
   aux autres ordinateurs du rseau distant. Pour cela vous devez fournir
   une autre paire nom d'utilisateur/mot de passe - votre mot de passe
   rseau.

   Il y a deux mthodes pour fournir un mot de passe rseau. Votre mot de
   passe rseau peut provenir de la mme paire nom d'utilisateur/mot de
   passe que celle que vous utilisez lorsque vous vous connectez sur le
   rseau local en allumant votre ordinateur. S'il est diffrent, vous
   pouvez configurer votre client VPN pour vous demander votre mot de
   passe pour le rseau distant une fois que la connexion VPN est
   tablie.

   Si vous arrivez  vous connecter au serveur VPN sans pouvoir accder
   aux ressources disponibles sur le rseau distant, alors vous n'avez
   pas fourni une paire nom d'utilisateur/mot de passe valide sur le
   rseau distant. Vrifiez que le nom d'utilisateur et le mot de passe
   pour votre rseau local fonctionnent aussi sur le rseau distant, ou
   configurez votre client VPN pour vous demander un nom d'utilisateur et
   un mot de passe  utiliser sur le rseau distant, et pour vous
   "enregistrer" sur le rseau distant une fois que la connexion VPN est
   tablie.
     _________________________________________________________________

5.7. Si votre session IPsec meurt automatiquement aprs un certain laps de
temps

   Si vous avez des problmes avec votre tunnel IPsec qui meurt
   rgulirement, plus particulirement si une vrification des
   enregistrements sur le pare-feu montrent que des paquets ISAKMP avec
   des valeurs "zero cookie" passent, voici ce qui arrive.

   Les versions antrieures du patch pour le masquage IPsec ne
   changeaient pas le dlai de fin d'attente (timeout) pour les entres
   de la table de masquage des paquets ISAKMP UDP. Les entres de la
   table de masquage pour le trafic ISAKMP UDP vont arriver en fin
   d'attente assez rapidement (comparativement au canal de donnes) et
   vont tre supprimes ; si l'hte IPsec distant dcide alors
   d'initialiser un renouvellement des cls avant que la machine IPsec
   locale ne le fasse, le trafic ISAKMP entrant pour le renouvellement
   des cls ne pourra alors pas tre rout vers la machine masque. Le
   trafic de renouvellement des cls sera rejet, l'hte IPsec distant
   pensera que le lien est tomb, et que la connexion va tre termine.

   Le patch 2.0.x a t modifi depuis sa version initiale pour augmenter
   le dlai de fin d'attente des entres de la table de masquage
   concernant les paquets ISAKMP UDP. Rcuprez la version actuelle du
   patch, disponible sur les sites indiqus dans la section Ressources,
   r-appliquez le patch et recompilez votre noyau.

   Vrifiez galement que votre paramtre Dure de vie de la table de
   masquage IPsec (IPsec Masq Table Lifetime) est configur pour tre
   gal, ou lgrement suprieur,  votre intervalle de renouvellement
   des cls.
     _________________________________________________________________

5.8. Si le masquage VPN ne fonctionne pas aprs le redmarrage

   Vous souvenez-vous d'avoir mis les commandes modprobe ip_masq_pptp.o
   ou modprobe ip_masq_ipsec.o dans votre script de dmarrage
   /etc/rc.d/rc.local au cas o vous avez compil le support de masquage
   VPN en modules ?
     _________________________________________________________________

5.9. Si votre seconde session PPTP tue votre premire session

   La RFC de PPTP prcise qu'il ne peut y avoir qu'un seul canal de
   contrle entre deux systmes. Cela peut vouloir dire qu'un seul client
   masqu est capable de contacter un serveur PPTP donn  un instant
   donn. Regardez pour de plus amples dtails.
     _________________________________________________________________

6. Notes techniques sur le masquage IPsec et considrations spciales sur la
scurit

6.1. Limites et faiblesses du masquage IPsec

   Le trafic utilisant le protocole AH _ne peut pas_ tre masqu. Le
   protocole AH inclut un contrleur d'intgrit cryptographique qui
   couvre les adresses IP, et que la passerelle de masquage ne peut pas
   rgnrer correctement. Donc tout le trafic AH masqu va tre rejet
   car il aura des contrleurs d'intgrit non valides.

   Le trafic IPsec utilisant le mode de transport ESP ne peut pas non
   plus tre correctement masqu. Le mode de transport ESP crypte tout ce
   qui se trouve aprs l'entte IP. Or, par exemple, les contrleurs
   d'intgrit de TCP et UDP incluent les adresses IP source et
   destination, ils se trouvent dans la partie crypte, et ne peuvent
   donc pas tre recalculs aprs que la passerelle de masquage ait
   modifi les adresses IP. L'entte TCP/UDP ne va donc pas passer les
   contrles d'intgrit sur la passerelle distante, et le paquet va tre
   rejet. Les protocoles n'incluant pas les informations sur les
   adresses IP source ou destination peuvent utiliser le masquage du mode
   de transport.

   Ces limites mises  part, le masquage IPsec est sr et fiable 
   condition qu'un seul hte IPsec soit masqu  un instant donn, ou que
   chaque hte masqu communique avec un serveur distant diffrent.
   Lorsque plusieurs machines masques communiquent avec la mme machine
   distante, quelques faiblesses apparaissent :

     * Les communications du mode transport sont sujettes  collisions.
       Si deux machines masques ou plus utilisent le mode transport pour
       communiquer avec le mme hte distant, et si la politique de
       scurit sur l'hte distant permet plusieurs sessions de mode
       transport avec la mme machine, il est possible que les sessions
       aient des collisions. Ceci arrive parce que l'adresse IP de la
       _passerelle de masquage_ va tre utilise pour identifier les
       sessions, et que les autres informations d'identification ne
       pourront pas tre masques puisqu'elles sont dans la portion
       crypte du paquet.
       Si la politique de scurit de l'hte distant n'autorise pas
       plusieurs sessions simultanes en mode transport avec la mme
       machine, la situation est pire : la session en mode transport
       ngocie en dernier va craser _tout_ le trafic de la session
       prcdente, entranant sa "mort". Alors que les sessions tablies
       via l'ancienne session IPsec en mode transport vont tre
       rapidement rinitialises si l'hte distant n'attend pas de
       trafic, au moins un paquet de donnes va tre envoy  la mauvaise
       machine. Ce paquet va probablement tre ignor par le
       destinataire, mais il va tout de mme tre envoy.
       _Donc une collision du mode transport peut avoir comme consquence
       une fuite d'information entre les deux sessions ou bien la fin de
       l'une des deux sessions._ L'utilisation d'IPsec en mode transport
       via une passerelle de masquage _n'est pas recommande_ s'il y a
       une possibilit que d'autres sessions IPsec en mode transport
       soient initialises via la mme passerelle de masquage vers le
       mme hte IPsec distant.
       IPsec en mode tunnel avec une adresse de rseau externe (l'hte
       IPsec masqu se voit attribuer une adresse IP du rseau de l'hte
       distant) n'est _pas_ sujet  ces problmes, car l'adresse IP
       fournie par le rseau distant sera utilise pour identifier les
       sessions plutt que l'adresse IP de la machine masquante.
     * Les communications ISAKMP sont sujettes  des collisions de
       cookies.
       Si deux ou plusieurs machines masques tablissant une session
       avec la mme machine distante utilisent le mme cookie lors de
       l'initialisation du trafic ISAKMP, la passerelle de masquage va
       router tout le trafic ISAKMP vers la seconde machine. Il y a une
       chance sur 2^64 (ie. trs petite) pour que cette collision ait
       lieu lorsque la connexion ISAKMP initiale est tablie.
       Pour corriger cela, il faut inclure le cookie de rponse dans la
       cl utilise pour router le trafic ISAKMP entrant. Cette
       modification est incluse dans le code de masquage IPsec des noyaux
       2.2.x, et la courte priode entre le moment o l'hte masqu
       initialise l'change ISAKMP et la rponse de l'hte distant est
       protge par le bloquage de tout nouveau trafic ISAKMP qui
       pourrait entrer en collision avec le trafic actuel. Cette
       modification va bientt tre porte sur le code des 2.0.x.
     * Il peut y avoir une collision entre les valeurs SPI du trafic
       entrant.
       Deux ou plusieurs htes IPsec masqus communiquant avec la mme
       machine IPsec distante peuvent ngocier pour utiliser la mme
       valeur SPI pour le trafic entrant. Si cela arrive, la passerelle
       de masquage va router tout le trafic entrant vers la premire
       machine qui va recevoir tout le trafic entrant avec ce SPI. La
       probabilit est de 1 sur 2^32 pour chaque session ESP, et le cas
       peut se prsenter  chaque renouvellement de cls.
       Les valeurs SPI sont rattaches  diffrents SA ayant diffrentes
       cls de cryptage, le premier hte ne sera donc pas capable de
       dcrire les donnes destines aux autres machines, donc il n'y
       aura aucune fuite de donnes. Il n'y a aucun moyen pour la
       passerelle de masquage de dtecter ou d'empcher cette collision.
       La seule faon d'empcher cette collision est que l'hte IPsec
       distant vrifie la valeur SPI propose par la machine masque pour
       voir si cette valeur SPI est dj utilise par un autre SA depuis
       la mme adresse IP. Il est peu probable que ceci soit implment
       un jour, car cela imposerait une charge supplmentaire  une
       opration dj coteuse (le renouvellement des cls) pour un
       bnfice concernant un nombre rduit de personnes et un type
       d'vnement assez rare.
     * Les valeurs SPI entrantes et sortantes peuvent tre dissocies.
       Ceci sera vu en dtail dans la section suivante.

   Pour viter ces problmes, le code des noyaux 2.2.x empche par dfaut
   l'tablissement de plusieurs connexions vers la mme machine distante.
   Si vous estimez que la faiblesse lie  plusieurs connexions vers la
   mme machine distante est acceptable, vous pouvez activer les
   "sessions parallles".

   Il peut tre gnant de bloquer pour des raisons de scurit les
   sessions parallles : il n'y a aucun moyen pour le code de masquage
   IPsec de sniffer la session et de voir quand elle se termine, donc les
   entres de la table de masquage vont tre conserves pendant leur
   dure de vie standard, mme si la session se termine juste aprs
   qu'elle ait t tablie. Si l'on empche les sessions parallles, cela
   signifie que le serveur n'acceptera pas d'autre client tant que
   l'entre de la table de masquage la plus rcente sera prsente. Cela
   peut prendre plusieurs heures.
     _________________________________________________________________

6.2. Routage correct du trafic crypt entrant

   La partie de l'change de cls ISAKMP o les valeurs SPI d'ESP sont
   communiques est crypte, donc les valeurs SPI d'ESP doivent tre
   dtermines en tudiant le trafic ESP actuel. Le trafic ESP sortant ne
   contient aucune indication sur ce que sera le SPI entrant. Cela
   signifie qu'il n'y a aucune mthode fiable pour associer le trafic ESP
   entrant avec le trafic ESP sortant.

   Le masquage IPsec tente d'associer le trafic ESP entrant et sortant en
   srialisant le trafic ESP par machine distante. Concrtement :

     * Si un paquet ESP sortant avec une valeur SPI qui n'a pas encore
       t vue (ou dont l'entre dans la table de masquage a expir) est
       reu (il sera appel par la suite un "paquet initial"), une entre
       dans la table de masquage est cre pour cette combinaison
       AdresseSource+SPI+AdresseDest. Elle est marque comme "en
       attente", ce qui signifie qu'aucun trafic correspondant  cette
       entre n'a t pour l'instant reu. Le marquage se fait en mettant
       la valeur "SPI entrant" dans l'entre de la table de masquage 
       zro, qui est une valeur rserve pour cela. Ceci arrivera lors de
       l'initialisation d'une nouvelle connexion ESP et  intervalles
       rguliers lors du renouvellement de cls d'une connexion ESP
       existante.
     * Tant que l'entre de la table de masquage est en attente, aucun
       autre paquet ESP initial  destination du _mme hte distant_
       n'est trait. Les paquets sont immdiatement rejets, et une
       entre du journal systme est ajoute, prcisant que le trafic est
       temporairement bloqu. Ceci s'applique galement au trafic initial
       en provenance de la mme machine masque  destination du mme
       hte distant, si les valeurs SPI sont diffrentes. Le trafic vers
       d'autres htes distants, et le trafic o les deux valeurs SPI sont
       connues (trafic dj "tabli") n'est pas affect.
     * Ceci peut facilement mener  un dni de service sur la machine
       distante, c'est pour cela que la dure de vie de cette entre en
       attente de la table de masquage ESP est faible, et que seul un
       nombre limit de tentatives pour le mme trafic est autoris. Ceci
       permet de faire un accs via round-robin  la machine distante si
       plusieurs machines masques tentent d'initialiser simultanment la
       connexion et que les rponses n'arrivent pas trs vite, par
       exemple  cause d'une congestion rseau, ou d'une machine distante
       lente. Le dcompte des tentatives commence ds qu'il y a une
       collision, donc l'hte IPsec masqu peut attendre une rponse
       aussi longtemps qu'il le faut jusqu' ce qu'il soit ncessaire de
       faire une mise en srie des connexions.
     * Quand un paquet ESP est reu en provenance de l'hte distant en
       attente, et que la valeur SPI n'apparat dans aucune entre de la
       table de masquage, il est suppos que le paquet est la rponse au
       paquet en attente initial. La valeur SPI est stocke dans l'entre
       courante de la table de masquage associant les valeurs SPI, et le
       trafic ESP entrant est alors rout vers la machine masque. A ce
       point un autre paquet initial destin au serveur distant peut tre
       trait.
     * Tout trafic ESP avec une valeur SPI de zro est rejet comme tant
       invalide, conformment au RFC.

   Il y a plusieurs possibilits pour que l'association de trafic ne se
   fasse pas proprement :

     * La latence du rseau ou la lenteur d'une machine distante peuvent
       retarder suffisamment la rponse au paquet initial pour que
       l'entre de la table de masquage ait expir, et qu'une autre
       machine masque ait eu sa chance d'initialiser un trafic. Ceci
       peut faire que la rponse sera associe au mauvais SPI sortant, et
       donc le trafic entrant sera rout vers la mauvaise machine
       masque. Si cela arrive, la machine masque recevant le trafic par
       erreur le rejettera parce qu'il n'aura pas la valeur SPI attendue,
       et tout le monde risque de patienter jusqu' la fin du temps
       d'attente pour faire un nouvel change de cls, et ressayer. On
       peut y remdier en ditant /usr/src/linux/net/ipv4/ip_masq.c
       (ip_masq_ipsec.c dans le 2.2.x) et en augmentant la dure de vie
       d'INIT ou le nombre de tentatives INIT autorises, avec pour cot
       l'agrandissement de la fentre de bloquage (et de dni de
       service).
     * Les sessions inactives ou semi-inactives (avec un trafic entrant
       peu frquent et aucun trafic sortant) sur une longue priode
       peuvent le rester suffisamment longtemps pour que l'entre de la
       table de masquage expire. Si la machine distante envoie du trafic
       d'une session ayant dj expir au niveau de la table de masquage
       pendant qu'une initialisation est en cours vers la mme machine,
       le trafic peut tre incorrectement rout, pour la mme raison que
       plus haut. On peut y remdier en s'assurant que le paramtre de
       configuration du noyau IPsec Masq Table Lifetime est lgrement
       plus grand que l'intervalle de renouvellement des cls, qui est la
       dure la plus longue que les paires SPI peuvent utiliser. Le
       problme ici est que vous ne pouvez pas connatre tous les
       intervalles de renouvellement des cls si vous masquez plusieurs
       serveurs distants, ou que certains peuvent avoir leurs intervalles
       de renouvellement des cls positionns  des valeurs
       draisonnablement leves, comme plusieurs heures.
     * S'il y a un dlai entre un renouvellement de cls et la
       transmission du trafic ESP sortant utilisant le nouveau SPI, et si
       durant ce dlai un trafic ESP entrant utilisant ce nouveau SPI est
       reu, il n'y a pas d'entre de la table de masquage dcrivant
       comment router le trafic entrant. Si une autre machine masque a
       une initialisation en attente avec le mme hte distant, le trafic
       va tre dissoci. Notez que la srialisation du trafic ESP initial
       n'affecte _pas_ le trafic de renouvellement des cls ISAKMP.

   La meilleure solution est d'avoir un moyen de pr-charger la table de
   masquage avec les bonnes paires SPI-sortie/SPI-entre, ou une autre
   forme d'association machine_distante + SPI_entre avec la
   machine_masque. Cela ne peut pas tre fait en suivant l'change de
   cls ISAKMP, car il est crypt. Il peut tre possible d'utiliser RSIP
   (galement connu en tant que Translation d'Adresse Rseau pour un hte
   (NdT : Host-NAT)) pour communiquer avec l'hte IPsec masqu et
   demander une notification sur les informations SPI une fois que la
   ngociation a eu lieu. Ce point est  tudier. Si quelque chose est
   fait pour l'implmenter, ce ne sera pas fait avant les sries 2.3.x,
   car RSIP est un protocole NAT client/serveur assez complexe.

   Quand un paquet ESP entrant avec un nouveau SPI est reu, le pare-feu
   de masquage tente de deviner  quel(s) hte(s) masqu(s) ce trafic
   entrant est destin. Si le trafic ESP entrant ne correspond pas  une
   session tablie, ou  une session en cours d'initialisation, alors le
   paquet est envoy  la (aux) machine(s) masque(s) qui a (ont)
   renouvel en dernier ses (leurs) cls avec cet hte distant. Les
   machines masques "incorrectement" vont rejeter le trafic comme
   n'tant pas correctement crypt, et la machine "correctement" masque
   va recevoir des donnes. Lorsque la machine "correctement" masque
   rpond, le processus normal de srialisation de l'initialisation ESP a
   lieu.
