lors 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.
Posts Tagged ‘ubuntu’
Ubuntu 22 et installation
mardi, novembre 7th, 2023Ubuntu 20.04 et non résolution de nom externe une fois connecté en VPN
lundi, mai 30th, 2022Avec 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.
Problème de navigation une fois le VPN activé suite à upgrade en debian 10.10 et ubuntu 20.04/21.04
mercredi, septembre 15th, 2021Il 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" ]; thenADDRESS_FAMILIES=""ip link set dev "$1" mtu 1300fi
Une fois cela fait vous pouvez arrêter le VPN, relancer la connexion WIFI et relancer la connexion VPN.