Dns_probe_finished_bad_config suite à upgrade Ubuntu de v20 vers v22

Le problème exposé dans ce sujet a été résolu.

Bonjour à tous,

Quand j’étais sur Ubuntu v20, durant les quelques minutes qui suivaient le démarrage de ma session utilisateur Ubuntu, j’ouvrais Chromium qui moulinait pour finalement afficher une erreur (de DNS si je me souviens bien). Je fermais et je rouvrais, et à partir de là inclus, le site s’affichait bien.

Je viens de passer à Ubuntu 22. 04.1 LTS. L’installation s’est correctement déroulée. Mais quand j’essaie de faire un ping www.google.fr, ou un sudo update, ou que j’ouvre Chromium sur un site, aucun transfert de données n’a lieu. Ce problème ne se limite plus aux quelques minutes suivant l’ouverture de ma session Ubuntu : il dure le temps de toute la session.

Pourtant, je suis bien connecté en wifi et le routeur est bien connecté à internet, en témoignent les autres équipements de la maison.

En particulier, quand j’ouvre Chromium j’obtiens le message d’erreur suivant :

unable to find IP of <le site>
DNS_PROBE_FINISHED_BAD_CONFIG

Du coup il semblerait que ce soit un problème de configuration du resolver de DNS, du peu de connaissances que j’ai en système réseaux.

Après avoir cherché sur Google avec mon téléphone que j’utilise d’ailleurs actuellement pour poster ce topic, j’ai trouvé que ça pouvait être un lien symbolique pété que j’ai donc tenté de recréer :

Rm /etc/resolv.conf
Ln - s /run/systemd/resolve/resolv.conf /etc/resolv.conf
Resolvconf -u
Service Network Manager restart

Mais ça n’a pas résolu le problème. Je n’ai pas rencontré d’erreur à la saisie de ces commandes. A noter que /etc/resolv.conf existait bien déjà. D’où le rm qui était nécessaire pour recréer le lien symbolique.

Voici le résultat (peu utile je pense) des commandes qui affichent la config du resolver DNS :

Le ping de l’IPv4 affichée à la clé "servername" ne fait rien (paquets perdus).

Je sèche un peu… Pourriez-vous s’il vous plaît me montrer la démarche pour résoudre ce genre de bugs ? :o

Merci beaucoup et très bon week-end à tous,

Le Jajars :ninja:

+0 -0

Quelle est l’adresse (ou les adresses) de ton résolveur DNS ? Tu peux voir cette information dans les paramètre réseaux (directement dans l’interface Gnome), ou bien en lançant resolvectl status.

On évite en général de toucher à /etc/resolv.conf qui, sur un système moderne, est géré par des intermédiaires (le résolveur de systemd par exemple).

Peux-tu ping une adresse IP du réseau Internet (pas local) directement ?

+1 -0

En fait si je comprends bien, l’IP actuelle de la clé servername ne répond pas (à mes ping).

Elle correspond au serveur DNS de l’interface finissant par "-wg5".

J’ai besoin d’utiliser l’IP de l’interface wlo1.

Or, je n’arrive pas à faire perdurer ce changement de valeur de servername d’un redémarrage à un autre du service NetworkManager.

Edit important : j’ai aussi essayé de renseigner 8.8.8.8 dans la GUI paramétre wifi, onglet Ipv4 avec attribution de l’IP par DHCP mais en ayant désactivé l’automatisation de la découverte du serveur DNS. Donc 8.8.8.8 devrait être pris en compte. Pourtant ce n’est toujours pas le cas…

+0 -0

Résolution du bug

Bonjour,

J’ai trouvé une solution. Ci-dessous les explications.

L’interface <xxx-wg5>, une interface VPN WireGuard installée dans le cadre de mon télétravail professionnel de la dernière boîte dans laquelle je n’officie plus, faisait partie du retour de : nmcli connection show et de resolvectl. Cette interface était liée à un servername DNS dont l’IP ne répondait pas aux ping que je faisais (champ Current DNS Server: du retour de resolvectl). Cette IP qui marche pas, de serveur DNS, était la cause du bug rencontré.

J’avais précédemment essayé de forcer resolvconf (configuration du résolveur DNS je suppose) à utiliser soit l’IP 8.8.8.8 (Google) soit l’IP du servername de l’interface wlo1 (interface WiFi non ?). Normalement, dans les versions récentes d’Ubuntu, c’est l’IP du servername de l’interface wlo1 qu’il faut choisir. Pour ce faire, j’avais tenté de renseigner le servername dans le fichier head de la configuration du démon resolvconf (resolvconf.d) et j’avais essayé un autre truc, mais rien ne marchait de manière permanente, seulement de manière temporaire, (= un service NetworkManager restart cassait tout) voire ça ne marchait pas du tout selon ce que je tentais.

La solution a été de supprimer l’interfacexxx-wg5 : nmcli connection delete <le UID de cette interface, vu dans la commande nmcli connection show>, car non-utilisée et associée au servername IP qui marche pas. J’ai ensuite lancé un service NetworkManager restart.

Depuis, tout est rentré dans l’ordre.

La valeur de cat /etc/resolvconf sont bonnes : c’est bien l’IP servername wlo1 qui est utilisée désormais.

Dans la GUI du NetworkManager (menu Paramètres > Wifi > Pictogramme "Engrenage" > IPv4), j’ai bien sélectionné "DHCP Automatique" (attribution IP) et surtout "DNS Automatique" donc je pense que ça joue. J’avais aussi mis: "DNS 8.8.8.8" au lieu d’automatique et ça marchait aussi, toutefois je n’avais pas vérifié dans cat /etc/resolvconf si l’IP servername 8.8.8.8 était bien utilisée et à vrai dire je m’en fouts puisque c’est pas souhaitable. (flemme de faire ce chheck)

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte