Certificat client : usage

avril 10th, 2008

Avertissement 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.

Tags: , , ,
Posted in Informations utilisateurs | No Comments »

Certificat serveur et MacOS

avril 10th, 2008

Le 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.

Tags: , , ,
Posted in informations techniques | No Comments »

VPN : qui s’occupe de quoi ?

avril 10th, 2008

Le 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

Tags: , , , ,
Posted in informations techniques | No Comments »

Connexion sur un LDAP extérieur

avril 10th, 2008

Pour 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"

Tags: , ,
Posted in informations techniques | No Comments »

VPN et MTU

avril 10th, 2008

Il 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.

Tags:
Posted in Informations utilisateurs | No Comments »

Gantry : problème de mise en ligne sous Apache

avril 10th, 2008

Lors de la mise en ligne de l’application de gestion VPN générée par Gantry, nous avons constaté le manque d’un module perl pour apache : undefined symbol: apreq_handle_apache2
Pour corriger cela Centos ne possède pas de paquet pré-conditionné, il faut donc le repackager.
Ghislain à reconditionné le paquet libapr2
fichier cri.repo
[CRI]
name=CRI RPM Repository for Red Hat Enterprise Linux
baseurl=http://yum.univ-fcomte.fr/el5/
enabled=1
gpgcheck=0

Tags: , , , ,
Posted in informations techniques | No Comments »

Problème linux : log de connexion

avril 9th, 2008

Les logs liés à une connexion VPN se trouvent dans /var/log/auth.log, /var/log/syslog et /var/log/messages.
Au lancement de la connexion IPsec (on voit ici que la connexion est à travers du nat) vous devez avoir des logs similaires à ceux-ci dans /var/log/auth.log (ou /var/log/messages):
#49: initiating Main Mode
#49: ignoring unknown Vendor ID payload [4f456c4c4f5d5264574e5244]
#49: received Vendor ID payload [Dead Peer Detection]
#49: received Vendor ID payload [RFC 3947] method set to=110
#49: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
#49: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
#49: STATE_MAIN_I2: sent MI2, expecting MR2
#49: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
#49: I am sending my cert
#49: I am sending a certificate request
#49: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
#49: STATE_MAIN_I3: sent MI3, expecting MR3
#49: Main mode peer ID is ID_IPV4_ADDR: '194.57.91.251'
#49: no crl from issuer "C=FR, ST=Franche-Comte, L=Besancon, O=UFC, OU=CRI, CN=CA-vpn, E=vpn-master@univ-fcomte.fr" found (strict=no)
#49: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
#49: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
#50: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+UP {using isakmp#49}
#50: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
#50: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x2e19c272 <0x37ba5dd5 xfrm=AES_0-HMAC_SHA1 NATD=194.57.91.251:4500 DPD=none}

Si vous n’avez pas de log de connexion IPsec, il faut vérifier votre fichier ipsec.conf, car il doit contenir des erreurs de syntaxe.

lors de la connexion (x)l2tp vous devriez avoir dans /var/log/syslog :
: pppd 2.4.4 started by root, uid 0
: Using interface ppp0
: Connect: ppp0 <--> /dev/pts/2
: Remote message: user2@lifc-edu connecte a lifc-edu^J
: PAP authentication succeeded
: replacing old default route to eth0 [192.168.1.254]
: local IP address 172.20.128.37
: remote IP address 192.168.255.201
: primary DNS address 194.57.91.200
: secondary DNS address 194.57.91.200

votre nouvelle adresse IP est précisée ici : : local IP address 172.20.128.37

Si vous n’avez pas de log (x)l2tp, vous pouvez lancer l2tpd en mode debug avec la commande suivante, en utilisateur root :
/etc/init.d/xl2tpd stop ou /etc/init.d/l2tpd stop
xl2tpd -D -c /etc/xl2tpd/xl2tpd.conf ou l2tpd -D -c /etc/l2tpd/l2tpd.conf
Ensuite effetcuez dans une autre fenêtre root le montage du lien PPP
echo "c user2" > /var/run/xl2tpd/l2tp-control ou echo "c user2" > /var/run/l2tp-control
Le résultat des logs dans la première fenêtre doit vous apporter de l’aide pour corriger votre problème.
Si cela persiste n’hésitez pas à contacter votre correspondant réseau ou vpn-master@univ-fcomte.fr

Tags: , ,
Posted in problèmes utilisateurs | No Comments »

Problème linux : je perds ma route par défaut en déconnectant le VPN

avril 9th, 2008

Lorsque vous effectuez la connexion VPN, les routes sur votre ordinateur ressemblent à cela :
cri-29:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.255.201 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
194.57.91.251 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

Lors de la déconnexion, il ne vous reste que :
cri-29:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.255.201 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
194.57.91.251 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

