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.