Archive for the ‘informations techniques’ Category

Windows, modification de la MTU

mardi, mai 28th, 2024

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:00000514

Compilation du client VPN sur GENTOO

mercredi, octobre 5th, 2022

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

Ubuntu 20.04 et non résolution de nom externe une fois connecté en VPN

lundi, mai 30th, 2022

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.

Fin prévu de vpn14 et évolution de vpn20

jeudi, janvier 6th, 2022

Bonjour à toutes et tous,

depuis 2008, le VPN évolue pour rendre un service plus simple (souvent) et plus sécurisant (toujours).

Voici le rappel des versions successives :

  • 2008-2014 : vpn1 (Besançon), vpn2 (Montbéliard), vpn3 (Belfort) en IPSEC/ikeV1/L2TP
  • 2014-2020 : vpn14 IPSEC/ikeV1/SHREW
  • 2020-2022 : vpn20-1, vpn20-2 IPSEC/ikeV2/natif OS

La pandémie et l’accélération du “travail à la maison/télétravail” a fait prendre conscience à chacun de la nécessité des outils de travail à distance. Le VPN a donc évolué en 2020 pour en faciliter l’accès.

Serveur vpn14, connexion SHREW

Nous projetons maintenant la fermeture de l’ancien serveur vpn14 (ikev1/shrew) pour juillet 2022.

Si vous possédez un accès VPN avec SHREW, il faudra penser à évoluer sur la nouvelle infrastructure.

Administration du service

Dans le même temps, nous allons changer de procédure de création des droits d’accès au VPN pour le déléguer aux composantes et laboratoires. La création de certificat n’étant plus nécessaire, cette délégation permettra de simplifier la mise en place des droits des usagers sur les realms @ufc et @ufc-pub d’une part et sur les realms spécifiques d’autre part.

MFA (Multi-Factor Authentication)

Nous allons mettre en place pour le VPN un 2FA (Double Authentification). Cette mesure permettra de sécuriser un peu plus les accès au sein de l’UFC.

Le moyen retenu pour le moment est Google Authenticator.

Cela se concrétise par l’usage d’un code (généré par une application ou un add-on de navigateur) à la fin de votre mot de passe.

L’application se base sur la date, l’heure et un nombre tiré au hasard (propre à votre instance d’application et au système d’authentification de l’UFC pour votre compte) pour générer le code à appliquer en plus de votre mot de passe. Code qui certifiera que vous êtes bien la personne qui doit être authentifiée.

Tester son MTU sous Windows

mercredi, décembre 15th, 2021

