$Revision: 2.19 $ $Date: 2000-10-22 12:07:43-07
$
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.
En d'autres mots, prenez des précautions.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.