J’ai installé Debian xfce il y a trois mois, et tout fonctionnait très bien jusqu’à il y a deux semaines environ.
Je précise, si ça a son importance, que c’est une très vieille machine, morte sous windows il y a 5 ans, et qui tournait sur xubuntu puis manjaro depuis.
Mon problème est le suivant:
Je capte le wifi, et le gestionnaire de connexion me dit que j’y suis connecté, mais impossible de naviguer sur internet, mes navigateurs me font des messages d’erreur comme quoi je ne suis pas connecté.
Or, fait étonnant, j’arrive à me surfer sans problème en utilisant un VPN!
Je n’ai pas de proxy ni de pare feu
J’ai testé quelques bidouilles simples avec un ami qui connaît Debian bien mieux que moi, et rien n’y a fait…
Quelqu’un pourrait-il m’aider? Ou m’orienter vers une hypothèse à laquelle je n’aurais pas pensé?
Un navigateur n’est pas compétent pour décider si on est « connecté » ou non.
Ce qui prouve que tu es connecté, sinon tu ne pourrais pas monter le VPN.
Lesquelles, pour éviter de faire perdre du temps à tout le monde ?
route est obsolète, et son format de sortie avec la passerelle entre le réseau et le masque est peu lisible. Il vaut mieux utiliser ip en IPv4 pour afficher la table de routage IPv4 mais aussi IPv6 qui n’est plus si rare de nos jours même chez les FAI grand public :
ip -4 route
ip -6 route
De nos jours il ne suffit plus de regarder dans le fichier /etc/resolv.conf pour savoir comment se fait la résolution de nom car il peut y avoir d’autres sources que DNS et le le fichier /etc/hosts : systemd-resolved, DoH (DNS over HTTPS)… Il faut aussi regarder la ligne « hosts: » dans /etc/nsswitch.conf. Accessoirement les navigateurs peuvent aussi avoir leur propre résolution de nom via DoH indépendamment de la configuration du système.
Firefox supporte aussi DoH.
Quant à nsswitch.conf, il peut être modifié automatiquement par les paquets qui fournissent un service de résolution de nom.
Bonjour, merci beaucoup pour vos réponses et votre disponibilité.
Précision 1: le problème ne concerne pas que les navigateurs web, c’est la même chose avec les mises à jour, Thunderbird, et mon logiciel de compta, par exemple.
Précision 2: en ce qui concerne les tentatives de mon copain, je crois me souvenir que c’était en rapport avec le DNS (essayer de rentrer manuellement un DNS de google, si je me souviens bien…). Et quelques commandes (que j’ai oubliées…) pour identifier le problème, sans succès.
Désolé, je me suis trompé dans les commandes à exécuter pour afficher les routes. Il s’agit de
ip -4 route
ip -6 route
On peut déjà voir que le serveur DNS défini dans resolv.conf est ::1, l’adresse locale IPv6, donc il s’agit d’un proxy DNS qui tourne sur la machine. Examiner la liste des sockets ouvertes pour trouver quel processus écoute sur le port 53.
ss -nlp | grep 53
ou
netstat -nlp | grep 53
En tout cas le remplacement du DNS quand le VPN est actif semble avoir un effet.
Il y a aussi une adresse IPv6 ULA sur une interface bizarre ipv6leak, mais il faudrait voir les routes IPv6 pour déterminer son influence.
Ne mets pas des images, mets directement le texte retourné par la commande, c’est beaucoup plus simple est accessible.
En plus, tu l’as fait sur le message que j’ai cité.
default via 172.16.12.1 dev wlp5s0 proto dhcp metric 600
169.254.0.0/16 dev wlp5s0 scope link metric 1000
172.16.12.0/24 dev wlp5s0 proto kernel scope link src 172.16.12.44 metric 600
ip-6 route
::1 dev lo proto kernel metric 256 pref medium
fdeb:446c:912d:8da::/64 dev ipv6leakintrf0 proto kernel metric 95 pref medium
fe80::/64 dev ipv6leakintrf0 proto kernel metric 95 pref medium
fe80::/64 dev wlp5s0 proto kernel metric 600 pref medium
default via fdeb:446c:912d:8da::1 dev ipv6leakintrf0 proto static metric 95 pref medium
default via 10.29.0.1 dev proton0 proto static metric 50
default via 172.16.12.1 dev wlp5s0 proto dhcp metric 600
10.29.0.0/16 dev proton0 proto kernel scope link src 10.29.0.57 metric 50
89.39.107.113 via 172.16.12.1 dev wlp5s0 proto static metric 600
169.254.0.0/16 dev wlp5s0 scope link metric 1000
172.16.12.0/24 dev wlp5s0 proto kernel scope link src 172.16.12.44 metric 600
172.16.12.1 dev wlp5s0 proto static scope link metric 600
ip -6 route
::1 dev lo proto kernel metric 256 pref medium
fdeb:446c:912d:8da::/64 dev ipv6leakintrf0 proto kernel metric 95 pref medium
fe80::/64 dev ipv6leakintrf0 proto kernel metric 95 pref medium
fe80::/64 dev proton0 proto kernel metric 256 pref medium
fe80::/64 dev wlp5s0 proto kernel metric 600 pref medium
default via fdeb:446c:912d:8da::1 dev ipv6leakintrf0 proto static metric 95 pref medium
Rien de particulier dans les routes à part une route IPv6 par défaut associée à un préfixe ULA sur une interface « ipv6leakintrf0 » que je ne connais pas. D’après son nom, je ne peux que supposer qu’il s’agit d’une interface virtuelle créée pour intercepter le trafic IPv6 que le VPN ne prend pas en charge (pas d’adresse ni de route IPv6 globale sur l’interface proton0) et éviter une « fuite » (leak) de ce trafic sur internet en dehors du VPN. Mais comme cette route est toujours présente que le VPN soit actif ou pas, je ne pense pas qu’elle soit en cause.
On en revient à la configuration DNS. Quand le VPN est inactif, l’adresse de serveur DNS configurée par NetworkManager dans /etc/resolv.conf est ::1, soit l’adresse IPv6 locale, mais ss n’affiche aucune socket en écoute sur le port 53 (DNS) donc la résolution DNS ne peut pas fonctionner. A moins qu’une autre source de résolution de noms globaux soit définie dans la ligne hosts: du fichier /etc/nsswitch.conf (que tu n’as pas fournie), la résolution de nom globaux ne peut pas fonctionner. mdns (Multicast DNS) ne fait que la résolution de noms locaux.
Tu peux vérifier cette hypothèse avec quelques commandes.
Vérifier la connectivité IPv4 sans résolution DNS qui devrait réussir :
ping -nc4 8.8.8.8
Vérifier la résolution DNS avec le serveur DNS local ::1 (il faut que le paquet dnsutils soit installé) :
host debian-fr.org ::1
Vérifier la résolution DNS avec un autre serveur DNS (j’ai mis celui de Google, on peut utiliser celui de la box internet ou du FAI si on connaît son adresse) :
Si les tests 1 et 3 réussissent et le test 2 échoue, alors c’est bien l’adresse ::1 dans resolv.conf qui est erronée. Comme elle est définie par NetworkManager, il faut rechercher dans les paramètres de ce dernier si cette adresse est configurée quelque part.
