[Resolu] Problème Résolution DNS

Oni_Shadow · Le 02/04/2022, à 13:35

Bonjour,
Je reprend la discussion commencée ici sur les problème DNS récent de mon ordinateur

Il semblerait que tout soit rentrée dans l'ordre pour le serveur etc. depuis le redémarrage du routeur, mais, sur 22.04, le soucis persiste. Impossible d'avoir une résolution DNS correcte avec la conf de base. Je ne peu pas ping google si aucun domaine, mais 8.8.8.8 fonctionne.
En passant à 192.168.1.1 dans résolv.conf tout fonctionne mais le changement n'est valide que jusqu'au prochain démarrage...

Dernière modification par Oni_Shadow (Le 02/04/2022, à 20:39)

Coeur Noir · Le 02/04/2022, à 14:31

C'est « normal » qu'une modification dans resolv.conf ne tienne que le temps de la session.

Quels sont tes paramètres dans le gestionnaire réseau, l'équivalent de Network-Manager sous KDE ?

Cette page a l'air d'actualité : https://www.lifewire.com/how-to-configu … ma-4683939

Note aussi que dans Firefox, tu peux préciser un DNS distinct.

Dernière modification par Coeur Noir (Le 02/04/2022, à 14:44)

Oni_Shadow · Le 02/04/2022, à 16:24

Oui je sais que c'est normal, (et j'ai aussi envie de comprendre pourquoi la config de base ne marche plus, je n'ai rien fait si ce n'est mettre à jour)...
Je suis sous GNOME (session ubuntu classique), mais je vais regarder ta page, cela me donnera peut-être des idées :-)

bruno · Le 02/04/2022, à 17:19

