Dans certain cas, il y a perte de connexion VPN sans erreur visible dans les fichiers de logs.
Deux pistes :
– coupure temporaire du lien réseau (qui peut arriver avec le WIFI, ou plus rarement une panne de l’opérateur) ;
– surcharge importante du lien par un ordinateur tièrce (si votre portable est en VPN que votre machine de bureau sans VPN effectue un gros transfert de fichier en utilisant toute la bande passante).
Pour les heureux possesseur de Windows Seven (Beta ?!), la procédure à suivre pour l’installation du VPN est rigoureusement la même que celle de VISTA.
Lorsqu’un portable sous VISTA passe en veille ou que celui-ci est fermé, si la connexion VPN n’a pas été close avant, certains descripteurs utilisé par L2TP sur la machines VISTA reste ouvert. Cela a pour conséquence qu’il devient impossible d’ouvrir une nouvelle connexion L2TP vers le serveur VPN. VISTA indique alors l’erreur 789.
il semble que sous VISTA, il faille écrire l’adresse IP du serveur VPN (194.57.91.250) et non son nom (vpn1.univ-fcomte.fr) pour que la connexion s’établisse correctement.
Il est possible de corriger cela en faisant la manipulation suivante :
Dans la fenêtre de connexion, bouton « propriété », onglet « gestion du réseau », « paramètre IPSEC », il faut décocher « vérifier les attributs Nom et Utilisation des du certificat du serveur ».
Le premier d’une série de quatre articles consacrés à la mise en oeuvre de notre solution VPN pour l’UFC a été publié dans le numéro 116 de GNU Linux Magazine France (GLMF).
Dans la boite à outils que propose Linux nous pouvons trouver :
iwconfig
dhclient
iwconfig permet de voir la configuration d’une interface WIFI …
iwconfig eth1
eth1 IEEE 802.11b ESSID:"ufc-personnels" Nickname:"ipw2100"
...
… ou de la reconfigurer :
iwconfig eth1 essid ufc-vpn
iwconfig eth1
eth1 IEEE 802.11b ESSID:"ufc-vpn" Nickname:"ipw2100"
...
et l’outils dhclient vous permet de récupérer via DHCP une adresse IP :
dhclient
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth1/00:04:23:96:c2:09
Sending on LPF/eth1/00:04:23:96:c2:09
Listening on LPF/eth0/00:06:1b:d8:c4:cb
Sending on LPF/eth0/00:06:1b:d8:c4:cb
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 172.21.7.254
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPACK from 172.21.7.254
bound to 172.21.7.231 -- renewal in 5416 seconds.
Un certificat non reconnu provoque est visible dans les logs du serveur /var/log/auth.log
Après la séquence de négociation correcte :
Mar 18 13:24:54 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: responding to Main Mode from unknown peer 172.21.7.202
Mar 18 13:24:54 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Mar 18 13:24:54 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: STATE_MAIN_R1: sent MR1, expecting MI2
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: STATE_MAIN_R2: sent MR2, expecting MI3
Et l’erreur proprement dite :
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: Main mode peer ID is ID_DER_ASN1_DN: 'C=FR, ST=Franche-Comte, O=UFC, OU=CRI, CN=choucroute, E=vpn-master@univ-fcomte.fr'
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: no crl from issuer "C=FR, ST=Franche-Comte, L=Besancon, O=UFC, OU=CRI, CN=CAvpn, E=vpn-master@univ-fcomte.fr" found (strict=no)
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: no suitable connection for peer 'C=FR, ST=Franche-Comte, O=UFC, OU=CRI, CN=choucroute, E=vpn-master@univ-fcomte.fr'
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: sending encrypted notification INVALID_ID_INFORMATION to 172.21.7.202:500
L’interprétation de l’erreur est assez simple puisque nous voyons que le certificat de choucroute contient OU=CRI ce qui n’est pas une valeur attendu (LINUX, XP, MACOS)
Si vous avez le message suivant dans vos log /var/log/auth.log :
Feb 27 11:42:14 cri-29 pluto[6156]: "ufc-vpn" #1: issuer cacert not found
... pluto[6156]: "ufc-vpn" #1: X.509 certificate rejected
... pluto[6156]: "ufc-vpn" #1: no RSA public key known for '194.57.91.250'
C’est que le fichier /etc/ipsec.d/cacerts/cacert.pem n’est pas le bon ou qu’il n’est pas dans ce répertoire.
Pour vérifier le cacert :
openssl x509 -in /etc/ipsec.d/cacerts/cacert.pem -noout -subject
qui vous donne :
subject= /C=FR/ST=Franche-Comte/L=Besancon/O=UFC/OU=CRI/CN=CA-vpn/
emailAddress=vpn-master@univ-fcomte.fr
Les versions d’opensuse 11 ne prennent pas en compte l’application de la route vers le serveur VPN lors de l’établissement du cannal VPN. De fait la liaison finit par s’interrompre au bout de quelques minutes (lié au timeout des connexions).
Il faut donc ajouter manuellement la route :
route add -host le_serveur_vpn gw votre_passerelle_actuelle
Lors de l’établissement de la connexion L2TP, il est possible que le serveur indique dans les logs
sent [LCP TermReq id=0x3 "peer refused to authenticate"]
Cette ligne indique une erreur dans le fichier /etc/l2tp/l2tp.conf ou /etc/xl2tp/xl2tp.conf.
Il faut impérativement avoir :
require authentication = no
à la place de
refuse authentication = yes
puisque le premier n’impose pas d’authentification mais ne la refuse pas, tandis que la seconde refuse toute authentification.