Il est possible d’utiliser le VPN sous Fedora en prenant soin d’informer le système des certificats utilisés. En particulier la chaîne de certification doit être créer à la main pour prendre en compte nos certificats de serveurs. Il faut placer le fichier de la chaîne de certification dans le répertoire /etc/ssl/certs
Le fichier ufc-vpn-chain.pem à placer dans le répertoire (enlevez le « _.txt » dans le nom du fichier).
Si la connexion VPN n’aboutit pas alors qu’un ping semble fonctionnel, l’une des causes (assez rare) peut être la MTU entre vous et le serveur (en espérant que vous ayez déjà réglé la MTU de l’interface qui vous sert à la connexion VPN à la valeur de 1300). Si votre équipement informatique est sur une box en France, ce cas ne devrait pas se présenter, mais avec un convertisseur 4G/wifi avec une connexion délicate cela peut arriver. Idem dans le TGV, par exemple.
Premièrement, et pour éviter d’autres erreurs, par exemple le fait que votre opérateur du moment ne permet pas à tous les protocoles de passer, faire le test suivant sur vpn20-2 (194.57.91.249) :
nc -uvz 194.57.91.249 500nc -uvz 194.57.91.249 4500
Si les deux tests sont en succès, passons au test suivant pour voir si la MTU ne serait pas en cause.
traceroute --mtu 194.57.91.249
1 * F=1500 * *
Cette commande doit/devrait vous retourner la MTU utilisable depuis là ou vous vous trouvez. Retenez la valeur indiquée (ici 1500).
Nous allons alors essayer de faire un ping sans fragmentation pour vérifier la valeur qui semble correcte.
La taille choisie, dans la commande ping, est la charge utile. La taille du paquet prend en compte l’encapsulation de 28 octets plus la charge utile (1472 ici).
1472+28 = 1500
ping -M do -s 1472 194.57.91.249
Si le résultat de la commande est avec des valeurs de temps (time=2.11ms) et sans erreur (ping: local error: message too long), c’est que la taille choisie est correcte :
PING 194.57.91.249 (194.57.91.249) 1472(1500) bytes of data.
1480 bytes from 194.57.91.249: icmp_seq=1 ttl=63 time=2.11 ms
1480 bytes from 194.57.91.249: icmp_seq=2 ttl=63 time=1.79 ms
Donc 1500 (1472+28) est bien la MTU de notre lien.
Pour pouvoir travailler sans problème avec la connexion VPN, il faut fixer la MTU de votre interface à la valeur 1500-200 = 1300
Plusieurs cas de PC portables sous Linux (Ubuntu et Mint) nous ont été remontés pour lesquels le tunnel VPN monte correctement mais les ressources universitaires ne sont pas joignables. Nous avons d’abord pensé à un problème de MTU souvent caractérisé par ce comportement. Mais en l’occurrence, la MTU était bien paramétrée.
Après consultation des logs des machines, on retrouve systématiquement les éléments suivants (https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg6086890.html) :
ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop
detected!
ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop
detected!
ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop
detected!
ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop
detected!
ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop
detected!
ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop
detected!La solution consiste à arrêter le service strongswan-starter (qui démarre le service strongswan en tant que serveur) qui vient en conflit avec network-manager-strongswan.
Voici les instructions nécessaires pour connaître le status de ce service :[sudo] systemctl status strongswan-starter
ou :
[sudo] service strongswan-starter status
Voici les instructions nécessaires pour arrêter ce service :
[sudo] systemctl stop strongswan-starterou :
[sudo] service strongswan-starter stopLe mieux consistera à désinstaller ce paquet avec la commande suivante :
[sudo] apt purge strongswan-starter
Dans le cas d’une installation « vierge » d’Ubuntu 24.04, ce problème ne se pose a priori pas : le service strongswan-starter n’est pas installé. Les paquets strictement nécessaires au bon fonctionnement du vpn sont :
Alexis Praga (CHU Besançon) nous signal ce point sur la compilation du client Strongswan sur une distribution Linux Gentoo.
j’ai pu faire fonctionner également le VPN sous Gentoo en utilisant votre tutorial (network-manager et son plugin). Il faut cependant installer strongswan en tant que root et avec toutes les options :
USE="caps constraints curl debug dhcp eap farp gcrypt gmp networkmanager openssl pam pkcs11 sqlite strongswan_plugins_addrblock strongswan_plugins_aesni strongswan_plugins_blowfish strongswan_plugins_bypass-lan strongswan_plugins_ccm strongswan_plugins_chapoly strongswan_plugins_ctr strongswan_plugins_error-notify strongswan_plugins_forecast strongswan_plugins_gcm strongswan_plugins_ha strongswan_plugins_ipseckey strongswan_plugins_kdf strongswan_plugins_led strongswan_plugins_lookip strongswan_plugins_newhope strongswan_plugins_ntru strongswan_plugins_rdrand strongswan_plugins_save-keys strongswan_plugins_systime-fix strongswan_plugins_unbound strongswan_plugins_unity strongswan_plugins_vici strongswan_plugins_whitelist strongswan_plugins_xauth-noauth systemd -ldap -mysql -non-root (-selinux) (-strongswan_plugins_padlock)" emerge
Sur une installation manuelle ou sur une mise à jour, il est possible que les deux options (entourées de rouge sur l’image suivante) de la connexion VPN soient invalidées.
Sans une revalidation de ces options, votre connexion au serveur VPN ne fonctionnera pas.
(Merci à Stéphane Daumas pour sa patience et l’ensemble des tests que nous avons effectués avec lui).
Si vous avez une erreur lors du lancement de la connexion VPN ou si SHREW vous demande une authentification du certificat, c’est que vous pouvez avoir l’erreur d’importation.
Sous Linux, nous retrouvons le répertoire « Téléchargement » qui est le plus souvent le répertoire par défaut de sauvegarde des pièces jointes des courriers électroniques.
Or votre certificat vous est envoyé par courrier électronique.
Si vous essayez d’importer depuis SHREW le « .vpn » qui se trouve dans le répertoire « Téléchargement« , celui-ci sera mal importé.
Cette erreur d’importation vient du logiciel SHREW qui gère mal les accents lors du choix du fichier à importer.
Il vous suffit de déplacer le « .vpn » dans votre répertoire principal et de réimporter le certificat.
Les erreurs ne devraient alors plus se reproduire.
Après la mise en route du VPN et de votre authentification, vous vous rendez compte que vous n’avez pas de réseau.
Même un ping sur votre passerelle (172.20.252.254 si vous êtes dans le realm @ufc) ne passe pas.
Pourtant le système VPN vous a bien donné une ip (172.20.252.xxx si vous êtes dans le realm @ufc).
C’est un souci qui se produit parfois suite à plusieurs déconnexions et reconnexions de votre client VPN (SHREW, sous MACOSX ce problème ne s’est pas posé en ces termes).
Ces déconnexions/connexions peuvent être volontaire ou non c’est-à-dire qu’il est possible qu’elles passent inaperçues.
Pour résoudre le souci, il faut :
– se déconnecter du VPN
– fermer la fenêtre de connexion VPN (SHREW)
– stopper le démon iked et ipsecd
* sous linux faire sudo iked
* sous window dans une fenêtre cmd
net stop ipsecd
net stop iked
net start iked
net start ipsecd
puis refaire les opérations de connexion :
– relancer le démon iked
– relancer la fenêtre de connexion VPN (SHREW)
– se connecter au VPN
Sinon vous avez aussi la possibilité de relancer votre poste de travail.
Suite à une réinstallation et la découverte de ce bug, Ernest Chiarello nous indique la marche à suivre.
Dans les sources de ubuntu, il la version 2.2.1 de Shrew existe.
# dpkg --list | grep -i shrew
ii ike 2.2.1+dfsg-2ubuntu1 amd64 Shrew Soft VPN client - Daemon and libraries
ii ike-qtgui 2.2.1+dfsg-2ubuntu1 amd64 Shrew Soft VPN client - Connection manager
Si iked se lance sans souci, vous pouvez avoir un problème avec qikea
$ qikea &
[1] 3856
qikea: error while loading shared libraries: libss_ike.so.2.2.1: cannot open shared object file: No such file or directory
Effectivement on vérifie se manque par :
$ ldd `which qikea`
libss_ike.so.2.2.1 => not found
libss_idb.so.2.2.1 => not found
libss_ith.so.2.2.1 => not found
libss_log.so.2.2.1 => not found
Mais nous pouvons corriger en demandant à ldd de rajouter les librairies utilisées par iked, en créant un fichier /etc/ld.so.conf.d/iked.conf comme suggéré ici : http://comments.gmane.org/gmane.network.vpn.shrew.user/3195
# cat /etc/ld.so.conf.d/iked.conf
/usr/lib/x86_64-linux-gnu/ike
Il faut terminer en lançant :
# ldconfig
Enfin, il faut noter que l’interface graphique qikea est disponible dans l’environnement utilisateur. (internet->shrew).
il n’est donc pas nécessaire de la lancer depuis une console, à moins d’avoir besoin de debugguer.
L’ENSMM par sa politique de sécurité qui consiste à autoriser qu’une ou deux adresses publique pour le NAT des machines en classe privée en son sein, ne permet donc qu’a un seul client Windows/Mac de se connecter sur le serveur VPN1 (194.57.91.250). Pour éviter ce problème (NAT), nous pourrions utiliser le lien direct (ENSMM-UFC) qui à été mis en place pour les besoins du laboratoire FEMTO-ST, mais l’ENSMM refuse de router les classes d’adresses de l’UFC par ce biais. De fait, le VPN ne fonctionne pas de manière efficace entre l’ENSMM et l’UFC
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).