La route par défaut a disparu et vous ne pouvez plus aller sur Internet.
Pour résoudre ce problème, vous pouvez taper manuellement (sous l’utilisateur root) :
route add default gw 192.168.1.254
ou utiliser les scripts suivants :
/etc/ppp/ip-pre-up
#!/bin/sh
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
export PATH
PPP_IFACE="$1"
PPP_TTY="$2"
PPP_SPEED="$3"
PPP_LOCAL="$4"
PPP_REMOTE="$5"
PPP_IPPARAM="$6"
export PPP_IFACE PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE PPP_IPPARAM
PPP_TTYNAME=`/usr/bin/basename "$2"`
export PPP_TTYNAME
run-parts /etc/ppp/ip-pre-up.d \
--arg="$1" --arg="$2" --arg="$3" --arg="$4" --arg="$5" --arg="$6"
EOF

etc/ppp/ip-pre-up.d/save-defaultroute
#! /bin/bash
GW=$(route -n | grep '^0.0.0.0' | tr -s ' ' ' ' | cut -d' ' -f2)
[ -n "$GW" ] && echo $GW > /tmp/$PPP_IFACE.defaultroute
exit 0;

et etc/ppp/ip-down.d/restore-defaultroute
#! /bin/sh -e
[ -f /tmp/$PPP_IFACE.defaultroute ] || exit 0
GW=$(cat /tmp/$PPP_IFACE.defaultroute)
route add default gw $GW
exit 0;

Si vous utilisez xl2tpd, un autre problème se pose pour vous. xl2tpd ne fait pas appel aux scripts de déconnexion de la session PPP. Il faut donc patcher xl2tpd en utilisant le repository du LIFC par exemple.

Tags: , ,
Posted in problèmes utilisateurs | No Comments »

Configuration Linux avec ou sans NAT

avril 9th, 2008

Le fichier /etc/ipsec.conf permet de déterminer si on utilise le NAT ou non.

Que l’on soit naté (chez soit avec sa ligne ADSL par exemple) ou non, vous pouvez utiliser dans la rubrique config setup
nat_traversal=yes

Très important dans la rubrique conn ufc-vpn
leftnexthop=192.168.1.254

Attention à mettre l’adresse de son routeur à la place du 192.168.1.254

Le client ipsec.conf configuré ici avec le serveur VPN 194.57.91.251
version 2
config setup
uniqueids=yes
nhelpers=0
nat_traversal=yes

conn vpn-ufc
authby=rsasig
keyingtries=1
rightprotoport=17/1701
leftprotoport=17/1701
keyexchange=ike
pfs=no
auto=add
left=%defaultroute
leftnexthop=192.168.1.254
leftcert="/etc/ipsec.d/certs/vpn-cri-29-cert.ufc.pem"
leftrsasigkey=%cert
leftsendcert=always
right=194.57.91.251
rightrsasigkey=%cert
rightca=%same

le fichier /etc/ipsec.secrets :
: RSA /etc/ipsec.d/private/vpn-cri-29-cert.key "testvpncri29"

le fichier xl2tpd.conf ou l2tpd.conf :
[global]
port = 1701

[lac user2]
lns = 194.57.91.251
redial = yes
redial timeout = 5
max redials = 3
length bit = yes
require authentication = no
refuse chap = yes
require pap = yes
name = user2
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client

le fichier /etc/ppp/options.l2tpd.client :

defaultroute
replacedefaultroute
debug
lock
user user2@lifc-edu
noipdefault
usepeerdns
noauth
lcp-echo-interval 20
lcp-echo-failure 10
noaccomp

le fichier /etc/ppp/pap-secrets :
user2@lifc-edu * ''user2''
ou

Cela peut être évité en utilisant l’astuce décrite dans cet article

Le montage du lien s’effectue en deux temps. IPSEC puis XL2TP
ipsec auto --up ufc-vpn
echo ''c user2'' > /var/run/xl2tpd/l2tp-control

L’arrêt du lien s’effectue par :
echo ''d user2'' > /var/run/xl2tpd/l2tp-control
ipsec auto --down ufc-vpn

Si vous utilisez L2TP les fichiers de configuration auront les mêmes contenu, mais le lancement s’effectue par :
ipsec auto --up ufc-vpn
echo ''c user2'' > /var/run/l2tp-control

L’arrêt du lien s’effectue par :
echo ''d user2'' > /var/run/l2tp-control
ipsec auto --down ufc-vpn

Tags: , , ,
Posted in Informations utilisateurs | No Comments »

Installer xl2tpd sous debian etch

avril 9th, 2008

mettre le repository du LIFC dans le fichier /etc/apt/sources.list :
# deb LIFC
deb http://lifc.univ-fcomte.fr/debian/ etch-lifc main

Ensuite effectuer :
apt-get update
apt-remove xl2tpd
apt-get install xl2tpd

Tags: , , ,
Posted in Informations utilisateurs | No Comments »

« Older Entries
Newer Entries »