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.