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
Gantry : problème de mise en ligne sous Apache
avril 10th, 2008Problème linux : log de connexion
avril 9th, 2008Les 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
Problème linux : je perds ma route par défaut en déconnectant le VPN
avril 9th, 2008Lorsque 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.
Configuration Linux avec ou sans NAT
avril 9th, 2008Le 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
Installer xl2tpd sous debian etch
avril 9th, 2008mettre 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
Authentification PPP
avril 9th, 2008L’authentification entre le serveur PPP et le client PPP via (X)L2TP n’est pas nécessaire. Dans le fichier /etc/l2tpd/l2tpd.conf ou /etc/xl2tpd/xl2tpd.conf l’option doit être configurée comme suit :
refuse authentication = yes
ou par :
require authentication = no
Le serveur VPN est configuré ainsi.
Utilité des options rightprotoport/leftprotoport
avril 9th, 2008Une cohérence doit exister entre la configuration du serveur VPN et celle du client : si le fichier de configuration d’IPsec du serveur VPN comporte la ligne protoport, le fichier de configuration du client doit également la comporter.
Dans le fichier ipsec.conf, au niveau du paramètrage des connexions (conn <blabla>), nous devons trouver les options :
rightprotoport=17/1701
leftprotoport=17/1701
sinon le lancement de la connexion :
ipsec auto --up blabla
ne fonctionnera pas.
A l’inverse, si cette option protoport n’est pas présente dans le fichier de configuration du serveur, elle devient inutile dans le fichier de configuration du client VPN.