16.10 ne parviennent pas à résoudre le DNS
Après avoir mis à niveau mon installation de 16.04 vers 16.10, j'ai des problèmes avec DNS.
Tout d'abord, j'ai eu quelques problèmes de connexion au WiFi alors que cela fonctionnait sur Ethernet. Maintenant, il semble que le WiFi fonctionne également. Je ne sais pas pourquoi, et si cela a un quelconque rapport avec le problème auquel je fais face maintenant:
Lors de la connexion à un hôte VPN avec Cisco Anyconnect VPN , il ajoute une ligne dans '/etc/resolv.conf'. Je comprends que Ubuntu utilise maintenant systemd-resol , et la page de manuel indique qu’il existe trois modes différents de traitement de /etc/resolv.conf. Mon /etc/resolv.conf n’est pas un lien symbolique et ne répertorie pas 127.0.0.53 en tant que serveur DNS. Par conséquent, pour autant que je sache, systemd-resol devrait "le lire pour les données de configuration DNS". Cependant, il ne semble pas s'en soucier.
Creuser
La chose étrange (pour moi) est que Dig Host.customer.tld, retourne une bonne réponse avec une SECTION REPONSE indiquant l’adresse IP de l’hôte demandé, et fait référence au serveur DNS ajouté à /etc/resolv.conf par le client VPN en tant que SERVEUR. Lorsque la connexion VPN est désactivée, je ne reçois aucune réponse. C'est à dire. Dig lit /etc/resolv.conf.
ping
Le navigateur, de l’autre côté, n’a pas accès à /etc/resolv.conf et n’est pas en mesure de résoudre le nom d’hôte. Soit dit en passant, ping/curl non plus.
nmcli
J'ai trouvé un article lié , et j'ai essayé de courir
nmcli device show <interfacename> | grep IP4.DNS
mais il ne répertorie pas de DNS pour le périphérique cscotun0. (Cela ne le fait pas non plus dans 16.04, cependant.) En outre, nmcli répertorie mon serveur DHCP (mon routeur) en tant qu’hôte IP4.DNS pour mes connexions eth/wlan. Utiliser Dig @192.168.0.1 xxx pour tout domaine public fonctionne bien.
configuration
Il existe d'autres serveurs DNS répertoriés dans mon /run/systemd/resolve/resolv.conf:
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2001:4860:4860::8844
Ceux-ci ne sont pas servis par mon serveur DHCP. le fichier /etc/systemd/resolved.conf contient uniquement des lignes commentées, à l'exception de l'en-tête de la section:
[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
La page de manuel de resol.conf indique que
DNS = Liste d'adresses IPv4 et IPv6 séparées par des espaces à utiliser comme serveurs DNS système. ... Pour des raisons de compatibilité, si ce paramètre n'est pas spécifié, les serveurs DNS répertoriés dans /etc/resolv.conf sont utilisés à la place, si ce fichier existe et si des serveurs y sont configurés. Ce paramètre est défini par défaut sur la liste vide.
FallbackDNS = Liste d'adresses IPv4 et IPv6 séparées par des espaces à utiliser comme serveurs DNS de secours. Tous les serveurs DNS per-link obtenus à partir de systemd-networkd.service (8) ont priorité sur ce paramètre, comme tous les serveurs définis via DNS = above ou /etc/resolv.conf. Ce paramètre est donc utilisé uniquement si aucune autre information de serveur DNS n'est connue. Si cette option n'est pas donnée, une liste compilée des serveurs DNS est utilisé à la place.
On dirait que la solution de rechange se termine dans /run/systemd/resolve/resolv.conf dans mon cas.
EDIT: Je ne savais pas quel était le problème, et pour être honnête, je ne sais toujours pas comment cela fonctionne, mais au moins, il s’est avéré que solution dans mon cas était de désactiver le service systemd-resolved. Je pensais que ce service était nécessaire, que c'était le composant qui fournissait le service DNS à toutes les applications locales, mais apparemment, il y a autre chose qui fait ce travail.
J'ai rencontré des problèmes similaires, par exemple avec l'ajout d'un dongle wifi supplémentaire. D'abord, j'ai désactivé dnsmasq dans networkmanager comme décrit ci-dessus et j'ai arrêté dnsmasq (service dnsmasq stop)
J'ai remarqué que lors de la résolution d'une panne lors de ma connexion VPN, la table de routage est légèrement différente (sortie de la commande route). Le nom de la passerelle est DD-WRT dans le cas où cela ne fonctionne pas et simplement "passerelle" quand cela fonctionne. La sortie de cela n'a pas changé:
nmcli device show wlp1s0 | grep IP4.DNS
Il a continué à montrer mon routeur IP. Une solution de contournement pour le faire fonctionner pendant un moment consiste à redémarrer systemd-resolvd:
Sudo service systemd-resolved restart
Puisque dnsmasq est hors de l’équation, c’est soit systemd-resolvd qui est la cause du problème, soit tout ce qui modifie la table de routage.
Donc, c'est la seule différence que je vois:
ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 601 0 0
qui fonctionne. Et ceci quand ça ne marche PAS:
ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default DD-WRT 0.0.0.0 UG 601 0 0 wlp1s0
Et la même différence de nom sur la ligne VPN:
vpn-dns.name gateway 255.255.255.255 UGH 0 0 0 wlp1s0
Qui sait ce qui peut influencer la table de routage? Ce serait bien si nous pouvions l'identifier afin qu'un rapport de bogue puisse être déposé. Je commence à être sérieusement malade et fatigué de poursuivre tous ces bugs, mais j'aimerais les réparer afin que les futurs utilisateurs et nous-mêmes soyons heureux :).
[Mise à jour] Il semble que l'arrêt de systemd-resol puisse résoudre ce problème et ne pas avoir d'impact négatif sur d'autres éléments. Vous pouvez essayer cela et le faire savoir si ça casse des choses. J'ai vu lors de l'exécution de systemd-resolvd dans le débogage quand il s'est cassé:
Removing scope on link wlp1s0, protocol llmnr, family AF_INET
Removing scope on link wlp1s0, protocol llmnr, family AF_INET6
Removing scope on link *, protocol dns, family *
Pour désactiver:
Sudo systemctl disable systemd-resolved.service
J'ai mis à jour le rapport Ubuntu avec des suggestions. [/ update] Add: Note: le rapport de bogue: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317 a un correctif pour 17.04 pour certains problèmes. Veuillez vérifier le rapport de bogue et si possible tester le correctif. Je vous remercie!
[mettre à jour]
Veuillez vérifier le rapport de bogue mentionné ci-dessus, le problème semble être résolu pour 17.10 et avec une simple commande, la fuite DNS peut également être désactivée.
[/mettre à jour]
Le comportement DNS lors de la connexion OpenVPN s'est amélioré immédiatement lorsque j'ai suivi ne suggestion sur ubuntuforums:
- Ouvrez
/etc/NetworkManager/NetworkManager.confdans un éditeur avec les droits root. - Supprimez (ou commentez avec un hash
#) la ligne qui litdns=dnsmasq - Redémarrez NetworkManager via
Sudo service NetworkManager restart
Couru dans le même problème. D'une manière ou d'une autre, j'ai dû installer DNSmasq avec une application. Supprimer simplement dnsmasq a résolu le problème pour moi.
Sudo apt-get remove dnsmasq
Depuis lors, plus aucune déconnexion ni aucun site ne peut plus être chargé (un problème de chargement de gmail s’est produit, c’est-à-dire que tout à coup, il n’a pas pu se connecter à gmail, même si d’autres sites ont fonctionné).
Editez /etc/nsswitch.conf et changez
hosts: files mdns4_minimal [NOTFOUND=return] dns
à
hosts: files dns mdns4_minimal [NOTFOUND=return]
Edit:
J'ai les mêmes problèmes depuis assez longtemps. J'ai été capable de résoudre les noms de domaine de vpn mais je n'ai pas été en mesure de les cingler ou de les curl, ni de les utiliser dans d'autres applications. Le changement décrit ci-dessus l'a résolu pour moi.