$Revision: 1.1.1.1 $ $Date: 2003/01/03 02:38:54 $
Ce document d�crit comment configurer un pare-feu Linux pour masquer le trafic d'un r�seau priv� virtuel (NdT: Virtual Private Network, VPN) utilisant IPsec ou PPTP, vous permettant ainsi d'�tablir une connexion VPN sans perdre ni la s�curit� ni la flexibilit� apport�es 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.
Ce document d�crit comment configurer le masquage d'un trafic VPN de type IPsec ou PPTP. Les VPNs utilisant SSH (comme celui vendu par F-Secure, et r�f�renc� dans le VPN mini-HOWTO) sont fond�s sur un trafic TCP standard, et ne n�cessitent aucune modification particuli�re 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'Acc�s 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 r�seau priv� (voir le RFC1918) derri�re un pare-feu Linux faisant du masquage, vous permettant ainsi de fournir de fa�on assez s�curis�e un acc�s � un r�seau priv� via seulement une seule adresse IP r�f�renc�e - y compris si cette adresse IP repr�sente celle d'une connexion modem pouvant varier.
Il est tr�s 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 d�passent le cadre de ce document. Voici quelques ressources :
Le patch pour les noyaux de la s�rie 2.0.x fonctionne bien sur la version 2.0.36 du noyau Linux, et a �t� int�gr� dans la version 2.0.37. Il doit �galement fonctionner sur les versions ant�rieures � 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, n�cessitant un patch diff�rent pour les s�ries 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 ant�rieurs.
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'h�sitez 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-Masquerade.html
PostScript: ftp://ftp.rubyriver.com/pub/jhardin/masquerade/VPN-howto/VPN-Masquerade.ps.gz
SGML source: ftp://ftp.rubyriver.com/pub/jhardin/masquerade/VPN-Masquerade.sgml
Il peut �galement �tre trouv� via le r�pertoire HOWTO du Linux Documentation Project et le r�pertoire /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 d�pass�es.
J'ai personnellement de l'exp�rience 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-r�seaux.
Les informations sur le masquage d'un serveur PPTP avec une adresse IP priv�e 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 s�ries 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 contr�lant la redirection de port des 2.2.x peut �tre obtenu � l'adresse http://juanjox.kernelnotes.org/.
Le site pour le redirecteur IP g�n�rique 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 d�tection 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 r�cup�r� sans vergogne quelques id�es tr�s importantes...
De plus amples informations sur comment installer des r�gles de pare-feu s'ex�cutant 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 conseill�e.
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-mp.tgz pour Multilink. Un autre ensemble de patchs (probablement int�ressants) pour pppd est disponible sur le site de t�l�chargement 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 fonctionnalit�s 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).
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 exp�rimental, 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 d�cider si vous souhaitez effectuer les changements indiqu�s 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. |
Un R�seau Priv� Virtuel (Virtual Private Network), ou "VPN", est un tunnel qui v�hicule le trafic d'un r�seau priv� d'un syst�me terminal vers un autre, en empruntant un r�seau public (comme l'internet), sans que les interm�diaires entre les deux machines terminales soient visibles du point de vue du trafic v�hicul�, et sans que les �quipements interm�diaires voient les paquets qui sont en train de transiter dans le tunnel. Le tunnel peut en option compresser et/ou crypter les donn�es, fournissant des performances accrues et quelques mesures de s�curit�.
La partie "Virtuelle" vient du fait que vous construisez une liaison priv�e au dessus d'un r�seau public, plut�t que d'acheter une liaison en dur sur une ligne lou�e. Le VPN vous permet de consid�rer que vous utilisez une ligne lou�e ou une ligne t�l�phonique 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.
IPsec est un ensemble de protocoles standards pour impl�menter des communications s�curis�es ainsi que l'�change de cl�s de cryptage entre ordinateurs. Il peut �tre utilis� pour mettre en place un VPN.
Un r�seau priv� virtuel IPsec consiste g�n�ralement en deux canaux de communication entre les machines terminales : un canal d'�change de cl�s, par lequel les informations sur l'authentification et les cl�s de cryptage transitent, et un ou plusieurs canaux de donn�es par lesquels le trafic du r�seau priv� est v�hicul�.
Le canal d'�change de cl�s est une connexion UDP standard en provenance de et vers le port 500. Le canal de donn�es transportant le trafic entre le client et le serveur utilise le protocole IP num�ro 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 num�ro 51), RFC2406 (le protocole ESP, protocole IP num�ro 50), et RFC2408 (le protocole d'�change de cl�s ISAKMP).
IPsec est un protocole de communication sym�trique. Cependant, vu que la plupart des gens vont s'y trouver confront� uniquement sous la forme d'un client Windows acc�dant � une passerelle centrale de s�curit� r�seau, le terme "client" va �tre utilis� pour d�signer la machine devant laquelle l'utilisateur est assis, et le terme "serveur" va �tre utilis� pour d�signer la passerelle centrale de s�curit� r�seau.
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 contr�leur d'int�grit� cryptographique sur des parties de l'ent�te 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 cl�s, elle ne peut pas r�g�n�rer correctement les contr�leurs d'int�grit� cryptographiques pour les ent�tes IP modifi�s. Les paquets IP modifi�s seront donc rejet�s par le destinataire comme des paquets invalides, car ils ne passeront pas le test d'int�grit� cryptographique.
PPTP signifie Point-to-Point Tunnelling Protocol. C'est un protocole propos� par Microsoft pour r�aliser un VPN.
Le protocole VPN PPTP consiste en deux canaux de communication entre le client et le serveur : un canal de contr�le par lequel les informations de gestion du lien transitent, et un canal de donn�es par lequel le trafic (�ventuellement crypt�) du r�seau priv� est v�hicul�.
Le canal de contr�le est une connexion TCP standard vers le port 1723 du serveur. Le canal de donn�es v�hiculant le trafic du r�seau priv� utilise le protocole IP num�ro 47, un protocole d'encapsulation g�n�rique d�crit dans le RFC1701. La transmission transparente des donn�es sur le canal de donn�es est r�alis�e par la n�gociation 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 n�goci�es sur le tunnel via le protocole PPP contr�lent si les donn�es sont compress�es et/ou crypt�es, et donc PPTP n'a rien � voir avec le cryptage.
Les d�tails du protocole PPTP sont document�s dans le RFC2637.
L'impl�mentation du protocole PPTP par Microsoft n'est pas consid�r�e comme tr�s s�curis�e. Si vous �tes int�ress�s par les d�tails, voici trois analyses diff�rentes :
http://www.counterpane.com/pptp.html
FWZ est un protocole de cryptage propri�taire d�velopp� 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 diff�rents 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.
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'acc�s internet contourne votre pare-feu Linux, la s�curit�, ainsi que les capacit�s de partage d'acc�s qu'il fournit. �tendre le pare-feu Linux pour aussi masquer le trafic VPN vous permet de conserver la s�curit� pare-feu fournie par le pare-feu Linux, ainsi que d'autoriser d'autres syst�mes de votre r�seau local � acc�der � 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 s�curit�, plut�t que de leur fournir des modems pour qu'ils puissent se connecter tout seuls � l'ext�rieur quand ils ont besoin d'utiliser le VPN. Le masquage VPN vous permet de le faire m�me si les machines clientes n'ont pas des adresses IP publiques.
Oui, bien qu'il puisse y avoir parfois quelques probl�mes mineurs.
Les protocoles IPsec d�finissent une m�thode pour identifier les flux de trafic appel�e Index des Param�tres de S�curit� (Security Parameters Index) ("SPI"). Malheureusement le SPI utilis� pour le trafic sortant est diff�rent du SPI utilis� pour le trafic entrant, et il n'y a pas d'autre information permettant l'identification qui ne soit pas crypt�e, 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 s�rie les nouvelles connexions. Alors que ceci fonctionne bien pendant les tests, on ne peut pas garantir que ce soit parfaitement fiable, et la s�rialisation des nouveaux trafics peut aboutir � des fins d'attente (timeouts) si la liaison est satur�e ou si plusieurs machines locales faisant de l'IPsec tentent d'initier des communications ou de r��changer leurs cl�s simultan�ment, avec la m�me machine distante faisant de l'IPsec.
Il est �galement reconnu que ce sch�ma 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 probl�mes auraient pu �tre supprim�s s'il y avait eu un moyen d'�couter les nouvelles valeurs SPI provenant de l'�change de cl�s ISAKMP avant que le moindre trafic ESP n'apparaisse, mais malheureusement cette partie de l'�change de cl�s est crypt�e.
Afin de minimiser les probl�mes associ�s � cela, il est recommand� d'ouvrir une fen�tre de commandes sur votre machine IPsec masqu�e, et de lancer le programme "ping" vers une machine du r�seau distant pour maintenir le tunnel actif.
Regardez les notes techniques sur IPsec � la fin du document pour de plus amples d�tails.
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 diff�rents flux de donn�es en provenance du m�me serveur. Le masquage PPTP avec le masquage d'identifiant d'appel activ� va permettre d'avoir plusieurs sessions masqu�es simultan�es sans restriction sur le choix du serveur que le client appelle.
Le RFC sur PPTP sp�cifie dans la section 3.1.3 qu'il ne peut y avoir qu'un seul canal de contr�le entre deux syst�mes. Ceci devrait signifier que vous pouvez masquer seulement une session PPTP � la fois avec un serveur distant donn�, mais dans la pratique l'impl�mentation 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 masqu�s cherchant � se connecter au m�me serveur distant.
Pour d'autres alternatives, voir la question suivante...
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 g�re, 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 acc�s. Ceci est peu efficace, esth�tiquement r�voltant, s�curitairement mauvais, et peut ne pas fonctionner si le serveur PPTP impl�mente correctement le protocole, mais c'est moins cher que d'acheter des licences NT.
Le routage r�seau � r�seau avec cette m�thode fonctionne tr�s bien. C'est comme �a que j'ai install� mon r�seau � la maison. Cela requiert un petit peu plus de connaissances r�seau que de simplement donner � tout le monde son client VPN.
De par mon exp�rience, le routage de r�seau � r�seau dans un environnement purement MS requiert l'installation de RRAS des deux c�t�s du tunnel.
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 r�seau 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 m�me si vous n'avez qu'une seule adresse IP publique. Ceci devrait aussi fonctionner m�me si votre adresse IP est assign�e 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 appel�e notre-entreprise.ddns.org ou quelque chose du genre. Notez que ceci est une faille de s�curit�, car il est possible que le client r�cup�re du serveur DNS dynamique une mauvaise adresse IP � cause d'une mauvaise synchronisation, suite � un probl�me lors de l'enregistrement de l'adresse IP actuelle, ou suite � l'enregistrement d'une adresse IP diff�rente avec le m�me nom par une tierce partie.
Le plus gros probl�me 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 n�cessite une modification du noyau.
Le canal de contr�le PPTP est du TCP pur, et ne n�cessite aucune configuration particuli�re autre que de le laisser passer au travers du pare-feu et de le masquer.
Masquer les canaux de donn�es IPsec et PPTP n�cessite une modification qui ajoute le support des protocoles ESP et GRE au code de masquage, et le masquage du protocole d'�change de cl�s ISAKMP n�cessite une modification qui emp�che l'op�ration de masquage de modifier le num�ro de port UDP source et qui remplace le suivi des valeurs de cookies ISAKMP par le suivi du num�ro de port.
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 sup�rieurs. Il devrait fonctionner sur les noyaux ant�rieurs, 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 s�curit�.
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 r�cents, 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 d�veloppement, 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 probl�me majeur pour le porter sur d'autres architectures. Je crois que les d�pendances vis-�-vis des architectures proviennent seulement de la repr�sentation interne des nombres dans la d�finition de l'ent�te GRE utilis� pour formater les messages du journal et de d�boguage. Si quelqu'un porte ce patch pour une architecture autre qu'Intel, j'appr�cierais d'en avoir un �cho, afin que je puisse int�grer les changements � la version d'origine.
Un patch noyau sp�cifique � 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 sp�cifique pour PPTP s'appliquant aux 2.1.105+/2.2.x.
Pour les exemples de configuration avec des adresses IP priv�es de ce document, nous allons utiliser cet exemple de r�seau :
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
| |
Internet-------- 200.200.200.200 eth1
Pare-feu Linux � deux cartes
.--- 222.0.0.1 eth0
|
|--- 222.0.0.2 Client ou serveur VPN
| |
Les clients VPN qui se connecteront au serveur des exemples seront 199.0.0.2 et 199.0.0.3
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 r�seau priv� comme d�crit dans le RFC1918 vous avez besoin de patcher votre noyau (� moins que ce ne soit un noyau 2.0.37 ou sup�rieur, dans la s�rie 2.0.x).
Si vous installez un serveur VPN masqu�, vous allez aussi devoir r�cup�rer les deux paquetages suivants.
Pour rediriger le trafic TCP/UDP entrant (le canal de contr�le PPTP 1723/tcp ou le canal ISAKMP 500/udp), vous avez besoin du patch noyau de redirection de port appropri� ipportfw r�cup�rable sur http://www.ox.compsoc.org.uk/~steve/portforwarding.html. La redirection de port a �t� incorpor�e dans les noyaux 2.2.x. Regardez man ipmasqadm pour les d�tails 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 g�n�rique 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.
Installez les sources du noyau (de pr�f�rence version 2.0.37), que vous pouvez obtenir sur http://www.kernel.org/ ou un site miroir. Les sources doivent se d�compacter automatiquement dans le r�pertoire /usr/src/linux.
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.
Sauvegardez les sources de votre noyau.
R�cup�rez le patch noyau si n�cessaire.
Si la version de votre noyau est 2.0.36 ou inf�rieure, r�cup�rez 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 s�rie 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.
Appliquez le patch de masquage VPN � votre noyau, si n�cessaire :
Allez dans le r�pertoire 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 r�sultats �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. |
V�rifiez le contenu du fichier vpn-patch.log pour voir si certaines �tapes ont �chou�. Si certaines �tapes n'ont pas fonctionn�, alors vous avez s�rement oubli� des options, ou lanc� le programme patch depuis le mauvais r�pertoire. Utilisez votre sauvegarde pour r�cup�rer votre noyau, et recommencez.
Si vous masquez un serveur VPN, r�cup�rez 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 r�seau : le patch de cha�nes pare-feu IP (ipchains), et le patch ipportfw. Ils cherchent tous � ajouter des options au m�me endroit dans net/ipv4/Config.in, et les changements effectu�s par un patch alt�rent le contexte recherch� par les autres patchs.
Si vous appliquez le patch de masquage VPN et les patchs de cha�nes 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� appliqu�es. En regardant le fichier patch vous devez trouver o� les nouvelles options doivent �tre ajout�es 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 premi�re indique l'�tat "avant" avec une indication des lignes devant �tre chang�es ou effac�es ; la seconde indique l'�tat "apr�s", avec une indications des lignes qui ont �t� chang�es ou ajout�es. Utilisez la premi�re partie pour trouver o� ajouter les lignes, et ajoutez les lignes qui sont indiqu�es dans la seconde partie.
Ceci ne devrait pas �tre un probl�me, ces patchs �tant � jour pour les noyaux 2.0.37+.
Configurez votre noyau et s�lectionnez les options suivantes - r�pondez 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 n�cessaire.
* IP: PPTP masq support (EXPERIMENTAL)
CONFIG_IP_MASQUERADE_PPTP
- Active le masquage de canal de donn�es 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; n�cessaire
uniquement si vous comptez masquer plusieurs clients
se connectant au m�me 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 r�seau pour d�terminer
quel est "l'intervalle de renouvellement des cl�s"
ou la "dur�e de validit� d'une cl�".
La dur�e de validit� par d�faut pour les entr�es de la
table de masquage est de trente minutes.
Si l'intervalle de renouvellement des cl�s est sup�rieur
� trente minutes, vous devez alors augmenter la dur�e
de validit� jusqu'� une valeur l�g�rement sup�rieure
� l'intervalle de renouvellement des cl�s.
* IP: always defragment
CONFIG_IP_ALWAYS_DEFRAG
- Tr�s fortement recommand� pour un pare-feu.
|
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 v�rifi� qu'il fonctionnait.
Pour d�terminer si le noyau qui tourne inclut ou non le support du masquage VPN, lancez la commande suivante :
grep -i masq /proc/ksyms |
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 entr�es, 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 syst�me de fichiers /proc dans la configuration de votre noyau.
Regardez le Kernel HOWTO pour plus de d�tails sur la configuration et la recompilation de votre noyau.
Si vous utilisez le masquage IPsec et que votre syst�me g�n�re des erreurs de protection g�n�rale (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 ant�rieurs. Il a �t� soumis � Alan Cox pour �tre inclus dans le noyau 2.0.39.
Installez les sources du noyau (de pr�f�rence 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 r�pertoire /usr/src/linux.
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.
Sauvegardez les sources de votre noyau.
R�cup�rez 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.
Appliquez le patch de masquage VPN � votre noyau, si n�cessaire.
Allez dans le r�pertoire 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 z�ro". Vous pourriez avoir des r�sultats �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. |
Notez �galement que le r�pertoire depuis lequel vous lancez la commande patch est diff�rent pour le patch noyau 2.2.x. |
V�rifiez le contenu du fichier vpn-patch.log pour voir si certaines �tapes ont �chou�. Si des �tapes ont �chou�, alors vous avez s�rement oubli� des options, ou lanc� la commande patch depuis le mauvais r�pertoire. Utilisez votre sauvegarde pour r�cup�rer votre noyau, et recommencez.
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 d�tails. Si ipmasqadm n'est pas inclus dans votre distribution, vous pouvez l'obtenir � l'adresse http://juanjox.kernelnotes.org/.
Configurez votre noyau et s�lectionnez les options suivantes - r�pondez 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
- N�cessaire pour le masquage. Cette option peut �tre
ou ne pas �tre dans la configuration de votre
noyau. Si elle n'est pas pr�sente, vous
devez ex�cuter ceci dans vos scripts de d�marrage :
echo 1 > /proc/sys/net/ipv4/ip_always_defrag
* IP: masquerading (EXPERIMENTAL)
CONFIG_IP_MASQUERADE
- Option n�cessaire.
* IP: masquerading special modules support
CONFIG_IP_MASQUERADE_MOD
- Option n�cessaire.
* 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 donn�es 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 sp�cifier
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 r�seau pour d�terminer
quel est "l'intervalle de renouvellement des cl�s"
ou "la dur�e de validit� d'une cl�".
La dur�e de validit� par d�faut pour les entr�es de la
table de masquage est de trente minutes.
Si l'intervalle de renouvellement des cl�s est sup�rieur
� trente minutes, vous devez alors augmenter la dur�e
de validit� jusqu'� une valeur l�g�rement sup�rieure
� l'intervalle de renouvellement des cl�s.
* 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 sp�ciale sur les informations sur la s�curit� de ce HOWTO
pour �tre au courant des probl�mes de s�curit� lorsque
vous faites du masquage. Si vous ne masquez qu'un seul client
IPsec, cette option n'a aucun effet.
|
* 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 utilis�s
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 list�es ci-dessus n'apparaissent pas lorsque
vous configurez votre noyau. N'activez PAS cette
option, sauf si vous impl�mentez un tunnel GRE
vers un routeur Cisco.
|
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 |
Masquage IPsec : ip_masq_esp et ip_demasq_esp
Masquage PPTP : ip_masq_pptp_tcp et ip_demasq_pptp_tcp
lsmod |
Masquage IPsec : ip_masq_ipsec
Masquage PPTP : ip_masq_pptp
Si vous ne voyez pas ces entr�es, 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 compil�s en modules ? Si le masquage VPN ne fonctionne plus apr�s le red�marrage de la machine, avez-vous ins�r� les commandes modprobe dans votre fichier de d�marrage /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 syst�me 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.
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 param�trage du filtrage de paquets au niveau de la s�curit�.
Les r�gles pare-feu minimales sont :
# Met la politique par d�faut de transmission des paquets � REFUS ipfwadm -F -p deny # Autorise le trafic sur le r�seau 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 |
Un param�trage de pare-feu rigoureux n'autoriserait que le trafic entre le client et le serveur, et bloquerait tout le reste :
# Met la politique par d�faut � REFUS : ipfwadm -I -p deny ipfwadm -O -p deny ipfwadm -F -p deny # Autorise le trafic sur le r�seau 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 r�gles n'autorisent que le trafic VPN et bloquent tout le reste. Vous devez ajouter des r�gles pour tous les autres flux que vous voulez autoriser, comme par exemple DNS, HTTP, POP, IMAP, etc...
Les r�gles pare-feu ipchains minimales sont :
# Met la politique par d�faut de transmission des paquets � REFUS ipchains -P forward DENY # Autorise le trafic sur le r�seau 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 |
Un param�trage de pare-feu rigoureux n'autoriserait que le trafic entre le client et le serveur, et bloquerait tout le reste :
# Met la politique par d�faut � REFUS : ipchains -P input DENY ipchains -P output DENY ipchains -P forward DENY # Autorise le trafic sur le r�seau 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 500 -i ppp0 ipchains -A output -j ACCEPT -p udp -s 200.200.200.0/24 500 -d 199.0.0.1/32 500 -i ppp0 ipchains -A input -j ACCEPT -p udp -s 199.0.0.1/32 500 -d 200.200.200.0/24 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/24 -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.200/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.200/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/32 -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/32 -i eth1 |
Note : ces r�gles n'autorisent que le trafic VPN. Vous devrez ajouter des r�gles pour tous les autres flux que vous souhaitez autoriser, comme par exemple DNS, HTTP, POP, IMAP, etc...
Notez �galement combien ces r�gles sont plus propres et plus faciles � comprendre que les r�gles ipfwadm �quivalentes. C'est parce que ipchains autorise la sp�cification de tous les protocoles IP, et pas seulement TCP, UDP, ICMP, ou ALL.
Si votre pare-feu se voit attribuer une adresse IP dynamique par votre FAI (les comptes modems fonctionnent comme �a, ainsi que certains cablo-op�rateurs), alors vous devez ajouter ce qui suit au script de d�marrage /etc/rc.d/rc.local:
echo 7 > /proc/sys/net/ipv4/ip_dynaddr |
Si vous ne le faites pas, il peut y avoir une "p�riode de latence" apr�s la reconnexion et avant l'expiration des anciennes entr�es de la table de masquage pendant laquelle vous serez masqu� avec la mauvaise adresse IP, ce qui vous emp�chera d'�tablir une connexion.
Ceci est particuli�rement utile si vous utilisez un d�mon de demande de connexion comme diald pour g�rer votre connexion modem.
Regardez le fichier /usr/src/linux/Documentation/networking/ip_dynaddr.txt pour de plus amples d�tails.
Si vous mettez en place le masquage VPN pour un serveur VPN avec une adresse IP priv�e (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 sp�cifique du pare-feu vers une machine sur le r�seau local derri�re le pare-feu. Il est utilis� pour rediriger le canal de contr�le PPTP initial 1723/tcp en entr�e, ou le trafic ISAKMP 500/udp vers le serveur VPN. L'autre (ipfwd) est un outil de transmission de paquets plus g�n�rique, 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 donn�es vers le serveur VPN.
Les sorties en r�ponse au trafic entrant 1723/tcp ou 500/udp sont masqu�es gr�ce aux fonctionnalit�s standard de masquage IP du noyau Linux. Le trafic sortant 47/ip ou 50/ip est masqu� gr�ce au patch du noyau pour le masquage VPN que vous avez install� pr�c�demment.
Une fois que ces outils sont install�s, vous devez les configurer pour faire suivre le trafic vers le serveur VPN.
Param�trer ipportfw pour les noyaux 2.0.x
Les commandes suivantes vont param�trer ipportfw pour faire suivre le trafic 500/udp entrant vers le serveur IPsec :
# Param�trage 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 |
# Param�trage 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 |
# Param�trage 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 |
# Param�trage 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 |
Configurer ipfwd pour les noyaux 2.0.x et 2.2.x
La commande suivante va param�trer ipfwd pour faire suivre le trafic entrant 50/ip initial au le serveur IPsec :
/sbin/ipfwd --masq 10.0.0.2 50 & |
/sbin/ipfwd --masq 10.0.0.2 47 & |
Les techniques d�crites ici peuvent �tre g�n�ralis�es pour autoriser le masquage de la plupart des serveurs - HTTP, FTP, SMTP, etc. Les serveurs qui sont bas�s 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 emp�cher 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 simultan�ment un serveur PPTP et des clients PPTP.
Mettre en place un serveur VPN avec une adresse IP publique se trouvant derri�re un pare-feu Linux est un simple probl�me de routage et de filtrage de paquets. Le masquage n'est pas n�cessaire.
Malheureusement les noyaux 2.0.x ne nous permettent pas de pr�ciser le protocole IP 47 ou 50, donc ce pare-feu est moins s�r que ce qu'il aurait pu �tre. Si cela vous pose un probl�me, alors installez le patch noyau pour les cha�nes pare-feu IP ou passez � un noyau de la s�rie 2.1.x ou 2.2.x, avec lesquels vous pouvez faire du filtrage par protocole IP.
Les r�gles pare-feu vont avoir un peu cette t�te l� :
# Cette section doit se trouver apr�s vos autres r�gles pare-feu # Pr�cisez explicitement les clients potentiels pour plus de s�curit� # 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 222.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 222.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 222.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 222.0.0.2/32 500 # Autorise le canal de contr�le PPTP en entr�e 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 r�gle "d�faut 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 # Pr�cisez explicitement les clients potentiels pour plus de s�curit� # Notez que ce param�trage est trop large, car nous sommes # oblig�s de pr�ciser "-P all" au lieu de "-P 47" ou "-P 50"... # Autorise le canal de donn�es 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 r�gle du type "par d�faut, refus" # qui ne s'applique qu'� l'interface internet. ipfwadm -I -a deny -W eth1 -V 200.200.200.200 |
Si vous installez des r�gles pare-feu ou des r�gle 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'ins�rer dans votre param�trage pare-feu actuel pour autoriser les autres trafics dont vous avez besoin.
La mise en place d'un client VPN avec une adresse IP publique derri�re un pare-feu Linux est similaire � celle d'un serveur VPN avec une adresse IP publique.
Les r�gles 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 199.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 199.0.0.1/32 500 # Autorise le canal de contr�le PPTP en entr�e 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 r�gle "par d�faut, 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 param�trage est trop large, car nous sommes # oblig�s de pr�ciser "-P all" au lieu de "-P 47" ou "-P 50"... # Autorise le canal de donn�es 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 r�gle du type "par d�faut, refus" # qui ne s'applique qu'� l'interface internet. ipfwadm -I -a deny -W eth1 -V 200.200.200.200 |
Mettre en place un serveur VPN avec une adresse IP publique derri�re un pare-feu Linux correspond � v�rifier que les commandes de routage et de filtrage de paquet appropri�es sont bien en place. Le masquage n'est pas n�cessaire.
Les r�gles pare-feu auront cette allure :
# Sp�cifiez explicitement les clients potentiels pour plus de s�curit�. # 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 contr�le PPTP en entr�e et en sortie. ipchains -A input -j ACCEPT -p tcp -s 199.0.0.2/32 -d 222.0.0.2/32 1723 -i eth1 ipchains -A output -j ACCEPT -p tcp -d 199.0.0.2/32 -s 222.0.0.2/32 1723 -i eth1 ipchains -A input -j ACCEPT -p tcp -s 199.0.0.3/32 -d 222.0.0.2/32 1723 -i eth1 ipchains -A output -j ACCEPT -p tcp -d 199.0.0.3/32 -s 222.0.0.2/32 1723 -i eth1 # Autorise le tunnel PPTP en entr�e et en sortie. ipchains -A input -j ACCEPT -p 47 -s 199.0.0.2/32 -d 222.0.0.2/32 -i eth1 ipchains -A output -j ACCEPT -p 47 -d 199.0.0.2/32 -s 222.0.0.2/32 -i eth1 ipchains -A input -j ACCEPT -p 47 -s 199.0.0.3/32 -d 222.0.0.2/32 -i eth1 ipchains -A output -j ACCEPT -p 47 -d 199.0.0.3/32 -s 222.0.0.2/32 -i eth1 |
Si vous installez des r�gles pare-feu ou des r�gles 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'ins�rer dans votre param�trage pare-feu actuel pour autoriser les autres trafics dont vous avez besoin.
La mise en place d'un client VPN avec une adresse IP publique derri�re un pare-feu Linux est identique � celle d'un serveur VPN avec une adresse IP publique.
Les r�gles 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 contr�le PPTP en entr�e et en sortie. ipchains -A output -j ACCEPT -p tcp -s 222.0.0.2/32 -d 199.0.0.1/32 1723 -i eth1 ipchains -A input -j ACCEPT -p tcp -d 222.0.0.2/32 -s 199.0.0.1/32 1723 -i eth1 # Autorise le tunnel PPTP en entr�e et en sortie. ipchains -A output -j ACCEPT -p 47 -s 222.0.0.2/32 -d 199.0.0.1/32 -i eth1 ipchains -A input -j ACCEPT -p 47 -d 222.0.0.2/32 -s 199.0.0.1/32 -i eth1 |
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 r�seaux, et un lecteur de disquette, vous pouvez mettre en place un pare-feu masquant avec toutes les fonctionnalit�s. Aucun disque dur n'est n�cessaire.
Le masquage VPN est cens� �tre inclus dans la version 2.2.9 de LRP - pour v�rifier 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 d�crit plus haut. Si vous voulez ajouter le masquage VPN � une version ant�rieure 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 r�gles pare-feu seront ajout�es au script de d�marrage dans Network Settings -> Direct Network Setup.
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 m�mes protocoles, ils ne peuvent pas cohabiter sur le m�me ordinateur.
Votre pare-feu peut, cependant, �tre une passerelle VPN IPsec FreeS/WAN et faire du masquage PPTP, ou vice-versa.
Configurez votre routage pour que votre pare-feu Linux soit votre passerelle par d�faut :
Ouvrez Panneau de configuration/R�seau ou faites un clic droit sur "Voisinage R�seau" et cliquez sur Propri�t�s.
Cliquez sur l'onglet Configuration.
Dans la liste des composants r�seaux install�s, faites un double-clic sur la ligne "TCP/IP -> votre-carte-r�seau".
Cliquez sur l'onglet Passerelle.
Entrez l'adresse IP locale de votre pare-feu Linux. Enlevez les autres passerelles.
Cliquez sur le bouton "OK".
Testez le masquage. Par exemple, lancez "telnet le.serveur.de.mail.de.mon.fai smtp" et vous devriez voir la banni�re d'accueil du serveur de mail.
Installez et configurez le logiciel de VPN. Pour le logiciel IPsec, suivez les instructions de l'�diteur. Pour PPTP de MS :
Ouvrez Panneau de Configuration/R�seau ou faites un clic droit sur "Voisinage R�seau" et cliquez sur Propri�t�s.
Cliquez sur l'onglet Configuration.
Cliquez sur le bouton "Ajouter", et cliquez ensuite sur la ligne "Carte".
S�lectionnez "Microsoft" comme constructeur, et ajoutez l'adaptateur "Carte de R�seau Priv� Virtuel Microsoft".
Red�marrez lorsque l'ordinateur vous le demande.
Si vous avez besoin de cryptage fort (128 bits), t�l�chargez la mise � jour pour cryptage fort de DUN 1.3 sur le site s�curis� de MS � l'adresse http://mssecure.www.conxion.com/cgi-bin/ntitar.pl et installez la, red�marrez ensuite quand l'ordinateur vous le demande.
Cr�ez une nouvelle entr�e dans votre carnet d'adresse d'appel distant pour votre serveur PPTP.
S�lectionnez l'adaptateur VPN comme p�riph�rique � utiliser, et entrez l'adresse IP internet du serveur PPTP comme num�ro de t�l�phone.
S�lectionnez l'onglet Types de Serveur, et cochez les cases Activer la compression logicielle et Demander un mot de passe crypt�.
Cliquez sur le bouton "Param�trages TCP/IP".
Renseignez les informations concernant l'adresse IP dynamique/statique de votre client comme pr�cis� par l'administrateur de votre serveur PPTP.
Si vous souhaitez avoir acc�s � votre r�seau local pendant que votre connexion PPTP est active, d�cochez la case "Utiliser la passerelle par d�faut pour le r�seau distant".
Red�marrez encore quelques fois, juste par habitude... :-)
Configurez le routage pour que le pare-feu Linux soit votre passerelle par d�faut, et testez le masquage comme indiqu� plus haut.
Installez et configurez le logiciel de VPN. Pour un logiciel IPsec, suivez les instructions de l'�diteur. Pour PPTP de MS :
Ouvrez Panneau de Configuration/Ajout/Suppression de programme et cliquez sur l'ongletInstallation de Windows.
Cliquez sur l'option Communications et cliquez sur le bouton "D�tails...".
Assurez vous que l'option "R�seau Priv� Virtuel (VPN)" est coch�e. Cliquez alors sur le bouton "OK".
Red�marrez la machine lorsqu'on vous le demande.
Si vous avez besoin d'utiliser du cryptage fort (128 bits), t�l�chargez la mise � jour s�curit� pour le cryptage fort VPN sur le site s�curis� de MS � l'adresse : http://mssecure.www.conxion.com/cgi-bin/ntitar.pl et installez-la, et ensuite red�marrez encore lorsqu'on vous le demande.
Cr�ez et testez une nouvelle entr�e pour votre serveur VPN dans votre carnet d'adresse d'appel distant, comme d�crit plus haut.
Je n'en ai pas vu pour l'instant. Je suppose que la proc�dure est tr�s proche de celle pour W'98. Quelqu'un pourrait-il me dire quelles sont les diff�rences, s'il y en a ? Merci.
Note: cette section peut �tre incompl�te car �a fait un petit moment que je n'ai pas install� PPTP sur un syst�me NT. |
Configurez votre routage pour que le pare-feu Linux soit votre passerelle par d�faut :
Ouvrez Panneau de Configuration/R�seau ou faites un clic droit sur "Voisinage R�seau" et cliquez sur Propri�t�s.
Cliquez sur l'onglet Protocoles et faites un double-clic sur la ligne "Protocole TCP/IP".
Entrez l'adresse IP locale de votre pare-feu Linux dans la zone de dialogue "Passerelle par d�faut".
Cliquez sur le bouton "OK".
Testez le masquage. Par exemple, lancez "telnet le.serveur.de.mail.de.mon.fai smtp" et vous devriez voir appara�tre la banni�re d'accueil du serveur de mails.
Installez et configurez le logiciel VPN. Pour un logiciel IPsec, suivez les instructions de l'�diteur. Pour PPTP de MS :
Ouvrez Panneau de Configuration/R�seau ou faites un clic droit sur "Voisinage R�seau" et cliquez sur Propri�t�s.
Cliquez sur l'onglet Protocoles.
Cliquez sur le bouton "Ajouter", et faites ensuite un double-clic sur la ligne "Point to Point Tunneling Protocol".
Quand on vous demande les num�ros de R�seaux Virtuels Priv�s, entrez les num�ros des serveurs PPTP que vous pouvez potentiellement joindre.
Red�marrez lorsqu'on vous le demande.
Si vous avez besoin d'utiliser du cryptage fort (128 bits), t�l�chargez la mise � jour de PPTP pour cryptage fort sur le site s�curis� de MS � l'adresse http://mssecure.www.conxion.com/cgi-bin/ntitar.pl et installez la, puis red�marrez lorsqu'on vous le demande.
Cr�ez une nouvelle entr�e dans votre carnet d'adresse d'appel distant pour votre serveur PPTP.
S�lectionnez l'adaptateur VPN comme p�riph�rique � utiliser, et entrez l'adresse IP internet du serveur PPTP comme num�ro de t�l�phone.
S�lectionnez l'onglet Types de Serveur et cochez les cases Activer la compression logicielle et Demander un mot de passe crypt�.
Cliquez sur le bouton "Param�tres TCP/IP".
Renseignez les informations concernant l'adresse IP dynamique/statique de votre client comme pr�cis� par l'administrateur de votre serveur PPTP.
Si vous souhaitez avoir acc�s � votre r�seau 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.)
Assurez vous d'avoir r�-appliqu� le dernier Service Pack, pour �tre s�r que les librairies RAS et PPTP sont � jour en ce qui concerne la s�curit� et les performances.
A �crire.
Vous devriez vraiment jeter un oeil sur FreeS/WAN (IPsec pour Linux) � l'adresse http://www.xs4all.nl/~freeswan/ plut�t que de faire du masquage.
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 masqu�es. Sur le pare-feu SecuRemote, faites ce qui suit.
Ex�cutez fwstop
�ditez $FWDIR/conf/objects.C et apr�s la ligne ":props�(", ajoutez ou modifiez les lignes suivantes pour avoir
:userc_NAT (true) :userc_IKE_NAT (true) |
Ex�cutez fwstart
R�installez votre politique de s�curit�.
V�rifiez que les changements ont �t� pris en compte en v�rifiant $FWDIR/conf/objects.C et $FWDIR/database/objects.C
Si vous utilisez les protocoles IPsec (appel�s "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 d�crit plus haut.
Le protocole propri�taire 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 v�rification d'int�grit� est faite sur l'ensemble du paquet IP, comme avec le protocole AH d'IPsec. Changer l'adresse IP casse cette garantie d'int�grit�, donc les tunnels FWZ encapsul�s ne peuvent pas �tre masqu�s.
En mode transport, seule la portion du paquet contenant les donn�es est crypt�e, et les ent�tes IP ne sont pas v�rifi�s pour voir s'ils ont �t� modifi�s. Dans ce mode, le masquage doit fonctionner avec les modifications indiqu�es plus haut.
La configuration pour choisir entre le mode encapsul� ou le mode transport se fait via l'IHM FireWall-1. Dans l'objet r�seau correspondant au pare-feu, sur l'onglet VPN, �ditez les propri�t�s FWZ. Le troisi�me onglet dans les propri�t�s 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 :
Pour tester le masquage VPN :
Activez la connexion � votre FAI depuis votre machine Linux, et v�rifiez qu'elle fonctionne correctement.
V�rifiez que le masquage fonctionne correctement, par exemple en utilisant une machine de votre r�seau local masqu�e pour aller surfer sur un site web, ou pour acc�der � un serveur FTP.
PPTP : v�rifiez que vous avez correctement configur� le masquage du canal de contr�le 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 r�ponse, jetez un coup d'oeil aux r�gles 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.
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 premi�re tentative, f�licitations ! Vous avez r�ussi !
IPsec : essayez d'�tablir une connexion IPsec.
Il y a plusieurs �l�ments qui peuvent emp�cher d'�tablir une session VPN. Nous allons les consid�rer 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.
Information sur la connexion : le "num�ro de t�l�phone" 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�.
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 exp�rience j'ai constat� que ce probl�me ne g�n�re pas de message d'erreur, et que le client cherche � se connecter sans cesse... Vous pouvez r�cup�rer la mise � jour pour le cryptage fort sur le site s�curis� de Microsoft dont l'URL est donn�e dans la section"Configurer un client MS".
Ceci va �galement affecter les clients IPsec, s'ils utilisent les librairies de cryptage fournies par MS plut�t que leurs propres librairies.
Routage : v�rifiez que la route par d�faut sur votre client VPN pointe bien vers la machine de masquage Linux. Lancez la commande route print et cherchez l'entr�e 0.0.0.0.
Si d'autres services masqu�s (comme HTTP, FTP, IRC, etc...) fonctionnent sur votre machine cliente VPN, alors ce n'est pas un probl�me de routage.
Masquage : il y a deux parties dans la session VPN.
Pour IPsec, le service d'authentification et d'�change de cl�s (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 contr�le, 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 donn�es crypt� avec IPsec est transport� au dessus d'ESP, le protocole IP 50. Le canal de donn�es crypt� avec PPTP est transport� au dessus de GRE, le protocole IP 47. (Notez que ce ne sont pas des num�ros de ports TCP ou UDP !) Le noyau Linux 2.0 ne vous permettant de pr�ciser que les protocoles IP TCP, UDP, ICMP et ALL lors de la cr�ation des r�gles de masquage, vous devez masquer le trafic du protocole ALL m�me si vous masquez uniquement des services sp�cifiques. Si vous masquez tout, ne vous en inqui�tez pas.
Afin d'isoler les probl�mes issus des r�gles du pare-feu de ceux provenant du code de masquage du noyau, essayez d'�tablir une connexion VPN avec votre pare-feu compl�tement ouvert, et si �a marche, resserrez alors les r�gles du pare-feu.
Pare-feu compl�tement ouvert avec ipfwadm et un noyau 2.0.x :
ipfwadm -I -p accept ipfwadm -O -p accept ipfwadm -F -a accept -m |
Pare-feu compl�tement 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 compl�tement ouvert plus de temps qu'il n'en faut pour prouver qu'une connexion VPN masqu�e peut �tre �tablie !
�quipements interm�diaires 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 probl�me ne vient probablement pas de l�.
Pour savoir si un �quipement interm�diaire 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.
Le pare-feu distant : le pare-feu du c�t� du serveur doit autoriser une machine ayant la m�me adresse IP que celle attribu�e � 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 probl�me ne vient probablement pas de l�.
Le pare-feu c�t� serveur et ESP : les donn�es crypt�es IPsec sont transport�es au dessus du protocole IP 50. Si le pare-feu derri�re 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 probl�me ne vient probablement pas de l�.
Le pare-feu c�t� serveur et GRE : le canal de donn�es PPTP est transport� comme une session PPP encapsul�e dans GRE (protocole IP 47). Si le pare-feu derri�re 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 probl�me ne vient probablement pas de l�.
Le patch : si votre client IPsec s'authentifie correctement mais ne peut pas �tablir de connexion r�seau, le patch peut ne pas masquer le trafic ESP correctement. Si votre client PPTP �tablit le canal de contr�le (RASMON bipe et le petit t�l�phone clignote) et qu'un trafic GRE est g�n�r� (la lumi�re en haut de RASMON clignote) mais qu'il n'y a pas de trafic GRE en retour (la lumi�re en bas de RASMON ne clignote pas en r�ponse), le patch peut ne pas masquer le trafic GRE correctement.
Regardez dans /var/log/messages pour trouver les entr�es des journaux qui montrent que le trafic VPN a �t� vu. Activez le d�boguage du VPN pour vous aider � d�terminer 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).
Clients multiples : l'ancien patch PPTP ne supporte PAS le masquage de plusieurs clients PPTP cherchant � acc�der au m�me serveur PPTP. Si vous essayez de le faire, vous devriez reconsid�rer votre architecture r�seau 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 simultan�es. Note : n'activez pas le masquage d'identifiant d'appel PPTP si vous masquez un serveur PPTP. Cela emp�cherait le trafic sortant en provenance du serveur d'�tre masqu�.
La plupart des probl�mes peuvent �tre identifi�s 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.
R�seau 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 c�t� 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 c�t� 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 interm�diaires bloquent le trafic ESP ou GRE.
Du c�t� 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, v�rifiez les r�gles 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 c�t� 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, v�rifiez la configuration du serveur VPN, y compris les r�gles de filtrage de paquets sur le serveur VPN.
Du c�t� 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, v�rifiez les r�gles 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 c�t� 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 r�volte encore.
Du c�t� r�seau 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 r�seau 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 d�boguage du VPN et de recompiler votre noyau. Ajoutez ce qui suit au fichier /etc/syslog.conf
# d�boguage *.=debug /var/log/debug |
Merci � Charles Curley <ccurley@trib.com> pour ce qui suit :
Si vous utilisez PPTP (Point to Point Tunneling Protocol) pour acc�der � un environnement R�seau Microsoft (SMB) et que vous avez votre propre environnement R�seau Microsoft sur votre r�seau 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. |
Je pense que ceci s'applique ind�pendamment de l'utilisation du VPN, car les services de nommage sont ind�pendants du transport. Si votre (ou vos) client peut voir les serveurs WINS sur le r�seau distant, vous aurez le probl�me, avec ou sans PPTP.
Si vous avez des probl�mes 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/ReleaseNotes.asp
Les m�mes consid�rations s'appliquent probablement �galement � W'98.
Merci � David Griswold <dgriswol@ix.netcom.com>
Lorsque vous utilisez un VPN pour acc�der � un r�seau MS, souvenez-vous qu'il vous faut fournir deux jetons d'authentification diff�rents - un pour se connecter au serveur VPN (le mot de passe VPN) et l'autre pour acc�der aux ressources du r�seau distant une fois que la connexion est �tablie (le mot de passe r�seau).
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 r�seau 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 r�seau distant. Pour cela vous devez fournir une autre paire nom d'utilisateur/mot de passe - votre mot de passe r�seau.
Il y a deux m�thodes pour fournir un mot de passe r�seau. Votre mot de passe r�seau peut provenir de la m�me paire nom d'utilisateur/mot de passe que celle que vous utilisez lorsque vous vous connectez sur le r�seau local en allumant votre ordinateur. S'il est diff�rent, vous pouvez configurer votre client VPN pour vous demander votre mot de passe pour le r�seau distant une fois que la connexion VPN est �tablie.
Si vous arrivez � vous connecter au serveur VPN sans pouvoir acc�der aux ressources disponibles sur le r�seau distant, alors vous n'avez pas fourni une paire nom d'utilisateur/mot de passe valide sur le r�seau distant. V�rifiez que le nom d'utilisateur et le mot de passe pour votre r�seau local fonctionnent aussi sur le r�seau distant, ou configurez votre client VPN pour vous demander un nom d'utilisateur et un mot de passe � utiliser sur le r�seau distant, et pour vous "enregistrer" sur le r�seau distant une fois que la connexion VPN est �tablie.
Si vous avez des probl�mes avec votre tunnel IPsec qui meurt r�guli�rement, plus particuli�rement si une v�rification des enregistrements sur le pare-feu montrent que des paquets ISAKMP avec des valeurs "zero cookie" passent, voici ce qui arrive.
Les versions ant�rieures du patch pour le masquage IPsec ne changeaient pas le d�lai de fin d'attente (timeout) pour les entr�es de la table de masquage des paquets ISAKMP UDP. Les entr�es de la table de masquage pour le trafic ISAKMP UDP vont arriver en fin d'attente assez rapidement (comparativement au canal de donn�es) et vont �tre supprim�es ; si l'h�te IPsec distant d�cide alors d'initialiser un renouvellement des cl�s avant que la machine IPsec locale ne le fasse, le trafic ISAKMP entrant pour le renouvellement des cl�s ne pourra alors pas �tre rout� vers la machine masqu�e. Le trafic de renouvellement des cl�s sera rejet�, l'h�te IPsec distant pensera que le lien est tomb�, et que la connexion va �tre termin�e.
Le patch 2.0.x a �t� modifi� depuis sa version initiale pour augmenter le d�lai de fin d'attente des entr�es de la table de masquage concernant les paquets ISAKMP UDP. R�cup�rez la version actuelle du patch, disponible sur les sites indiqu�s dans la section Ressources, r�-appliquez le patch et recompilez votre noyau.
V�rifiez �galement que votre param�tre Dur�e de vie de la table de masquage IPsec (IPsec Masq Table Lifetime) est configur� pour �tre �gal, ou l�g�rement sup�rieur, � votre intervalle de renouvellement des cl�s.
Vous souvenez-vous d'avoir mis les commandes modprobe ip_masq_pptp.o ou modprobe ip_masq_ipsec.o dans votre script de d�marrage /etc/rc.d/rc.local au cas o� vous avez compil� le support de masquage VPN en modules ?
La RFC de PPTP pr�cise qu'il ne peut y avoir qu'un seul canal de contr�le entre deux syst�mes. 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 d�tails.
Le trafic utilisant le protocole AH ne peut pas �tre masqu�. Le protocole AH inclut un contr�leur d'int�grit� cryptographique qui couvre les adresses IP, et que la passerelle de masquage ne peut pas r�g�n�rer correctement. Donc tout le trafic AH masqu� va �tre rejet� car il aura des contr�leurs d'int�grit� 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 apr�s l'ent�te IP. Or, par exemple, les contr�leurs d'int�grit� de TCP et UDP incluent les adresses IP source et destination, ils se trouvent dans la partie crypt�e, et ne peuvent donc pas �tre recalcul�s apr�s que la passerelle de masquage ait modifi� les adresses IP. L'ent�te TCP/UDP ne va donc pas passer les contr�les d'int�grit� 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 s�r et fiable � condition qu'un seul h�te IPsec soit masqu� � un instant donn�, ou que chaque h�te masqu� communique avec un serveur distant diff�rent. Lorsque plusieurs machines masqu�es communiquent avec la m�me machine distante, quelques faiblesses apparaissent :
Les communications du mode transport sont sujettes � collisions.
Si deux machines masqu�es ou plus utilisent le mode transport pour communiquer avec le m�me h�te distant, et si la politique de s�curit� sur l'h�te distant permet plusieurs sessions de mode transport avec la m�me machine, il est possible que les sessions aient des collisions. Ceci arrive parce que l'adresse IP de la passerelle de masquage va �tre utilis�e pour identifier les sessions, et que les autres informations d'identification ne pourront pas �tre masqu�es puisqu'elles sont dans la portion crypt�e du paquet.
Si la politique de s�curit� de l'h�te distant n'autorise pas plusieurs sessions simultan�es en mode transport avec la m�me machine, la situation est pire : la session en mode transport n�goci�e en dernier va �craser tout le trafic de la session pr�c�dente, entra�nant sa "mort". Alors que les sessions �tablies via l'ancienne session IPsec en mode transport vont �tre rapidement r�initialis�es si l'h�te distant n'attend pas de trafic, au moins un paquet de donn�es va �tre envoy� � la mauvaise machine. Ce paquet va probablement �tre ignor� par le destinataire, mais il va tout de m�me �tre envoy�.
Donc une collision du mode transport peut avoir comme cons�quence 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 recommand�e s'il y a une possibilit� que d'autres sessions IPsec en mode transport soient initialis�es via la m�me passerelle de masquage vers le m�me h�te IPsec distant.
IPsec en mode tunnel avec une adresse de r�seau externe (l'h�te IPsec masqu� se voit attribuer une adresse IP du r�seau de l'h�te distant) n'est pas sujet � ces probl�mes, car l'adresse IP fournie par le r�seau distant sera utilis�e pour identifier les sessions plut�t que l'adresse IP de la machine masquante.
Les communications ISAKMP sont sujettes � des collisions de cookies.
Si deux ou plusieurs machines masqu�es �tablissant une session avec la m�me machine distante utilisent le m�me 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. tr�s petite) pour que cette collision ait lieu lorsque la connexion ISAKMP initiale est �tablie.
Pour corriger cela, il faut inclure le cookie de r�ponse dans la cl� utilis�e pour router le trafic ISAKMP entrant. Cette modification est incluse dans le code de masquage IPsec des noyaux 2.2.x, et la courte p�riode entre le moment o� l'h�te masqu� initialise l'�change ISAKMP et la r�ponse de l'h�te distant est prot�g�e par le bloquage de tout nouveau trafic ISAKMP qui pourrait entrer en collision avec le trafic actuel. Cette modification va bient�t �tre port�e sur le code des 2.0.x.
Il peut y avoir une collision entre les valeurs SPI du trafic entrant.
Deux ou plusieurs h�tes IPsec masqu�s communiquant avec la m�me machine IPsec distante peuvent n�gocier pour utiliser la m�me valeur SPI pour le trafic entrant. Si cela arrive, la passerelle de masquage va router tout le trafic entrant vers la premi�re 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 pr�senter � chaque renouvellement de cl�s.
Les valeurs SPI sont rattach�es � diff�rents SA ayant diff�rentes cl�s de cryptage, le premier h�te ne sera donc pas capable de d�crire les donn�es destin�es aux autres machines, donc il n'y aura aucune fuite de donn�es. Il n'y a aucun moyen pour la passerelle de masquage de d�tecter ou d'emp�cher cette collision. La seule fa�on d'emp�cher cette collision est que l'h�te IPsec distant v�rifie la valeur SPI propos�e par la machine masqu�e pour voir si cette valeur SPI est d�j� utilis�e par un autre SA depuis la m�me adresse IP. Il est peu probable que ceci soit impl�ment� un jour, car cela imposerait une charge suppl�mentaire � une op�ration d�j� co�teuse (le renouvellement des cl�s) pour un b�n�fice concernant un nombre r�duit de personnes et un type d'�v�nement assez rare.
Les valeurs SPI entrantes et sortantes peuvent �tre dissoci�es.
Ceci sera vu en d�tail dans la section suivante.
Pour �viter ces probl�mes, le code des noyaux 2.2.x emp�che par d�faut l'�tablissement de plusieurs connexions vers la m�me machine distante. Si vous estimez que la faiblesse li�e � plusieurs connexions vers la m�me machine distante est acceptable, vous pouvez activer les "sessions parall�les".
Il peut �tre g�nant de bloquer pour des raisons de s�curit� les sessions parall�les : 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 entr�es de la table de masquage vont �tre conserv�es pendant leur dur�e de vie standard, m�me si la session se termine juste apr�s qu'elle ait �t� �tablie. Si l'on emp�che les sessions parall�les, cela signifie que le serveur n'acceptera pas d'autre client tant que l'entr�e de la table de masquage la plus r�cente sera pr�sente. Cela peut prendre plusieurs heures.
La partie de l'�change de cl�s ISAKMP o� les valeurs SPI d'ESP sont communiqu�es est crypt�e, donc les valeurs SPI d'ESP doivent �tre d�termin�es 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 m�thode 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 s�rialisant le trafic ESP par machine distante. Concr�tement :
Si un paquet ESP sortant avec une valeur SPI qui n'a pas encore �t� vue (ou dont l'entr�e dans la table de masquage a expir�) est re�u (il sera appel� par la suite un "paquet initial"), une entr�e dans la table de masquage est cr��e pour cette combinaison AdresseSource+SPI+AdresseDest. Elle est marqu�e comme "en attente", ce qui signifie qu'aucun trafic correspondant � cette entr�e n'a �t� pour l'instant re�u. Le marquage se fait en mettant la valeur "SPI entrant" dans l'entr�e de la table de masquage � z�ro, qui est une valeur r�serv�e pour cela. Ceci arrivera lors de l'initialisation d'une nouvelle connexion ESP et � intervalles r�guliers lors du renouvellement de cl�s d'une connexion ESP existante.
Tant que l'entr�e de la table de masquage est en attente, aucun autre paquet ESP initial � destination du m�me h�te distant n'est trait�. Les paquets sont imm�diatement rejet�s, et une entr�e du journal syst�me est ajout�e, pr�cisant que le trafic est temporairement bloqu�. Ceci s'applique �galement au trafic initial en provenance de la m�me machine masqu�e � destination du m�me h�te distant, si les valeurs SPI sont diff�rentes. Le trafic vers d'autres h�tes distants, et le trafic o� les deux valeurs SPI sont connues (trafic d�j� "�tabli") n'est pas affect�.
Ceci peut facilement mener � un d�ni de service sur la machine distante, c'est pour cela que la dur�e de vie de cette entr�e en attente de la table de masquage ESP est faible, et que seul un nombre limit� de tentatives pour le m�me trafic est autoris�. Ceci permet de faire un acc�s via round-robin � la machine distante si plusieurs machines masqu�es tentent d'initialiser simultan�ment la connexion et que les r�ponses n'arrivent pas tr�s vite, par exemple � cause d'une congestion r�seau, ou d'une machine distante lente. Le d�compte des tentatives commence d�s qu'il y a une collision, donc l'h�te IPsec masqu� peut attendre une r�ponse aussi longtemps qu'il le faut jusqu'� ce qu'il soit n�cessaire de faire une mise en s�rie des connexions.
Quand un paquet ESP est re�u en provenance de l'h�te distant en attente, et que la valeur SPI n'appara�t dans aucune entr�e de la table de masquage, il est suppos� que le paquet est la r�ponse au paquet en attente initial. La valeur SPI est stock�e dans l'entr�e courante de la table de masquage associant les valeurs SPI, et le trafic ESP entrant est alors rout� vers la machine masqu�e. A ce point un autre paquet initial destin� au serveur distant peut �tre trait�.
Tout trafic ESP avec une valeur SPI de z�ro est rejet� comme �tant invalide, conform�ment au RFC.
Il y a plusieurs possibilit�s pour que l'association de trafic ne se fasse pas proprement :
La latence du r�seau ou la lenteur d'une machine distante peuvent retarder suffisamment la r�ponse au paquet initial pour que l'entr�e de la table de masquage ait expir�, et qu'une autre machine masqu�e ait eu sa chance d'initialiser un trafic. Ceci peut faire que la r�ponse sera associ�e au mauvais SPI sortant, et donc le trafic entrant sera rout� vers la mauvaise machine masqu�e. Si cela arrive, la machine masqu�e 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 cl�s, et r�essayer. On peut y rem�dier en �ditant /usr/src/linux/net/ipv4/ip_masq.c (ip_masq_ipsec.c dans le 2.2.x) et en augmentant la dur�e de vie d'INIT ou le nombre de tentatives INIT autoris�es, avec pour co�t l'agrandissement de la fen�tre de bloquage (et de d�ni de service).
Les sessions inactives ou semi-inactives (avec un trafic entrant peu fr�quent et aucun trafic sortant) sur une longue p�riode peuvent le rester suffisamment longtemps pour que l'entr�e de la table de masquage expire. Si la machine distante envoie du trafic d'une session ayant d�j� expir� au niveau de la table de masquage pendant qu'une initialisation est en cours vers la m�me machine, le trafic peut �tre incorrectement rout�, pour la m�me raison que plus haut. On peut y rem�dier en s'assurant que le param�tre de configuration du noyau IPsec Masq Table Lifetime est l�g�rement plus grand que l'intervalle de renouvellement des cl�s, qui est la dur�e la plus longue que les paires SPI peuvent utiliser. Le probl�me ici est que vous ne pouvez pas conna�tre tous les intervalles de renouvellement des cl�s si vous masquez plusieurs serveurs distants, ou que certains peuvent avoir leurs intervalles de renouvellement des cl�s positionn�s � des valeurs d�raisonnablement �lev�es, comme plusieurs heures.
S'il y a un d�lai entre un renouvellement de cl�s et la transmission du trafic ESP sortant utilisant le nouveau SPI, et si durant ce d�lai un trafic ESP entrant utilisant ce nouveau SPI est re�u, il n'y a pas d'entr�e de la table de masquage d�crivant comment router le trafic entrant. Si une autre machine masqu�e a une initialisation en attente avec le m�me h�te distant, le trafic va �tre dissoci�. Notez que la s�rialisation du trafic ESP initial n'affecte pas le trafic de renouvellement des cl�s ISAKMP.
La meilleure solution est d'avoir un moyen de pr�-charger la table de masquage avec les bonnes paires SPI-sortie/SPI-entr�e, ou une autre forme d'association machine_distante + SPI_entr�e avec la machine_masqu�e. Cela ne peut pas �tre fait en suivant l'�change de cl�s ISAKMP, car il est crypt�. Il peut �tre possible d'utiliser RSIP (�galement connu en tant que Translation d'Adresse R�seau pour un h�te (NdT : Host-NAT)) pour communiquer avec l'h�te IPsec masqu� et demander une notification sur les informations SPI une fois que la n�gociation a eu lieu. Ce point est � �tudier. Si quelque chose est fait pour l'impl�menter, ce ne sera pas fait avant les s�ries 2.3.x, car RSIP est un protocole NAT client/serveur assez complexe.
Quand un paquet ESP entrant avec un nouveau SPI est re�u, le pare-feu de masquage tente de deviner � quel(s) h�te(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) masqu�e(s) qui a (ont) renouvel� en dernier ses (leurs) cl�s avec cet h�te distant. Les machines masqu�es "incorrectement" vont rejeter le trafic comme n'�tant pas correctement crypt�, et la machine "correctement" masqu�e va recevoir des donn�es. Lorsque la machine "correctement" masqu�e r�pond, le processus normal de s�rialisation de l'initialisation ESP a lieu.