Il y a plusieurs endroits où on peut définir les résolveurs DNS.
D'abord sur ton routeur s'il sert aussi de DHCP. Ainsi les machines connectées obtiennent automatiquement les adresses des résolveurs choisis. (meilleure méthode)
Ensuite, effectivement dans NetworkManager (voir l'utilitaire de gestion réseau de GNOME).
Au niveau du système avec systemd-resolved dans le fichier /etc/systemd/resolved.conf, ou avec DHCP dans le fichier /etc/dhcp/dhclient.conf.

Il serait utile que tu montres ta configuration réseau :

ip a
ip route
resolvectl status

Oni_Shadow · Le 02/04/2022, à 17:34

Merci Bruno
Effectivement à la base cela se faisait niveau routeur ce qui était pratique.
J'ai essayé dans network-manager, mais ća n'a rien donné
J'ai aussi regarder mon

cat /etc/systemd/resolved.conf 
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
DNS=192.168.1.1 # Ajouté il y a quelque minute par ce que la conf me semblait bien vide ! 
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no

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: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 60:57:18:5e:1b:4a brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.248/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp1s0
       valid_lft 86139sec preferred_lft 86139sec
3: ipv6leakintrf0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 7e:b9:2b:e0:8f:0a brd ff:ff:ff:ff:ff:ff
    inet6 fdeb:446c:912d:8da::/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::77d6:9ab1:f306:fc6/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

ip route
default via 192.168.1.1 dev wlp1s0 proto dhcp metric 600 
169.254.0.0/16 dev wlp1s0 scope link metric 1000 
192.168.1.0/24 dev wlp1s0 proto kernel scope link src 192.168.1.248 metric 600

resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

Link 2 (wlp1s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (ipv6leakintrf0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: ::1
       DNS Servers: ::1
        DNS Domain: ~.

Mais tout à l'aire d'être OK maintenant, je redémarre pour voir

Oni_Shadow · Le 02/04/2022, à 17:37

Après re´demarage cela ne fonctionne pas,
J'ai repris le résultat des commandes avant de faire mon changement habituel dans /etc/resolv.conf pour écrire ici

$ os @ DellDevel  ~
└──▶  resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

Link 2 (wlp1s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (ipv6leakintrf0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: ::1
       DNS Servers: ::1
        DNS Domain: ~.
$ os @ DellDevel  ~
└──▶  ip route
default via 192.168.1.1 dev wlp1s0 proto dhcp metric 600 
169.254.0.0/16 dev wlp1s0 scope link metric 1000 
192.168.1.0/24 dev wlp1s0 proto kernel scope link src 192.168.1.248 metric 600 
$ os @ DellDevel  ~
└──▶  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: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 60:57:18:5e:1b:4a brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.248/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp1s0
       valid_lft 86297sec preferred_lft 86297sec
3: ipv6leakintrf0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 7e:b9:2b:e0:8f:0a brd ff:ff:ff:ff:ff:ff
    inet6 fdeb:446c:912d:8da::/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::77d6:9ab1:f306:fc6/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Édit : J'ai pas l'impression qu'il y ai de modification significative pourtant

Dernière modification par Oni_Shadow (Le 02/04/2022, à 17:41)

Coeur Noir · Le 02/04/2022, à 17:44

Oni_Shadow a écrit :

Je suis sous GNOME (session ubuntu classique)

Ah, un instant, j'ai cru voir un forum tout bleu, j'ai cru que t'étais sous KDE du coup…
Tu as cette doc' plus tout à fait à jour mais ok dans les grandes lignes https://doc.ubuntu-fr.org/network-manager

Oni_Shadow · Le 02/04/2022, à 17:47

Oui j'ai commencé sous KUBUNTU 07.04, j'ai pris l'habitude du forum bleu ^^
Je vais regarder cette doc merci

bruno · Le 02/04/2022, à 18:21

Effectivement à la base cela se faisait niveau routeur ce qui était pratique.

Et pourquoi n'est-ce plus le cas ?

Le retour de resolvectl status montre que la résolution de nom n'est pas gérée par systemd-resolved :

  resolv.conf mode: foreign

Peut-on voir (avant modification) :

cat /etc/resolv.conf
cat /etc/NetworkManager/NetworkManager.conf

Oni_Shadow · Le 02/04/2022, à 19:32

bruno a écrit :

Et pourquoi n'est-ce plus le cas ?

Disons que ća l'est ; c'est que avant de trouver l'astuce dans /etc/resolv.conf avec 192.168.1.1, j'utilisais 8.8.8.8 ce qui est moins pratique par ce que je n'ai pas accès à mes nom de domaines pour mes serveurs locaux (et plus de latence, moins de bande passante).

bruno a écrit :

Le retour de resolvectl status montre que la résolution de nom n'est pas gérée par systemd-resolved :
  resolv.conf mode: foreign

Effectivement ća doit être le problème. J'ai d'ailleurs remarqué que je n'avais pas de commande systeld-resolved de dispo... mais pas vu comment l'installer

bruno a écrit :

Peut-on voir (avant modification) :
cat /etc/resolv.conf
cat /etc/NetworkManager/NetworkManager.conf

Yep

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53
# nameserver 192.168.1.1 # je commente la 1ere ligne et décommente celle-ci pour avoir accès au net

cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

Pour l'instant mes tentatives avec Network manager n'ont rien donné non plus

bruno · Le 02/04/2022, à 19:48

C'est très bizarre…
Il faudrait regarder s'il y a des choses sous /etc/netplan (doc netplan), le contenu de /etc/network/interfaces, ou un autre truc qui gérerai la connexion WiFi en dehors de NetworkManager et bien vérifier s'il n'y a pas un pare-feu mal configuré qui bloque 127.0.0.53

Sinon, je suggère :
/etc/NetworkManager/NetworkManager.conf :

[main]
plugins=ifupdown,keyfile
dns=systemd-resolved
rc-manager=file

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

Puis suppression du fichier /etc/resolv.conf :

sudo mv /etc/resolv.conf /etc/resolv.conf.backup

Redémarrage de NetworkManager :

sudo systemctl restart NetworkManager

On vérifie si le fichier resolv.conf a bien été recréé :

cat /etc/resolv.conf

Et on teste avec dig :

dig ubuntu-fr.org

Dernière modification par bruno (Le 02/04/2022, à 19:53)

Oni_Shadow · Le 02/04/2022, à 20:13

dig ubuntu-fr.org

; <<>> DiG 9.18.1-1ubuntu1-Ubuntu <<>> ubuntu-fr.org
;; global options: +cmd
;; connection timed out; no servers could be reached

ca n'a pas l'aire mieux, je vais regarder du côté de netplan

xubu1957 · Le 02/04/2022, à 20:18

Bonjour,

Tu n'utilises pas protonvpn ?

Oni_Shadow · Le 02/04/2022, à 20:19

Bonjour, Si pourquoi ?

Depuis longtemps d'ailleurs, ca ne posais pas de soucis avant, j'ai vérifié d'ailleurs que pas de config active (je m'était fait avoir une fois)

Dernière modification par Oni_Shadow (Le 02/04/2022, à 20:20)

xubu1957 · Le 02/04/2022, à 20:20

Montre, en te servant du Retour utilisable de commande :

nmcli device

> askubuntu.com/questions/1319033/internet-stops-working-after-installing-protonvpn

Dans Askubuntu, le 19/03/2021, User.cpp a écrit :

I found out I had two extra connections that had remained there and the system was trying to route through them, so after identifying them I simply did
J'ai découvert que j'avais deux connexions supplémentaires qui étaient restées là et que le système essayait de les acheminer, donc après les avoir identifiées j'ai simplement fait
sudo nmcli connection delete pvpn-killswitch
sudo nmcli connection delete pvpn-ipv6leak-protection
After that rebooting solved everything. Après cela, le redémarrage a tout résolu.

repris dans ce fil

Oni_Shadow · Le 02/04/2022, à 20:33

Intéressant !

$ os @ DellDevel  ~
└──▶  nmcli device
DEVICE             TYPE      STATE         CONNECTION               
wlp1s0             wifi      connected     45                       
ipv6leakintrf0     dummy     connected     pvpn-ipv6leak-protection 
44:00:10:21:4A:7A  bt        disconnected  --                       
78:62:56:B7:B0:97  bt        disconnected  --                       
p2p-dev-wlp1s0     wifi-p2p  disconnected  --                       
lo                 loopback  unmanaged     --

j'ai comme l'impression que `ipv6leakintrf0` / `pvpn-ipv6leak-protection` est en trop, non ?

Dernière modification par Oni_Shadow (Le 02/04/2022, à 20:34)

xubu1957 · Le 02/04/2022, à 20:36

Je ne suis pas au point en matière de réseau.

Je laisse la main aux aidants connaisseurs.

Oni_Shadow · Le 02/04/2022, à 20:38

Et bien testé et approuvé !

 sudo nmcli connection delete pvpn-ipv6leak-protection

Tout fonctionne correctement maintenant, fallait le trouvé celui-là !
Merci beaucoup à tous pour vos contributions :-)

Dernière modification par Oni_Shadow (Le 02/04/2022, à 20:39)

Coeur Noir · Le 03/04/2022, à 16:24

fallait le trouvé celui-là !
Il n'apparaissait pas dans ton gestionnaire de réseau ? Ou dans « paramètres / réseau / vpn » ?

Oni_Shadow · Le 03/04/2022, à 20:11

et non ! quand je suis connecté à protonvpn, je le vois bien, (c'est pourquoi j'avais précisé que je n'était pas co). La je crois que la déco était partielle : rien dans NM.
J'ai fait un test, à l'instant : quand Protonvpn est en route normalement j'ai

nmcli device
DEVICE             TYPE      STATE                   CONNECTION               
ipv6leakintrf0     dummy     connected               pvpn-ipv6leak-protection 
proton0            tun       connected (externally)  proton0                  
wlp1s0             wifi      connected               45                       
44:00:10:21:4A:7A  bt        disconnected            --                       
78:62:56:B7:B0:97  bt        disconnected            --                       
p2p-dev-wlp1s0     wifi-p2p  disconnected            --                       
lo                 loopback  unmanaged               --

il y a bien la ligne dummy qui n'apparait pas dans NM, mais également une autre qui, elle apparaît !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 02/04/2022, à 13:35

[Resolu] Problème Résolution DNS

#2 Le 02/04/2022, à 14:31

Re : [Resolu] Problème Résolution DNS

#3 Le 02/04/2022, à 16:24

Re : [Resolu] Problème Résolution DNS

#4 Le 02/04/2022, à 17:19

Re : [Resolu] Problème Résolution DNS

#5 Le 02/04/2022, à 17:34

Re : [Resolu] Problème Résolution DNS

#6 Le 02/04/2022, à 17:37

Re : [Resolu] Problème Résolution DNS

#7 Le 02/04/2022, à 17:44

Re : [Resolu] Problème Résolution DNS

#8 Le 02/04/2022, à 17:47

Re : [Resolu] Problème Résolution DNS

#9 Le 02/04/2022, à 18:21

Re : [Resolu] Problème Résolution DNS

#10 Le 02/04/2022, à 19:32

Re : [Resolu] Problème Résolution DNS

#11 Le 02/04/2022, à 19:48

Re : [Resolu] Problème Résolution DNS

#12 Le 02/04/2022, à 20:13

Re : [Resolu] Problème Résolution DNS

#13 Le 02/04/2022, à 20:18

Re : [Resolu] Problème Résolution DNS

#14 Le 02/04/2022, à 20:19

Re : [Resolu] Problème Résolution DNS

#15 Le 02/04/2022, à 20:20

Re : [Resolu] Problème Résolution DNS

#16 Le 02/04/2022, à 20:33

Re : [Resolu] Problème Résolution DNS

#17 Le 02/04/2022, à 20:36

Re : [Resolu] Problème Résolution DNS

#18 Le 02/04/2022, à 20:38

Re : [Resolu] Problème Résolution DNS

#19 Le 03/04/2022, à 16:24

Re : [Resolu] Problème Résolution DNS

#20 Le 03/04/2022, à 20:11

Re : [Resolu] Problème Résolution DNS

Pied de page des forums