Internet Explorer 7 permet de définir les proxies en fonction de chaque connexion. Il est donc impératif si vous voulez travailler avec IE7 sous une connexion VPN de définir le proxy.pac de l’UFC dans les propriétés de la connexion VPN.
La documentation sur le VPN (document PDF) indique la marche à suivre.
Problème Windows : IE7 et proxy
avril 10th, 2008Problème linux : Fedora Core 7, 8, 9 et PPP/L2TP
avril 10th, 2008La version de base il faut recompiler les sources de PPP (cf CRI XXXXXXXXXXXXXXXXX) car la version 2.4.2 (FC 7, 8) et la version 2.4.4-rel6 (FC 9) ne possède pas l’option replacedefaultroute nécessaire dans la configuration L2TP/PPP
VPN : encapsulation des informations
avril 10th, 2008sur le shéma ci-dessous, nous voyons comment IPSEC encapsule les données utilisateurs. Dans le mode transport et le mode tunnel.
sur ce nouveau shéma, nous voyons les différentes étapes d’encapsulation lorsqu’on utilise L2TP en mode tunnel
enfin sur ce troisième shéma, nous décrivons l’encapsulation d’une connexion l2tp à travers du nat
Client Linux et Serveur : options dans sysctl.conf
avril 10th, 2008Pour le bon fonctionnement du proxy-arp du serveur VPN,
le fichier /etc/sysctl.conf du serveur VPN doit être configuré comme suit en ajoutant ces options :
net.ipv4.ip_forward=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.conf.all.log_martians=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
Sans ces options, le proxy-arp du serveur VPN ne fonctionne pas correctement et empêche le client d’accéder à quoi que ce soit hors le serveur VPN lui même.
Gantry : bug dans les modules MP10.pm et MP20.pm
avril 10th, 2008Un patch a été envoyé (29/02/2008) pour corriger des erreurs sur le mod_perl (1 et 2) dans Gantry.
Certificat client : usage
avril 10th, 2008Avertissement aux utilisateurs : lorsque le CRI vous délivre, par l’intermédiaire de votre correspondant réseau, un certificat pour utiliser le VPN, ce certificat est à votre nom ; il est personnel, non cessible et vous avez la pleine responsabilité de son utilisation.
Durée de validité du certificat : la durée d’un certificat est normalement de 3 ans sauf spécification contraire.
Lorsque votre certificat arrive à échéance vous serez averti (3 mois, 1 mois, 15 jours avant) ainsi que votre correpondant.
Compatibilité des certificats avec les différents systèmes d’exploitation : un certificat délivré par le CRI à un usager est configuré pour fonctionner avec un certain type de machine.
Les distinctions se font vis à vis de l’OS est plus particulièrement pour MacOS (tiger et suivants), Windows (XP et Vista), Linux (debian/ubuntu, centos/fedora, mandriva).
L’installation d’un certificat prévue pour un MacOS ne fonctionnera pas sur un Windows et vice-versa.
Format du certificat :
Pour windows, le certificat comporte un seul fichier qui porte l’extension .p12.
Pour Linux, le certificat est composé des trois fichiers à copier dans différents répertoires.
Pour MacOS, un seul fichier avec l’extension .p12.
Certificat serveur et MacOS
avril 10th, 2008Le certificat du serveur doit absolument contenir une information subjectAltName. Dans le fichier openssl.cnf il faut donc (si on utilise tinyCA) configurer la section suivante ainsi :
[ server_cert ]
...
#subjectAltName = email:copy
subjectAltName = IP:"adresse du serveur VPN"
Sans cette option, les clients MacOS ne peuvent pas établir la connexion IPSEC.
VPN : qui s’occupe de quoi ?
avril 10th, 2008Le projet est techniquement réalisé par Jean-Michel Caricand, Ghislaine Foltête et Marc Hamelin.
Par techniquement on entend la configuration/debug/patch sur les applications openswan, (x)l2tpt, freeradius, gantry, apache, postgresql, openCA/tinyCA. C’est l’interaction entre ces différentes briques de base qui définit le projet VPN.
Le projet est opérationnellement maintenu sur différents niveaux :
RSSI : Bertrand Astric, Patrice Koch
Patch Centos : Ghislain Pruniaux
Patch sur les outils : Jean-Michel Caricand
Maintenance VPN (tous les outils) : Jean-Michel Caricand, Ghislaine Foltête et Marc Hamelin
Suivi des certificats : Ghislaine Foltête et Marc Hamelin sous couvert des RSSI
Realm : correspondants réseaux
Droits utilisateurs : correpondants réseaux
Documentation : Jean-Michel Caricand, Ghislaine Foltête et Marc Hamelin
Communication : Ghislaine Foltête et Marc Hamelin
Connexion sur un LDAP extérieur
avril 10th, 2008Pour authentifier des utilisateurs, nous pouvons à partir du RADIUS principal passer le relais de l’authentification sur un LDAP de laboratoire et/ou d’UFR.
Pour que cela fonctionne, il faut fournir au CRI un compte de bind du style :
identity = "cn=<nom-cri>,ou=foo,dc=bar,dc=fr"
password = "mdp"
basedn = "ou=people,ou=foo1,dc=bar,dc=fr"
VPN et MTU
avril 10th, 2008Il est inutile de configurer la MTU dans les fichiers de configuration du client car celui-ci est négocié avec le serveur.
La RFC 2401 discute de la PMTU et le document CISCO nous précise :
Tunnel Combination Specific MTU Needed Recommended MTU
GRE + IPsec (Transport mode) 1440 bytes 1400 bytes
GRE + IPsec (Tunnel mode) 1420 bytes 1400 bytes
Nous avons donc fixer sur l’interface du serveur VPN une MTU de 1400 octets.