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
Si la connexion VPN est active et que les sites universitaires ne sont pas accessibles, voici une liste à vérifier :
Voici un script qui modifie la base de registre pour y placer directement la bonne valeur de MTU. En effet, nous nous sommes rendu compte que parfois la modification manuelle (à partir de l’interface réseau) n’était pas prise en compte correctement. En modifiant la base de registre, la valeur affectée est la bonne.
Voici le programme set-vpn-mtu.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocoles]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocoles\0]
"ProtocolType"=dword:00000800
"PPPProtocoleType"=dword:00000021
"TunnelMTU"=dword:00000514lors de l’installation avec la documentation du VPN sur une Ubuntu version 22 un problème de MTU peut apparaître. L’outil graphique nmtui permet de vérifier et de corriger le problème.
Nous n’avons pas à ce jour identifié le problème des déconnexions non demandées au bout de 2h ou 8h.
Les pistes sont :
Les collègues de FEMTO-ST (entre autre) ont été confronté au problème de montage de disque (par exemple) suite à l’établissement de la connexion VPN. En effet, dans ce cas, ce sont les identifiants utilisés par la connexion VPN qui sont rejoués pour le montage du disque sur le domaine considéré. Or ces identifiants ne peuvent pas être reconnu car spécifique à l’établissement de la connexion VPN.
Les collègues nous ont fourni le moyen de modifier le script d’établissement de la connexion avec deux ajouts :
$pbkpath = "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk"
(Get-Content -path $pbkpath -Raw) -Replace 'UseRasCredentials=1','UseRasCredentials=0' | Set-Content -path $pbkpathCes premières lignes permettent de modifier le fichier « rasphone.pbk » qui contient une variable qui permet de redemander un identifiant de connexion…
Add-VpnConnectionTriggerDnsConfiguration -ConnectionName "VPN UFC" -DnsIpAddress "195.83.19.60" -DnsSuffix "femto-st.fr" -PassThru -ForceCette troisième ligne permettant d’interroger le bon DNS du domaine « femto-st.fr ».
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
Lors d’une tentaive de connexion au serveur VPN sous Windows 10, le message suivant s’affiche : « Le port est déjà ouvert« .
Après investigation, on se rend compte qu’aucun autre logiciel en cours de fonctionnement utilise les ports utilisé par Ikev2. Or, on se rend compte que les connexions WAN Miniport du gestionnaire de périphériques ont disparues.
Les mises à jour de l’OS, des pilotes,… n’y font rien.
Solution : pour réinstaller la pile WAN, il faut se rendre dans C:\Windows\inf et installer manuellement netavpna.inf (clic droit sur le fichier puis installer).
Merci à Romain Pacé son retour.
Avec la version 22.04, le fonctionnement de dnsmasq a changé. Un client Ubuntu 20.04 connecté au VPN de l’UFC et voulant aller sur un site externe à l’UFC se retrouve bloqué car la résolution de nom échoue.
Explication
Nous avons pu identifier le problème au niveau de dnsmasq, sans pour autant retrouver l’explication de la différence de fonctionnement.
Sur les versions 18.04 et 20.04, le dnsmasq était interrogé et lorsque celui-ci n’avait pas de réponse (aucun cas n’étant trouvé dans la configuration), il passait la main au DNS de base (le DNS de la Box ou de la connexion 4G).
Avec la dernière version (22.04), si dnsmasq est activé, celui-ci ne passe plus la main au serveur de base. De fait, une résolution sur un site non inclus dans la configuration échoue.
Correction
Pour corriger le problème, Jean-Michel Caricand à eu l’idée d’inclure de force un DNS de base toujours accessible.
Il faut créer un nouveau fichier /etc/NetworkManager/dnsmasq.d/00-use-dns-google.conf :
server=8.8.8.8
server=8.8.4.4
La documentation en ligne pour Ubuntu contient cette correction.