Vous pouvez trouver l’outil mtupath.exe (https://www.iea-software.com/products/mtupath/).

Une fois chargé dans votre répertoire, ouvrez une console CMD.

cd %userprofile%\Downloads ;
mtupath.exe vpn20-2.univ-fcomte.fr ;

il va sortir des informations du style :

MTU path scan to vpn20-2.univ-fcomte.fr (194.57.91.249), ttl=64, limit=48 # 21 best MSS 1412 (estimated MTU 1440) [pPPPPpPppP****ppPPP**]

#1 MSS IN RANGE 1 <== 1411 ==> 1412
#2 SCAN TIMEOUT 1413 <== 31 ==> 1444
#3 MSS EXCEEDED 1445 <== 14939 ==> 16384

[WARNING] Possible PMTU blackhole in route to peer

A partir de là si vous regarder l’état du MTU de l’interface avec laquelle vous vous connectez au VPN :

netsh interface ip show interfaces

Vous pourrez facilement faier un réglage plus adéquat :

netsh interface ipv4 set subinterface “nom de l’interface listée ci-dessus” mtu=XXXX store=persistent

VPN et TGV

mercredi, décembre 15th, 2021

Il est possible que dans le TGV votre connexion VPN n’aboutisse pas.

Nous avons fait certains réglages en fixe dans les attributs de la connexion VPN qui ne sont peut-être pas les bons lorsque vous utilisez le VPN dans le TGV.

La solution est de faire un réglage du MTU de la connexion réseau que vous utilisez pour le VPN avec une valeur différente de celle fixée.

Pour cela, ouvrez une fenêtre shell (commande CMD). Ensuite, faire dans la fenêtre CMD

netsh interface ip show interfaces

Vous obtenez la liste des interfaces réseau que vous utilisez sur votre machine.

Choisissez l’interface WIFI (vu que vous êtes dans le TGV).

Tapez la commande dans la fenêtre CMD :

netsh interface ipv4 set subinterface “le nom de l’interface wifi” mtu=1264 store=persistent

Et essayez de relancer votre connexion VPN. Avec cette nouvelle valeur, la connexion devrait être correcte.

Problème de navigation une fois le VPN activé suite à upgrade en debian 10.10 et ubuntu 20.04/21.04

mercredi, septembre 15th, 2021

Il est possible que la connexion au VPN (vpn20-1, vpn2-2 ou vpn20-3) via la WIFI ne fonctionne pas correctement.

Il se trouve que sur ces OS récents, il n’est plus possible de faire le réglage de la MTU via les paramètres graphique de la connexion WIFI.

Un ip address va vous informer sur l’état de votre conenxion.

Exemple :

dsin@dsin-NL40-50GU:~$ ip address
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: wlp0s12f0: mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:41:8c:68:37:56 brd ff:ff:ff:ff:ff:ff
inet 172.21.205.141/20 brd 172.21.207.255 scope global dynamic noprefixroute wlp0s12f0
valid_lft 4992sec preferred_lft 4992sec
inet 10.248.3.19/32 scope global wlp0s12f0
valid_lft forever preferred_lft forever
inet6 fe80::3c5:7d40:52b7:1452/64 scope link noprefixroute
valid_lft forever preferred_lft forever

ce qu’il faut voir ici est la ligne :

2: wlp0s12f0: mtu 1500 qdisc noqueue state UP group default qlen 1000

Qui indique un MTU à 1500 octets.

Ainsi la connexion VPN basé sur le WIFI n’est pas fonctionnelle.

Il faut ré-appliquer “à la main” la procédure suivante (merci à Sébastien Picard d’avior été vigilent sur ce point) dans le fichier /etc/NetworkManager/dispatcher.d/01-ifupdown :

if [ "$2" = "vpn-up" ] || [ "$2" = "vpn-down" ]; then
ADDRESS_FAMILIES=""
ip link set dev "$1" mtu 1300
fi

Une fois cela fait vous pouvez arrêter le VPN, relancer la connexion WIFI et relancer la connexion VPN.

Opérateurs et IPv6

lundi, août 26th, 2019

Chez certains opérateurs, la connexion réseau s’établit en IPv6.
Cela n’impacte pas votre navigation, mais comme le serveur VPN est en IPv4 seulement, vous ne pourrez pas vous connecter.

Donc si vous utilisez votre téléphone pour connecter votre portable informatique (plus le partage de connexion WIFI ou USB).

Il faut donc aller dans les paramètres du téléphone pour valider IPv4 uniquement et refaire la procédure de connexion VPN.

Correction de la déconnexion des clients MAC OSX

mercredi, janvier 28th, 2015

Les usagers du VPN avec ddes clients Mac OSX peuvent éprouver des difficultées suite à des déconnexions.
Ces déconnexions, si elles ne sont pas dûes à d’autre causes, sont interne au système OSX.
Cela est noté comme bug depuis Mac OSX 10.9.1. Apple refuse de le corriger.
Il existe un fichier dans les Mac OSX qui spécifie un timeout au bout de 3600s.

Vous trouverez des fichiers *.conf dans /var/run/racoon/.
L’un d’eux annoncera lifetime time 3600 sec

pour corriger le problème, il suffit de suivre le post de Simon Heimlicher

VPN et accès Internet

mercredi, décembre 17th, 2014

Jusqu’à présent lorsque vous êtes connectés en VPN sur l’UFC, vous ne pouvez pas naviguer en même temps sur Internet sans configurer le proxy.
Du coup certains services sont difficilement accessible (Visio/SSH/…).
Nous avons mis en place une solution pour que les usagers du VPN dans le realm @ufc puisse avoir accès à l’extérieur sans pour autant configurer un serveur mandataire.
Il s’agit du serveur NAT qui est pour le moment en phase de tests.
Si vous avez un retour à ce sujet n’hésitez pas à contacter vpn-master at univ-fcomte.fr