Network manager/VPN - Pas d'internet/Problème DNS local (DNS leak protection forced on ?)

Bonjour à tous,

Je suis sous Debian 11 avec Gnome 3.38, et j’utilise le VPN secure core de Proton Suisse-France qui se connecte automatiquement avec la connexion au réseau wifi de la bbox (Bouygues Télécom).

Depuis hier, je ne peux plus accéder à internet bien qu’il continue à se connecter automatiquement au réseau wifi sans VPN. Avant de se connecter, j’ai remarqué qu’il indique l’icône de connection ethernet alors qu’il n’est pas connecté en filaire.

Le plus curieux, c’est que mon second ordinateur qui est sous Lubuntu et qui est configuré de la même manière avec Bouygues et Proton a exactement le même soucis - alors que ma connexion internet fonctionne sur mes autres périphériques, comme mon VPN.

Voici le résultat de quelques commandes réseau :

$ sudo lspci
06:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12)
07:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)

-
$ sudo ifconfig
enp6s0f1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 08:97:98:6c:ad:92  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 126  base 0x1000  
ipv6leakintrf0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet6 fdeb:446c:912d:8da::  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::f3c:7a4c:faf0:f91e  prefixlen 64  scopeid 0x20<link>
        ether 1a:88:44:1a:c6:0b  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 2742 (2.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Boucle locale)
        RX packets 1446  bytes 167168 (163.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1446  bytes 167168 (163.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
wlp7s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.28  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::92be:d9df:20c8:c4dc  prefixlen 64  scopeid 0x20<link>
        inet6 2001:861:e100:570:39c0:933c:b49f:58b9  prefixlen 64  scopeid 0x0<global>
        ether 3c:91:80:d3:73:e7  txqueuelen 1000  (Ethernet)
        RX packets 335  bytes 30523 (29.8 KiB)
        RX errors 0  dropped 282  overruns 0  frame 0
        TX packets 168  bytes 26586 (25.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

-
$ sudo iwconfig
lo        no wireless extensions.
enp6s0f1  no wireless extensions.
ipv6leakintrf0  no wireless extensions.
wlp7s0    IEEE 802.11  ESSID:"PILOUSWIFI"  
          Mode:Managed  Frequency:5.26 GHz  Access Point: 10:D7:B0:CB:9B:D4   
          Bit Rate=234 Mb/s   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=41/70  Signal level=-69 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:53   Missed beacon:0

-
$ sudo ip a
1: lo: <LOOPBACK,UP,LOWER_UP> 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: enp6s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 08:97:98:6c:ad:92 brd ff:ff:ff:ff:ff:ff
3: ipv6leakintrf0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 1a:88:44:1a:c6:0b brd ff:ff:ff:ff:ff:ff
    inet6 fdeb:446c:912d:8da::/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::f3c:7a4c:faf0:f91e/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: wlp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3c:91:80:d3:73:e7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.28/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp7s0
       valid_lft 85343sec preferred_lft 85343sec
    inet6 2001:861:e100:570:39c0:933c:b49f:58b9/64 scope global dynamic noprefixroute 
       valid_lft 86142sec preferred_lft 14142sec
    inet6 fe80::92be:d9df:20c8:c4dc/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

-
$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback

-
$ cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	HCORPORATION.lan	HCORPORATION

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

-
$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver ::1

-
$ ping -c 5 google.com
ping: google.com: Nom ou service inconnu

Qu’en pensez-vous ?

Je vous remercie par avance,

LR

Je ne vois rien là-dedans qui te permette de conclure « pas de connexion internet ».
Que donne

ping 8.8.8.8

Si je devais jouer aux devinettes, je dirais que la résolution DNS est cassée parce que /etc/resolv.conf désigne un serveur DNS local sur la machine qui n’existe pas ou ne fonctionne pas.

PS : les symptômes ressemblent furieusement à Pas de connexion internet...sauf avec un VPN! - #16 par FrancoisPizarre

Bonjour,

Je vous remercie pour votre réponse. Effectivement, j’ai internet mais il y a un problème de DNS local - je ping sans problème l’adresse 8.8.8 8 :

$ ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=22.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=21.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=32.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=19.3 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=115 time=19.8 ms

— 8.8.8.8 ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 19.323/23.129/32.687/4.899 ms

Je crois qu’il y a eu un problème soudain en relation avec la connexion VPN qui a modifié la configuration réseau en ce sens (peut-être la protection contre les fuites DNS qui est restée activée et qui cause des problèmes). Sauriez-vous comment résoudre la difficulté - sans devoir tout réinstaller ?

En vous remerciant.

Je ne le sais pas plus que lorsque j’ai répondu dans l’autre sujet. Ce ne serait pas une option paramétrable du VPN ?

Bonjour,

Finalement, j’avais réussi en relançant le logiciel de ProtonVPN à désactiver correctement la protection contre les fuites DNS, mais les paramètres de Network-Manager posaient toujours problème pour la connexion au réseau wifi de Bouygues. Donc j’ai lancé la commande :

apt-get autoremove – purge network-manager

Et j’ai réinstallé l’utilitaire réseau après avoir redémarré et m’être reconnecté en ethernet à l’aide de la commande :

sudo dhclient eth0 (nom du périphérique ethernet)

Et ça a refonctionné sans problème. En approfondissant un peu, je me suis rendu compte que le problème était lié à mon fournisseur d’accès à internet qui n’est pas parfaitement compatible avec les VPN - sans doute à dessein. Donc je vais en changer.

Je vous remercie.

Tu fais comme tu veux mais je vois pas en quoi un opérateur peut-être bloquant pour l’établissement d’un tunnel VPN, peux-tu apporter les informations qui te laissent penser le contraire ?

Je ne serais pas contre des précisions, car je ne vois pas bien non plus en quoi un FAI ne serait pas compatible avec les VPN, à moins de ne pas laisser passer (volontairement ou non, par exemple par effet de bord du partage d’adresse IPv4 publique entre plusieurs abonnés) un élément du trafic nécessaire au VPN (protocole, port, adresse de destination). Et surtout je ne vois pas le rapport avec la protection contre les fuites de DNS.