Ubuntu 16.04 Impossible de résoudre les noms d'hôte
J'ai un problème étrange avec la résolution des noms d'hôte sur Ubuntu 16.04. Je cherche une solution à partir de vendredi (4 jours!), Donc je pense que cela ne correspond absolument pas à des questions similaires.
J'ai un serveur dans le réseau local avec deux interfaces: externe (à Internet) et interne (au réseau local). Les deux sont configurés de manière statique. Je montrerai la configuration ci-dessous.
Il fonctionnait parfaitement depuis son installation en mars. Plusieurs fois, j'ai réussi à faire 'apt update' sans problème. Vendredi, j'ai essayé de le mettre à jour à nouveau, et c'est ici que commence l'histoire principale ...
apt update
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-93-generic x86_64)
~$ Sudo apt update
Err:1 http://us.archive.ubuntu.com/ubuntu xenial InRelease
Temporary failure resolving 'us.archive.ubuntu.com'
Err:2 http://security.ubuntu.com/ubuntu xenial-security InRelease
Temporary failure resolving 'security.ubuntu.com'
Err:3 http://us.archive.ubuntu.com/ubuntu xenial-updates InRelease
Temporary failure resolving 'us.archive.ubuntu.com'
Err:4 http://us.archive.ubuntu.com/ubuntu xenial-backports InRelease
Temporary failure resolving 'us.archive.ubuntu.com'
Reading package lists... Done
Building dependency tree
Reading state information... Done
195 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/xenial/InRelease Temporary failure resolving 'us.archive.ubuntu.com'
W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease Temporary failure resolving 'us.archive.ubuntu.com'
W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease Temporary failure resolving 'us.archive.ubuntu.com'
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease Temporary failure resolving 'security.ubuntu.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.
ping/telnet
~$ ping google.com
ping: unknown Host google.com
~$ ping 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=58 time=3.87 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=3.93 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=3.88 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.870/3.898/3.939/0.077 ms
~$ telnet 8.8.8.8 53
Trying 8.8.8.8...
Connected to 8.8.8.8.
Escape character is '^]'.
Connection closed by foreign Host.
Lors des mises à jour précédentes, la résolution des noms d’hôte ne posait aucun problème. Le serveur est principalement utilisé dans le réseau local par l'adresse IP, donc je ne sais pas quand ce problème se produira. Voici donc quelques commandes que j’ai exécutées (adresse IP externe remplacée par #):
ifconfig
~$ ifconfig
enp29s0 Link encap:Ethernet HWaddr 00:10:18:25:cd:40
inet addr:#.#.#.# Bcast:#.#.#.# Mask:255.255.255.248
inet6 addr: fe80::210:18ff:fe25:cd40/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:145862 errors:0 dropped:0 overruns:0 frame:0
TX packets:119991 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14777641 (14.7 MB) TX bytes:22823397 (22.8 MB)
enp3s0 Link encap:Ethernet HWaddr 00:1a:64:c9:93:f8
inet addr:10.0.35.115 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fe80::21a:64ff:fec9:93f8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:779951 errors:0 dropped:0 overruns:0 frame:0
TX packets:608340 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:514425482 (514.4 MB) TX bytes:189891768 (189.8 MB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:2145438 errors:0 dropped:0 overruns:0 frame:0
TX packets:2145438 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:1185976997 (1.1 GB) TX bytes:1185976997 (1.1 GB)
cat/etc/network/interfaces
~$ 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
# The primary network interface - Internal
auto enp3s0
iface enp3s0 inet static
address 10.0.35.115
netmask 255.0.0.0
network 10.0.0.0
broadcast 10.255.255.255
# gateway 10.1.10.102
# # dns-* options are implemented by the resolvconf package, if installed
# dns-nameservers 10.1.10.102
metric 20
# The secondary network interface - External
auto enp29s0
iface enp29s0 inet static
address #.#.#.#
netmask 255.255.255.248
# network #.#.#.#
# broadcast #.#.#.#
gateway #.#.#.#
dns-nameservers 8.8.8.8 8.8.4.4
metric 10
#auto enp6s0
iface enp6s0 inet manual
/ etc/resolv.conf
~$ ls -la /etc/resolv.conf
lrwxrwxrwx 1 root root 27 Oct 14 01:46 /etc/resolv.conf -> /run/resolvconf/resolv.conf
~$ cat /etc/resolv.conf
# 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
nameserver 8.8.8.8
nameserver 8.8.4.4
Mais nmcli n'a montré aucun DNS configuré: nmcli
~$ nmcli dev show | grep 'DNS'
~$ nmcli dev show | grep 'IP4'
IP4.ADDRESS[1]: #.#.#.#/29
IP4.GATEWAY: #.#.#.#
Ce que j'ai fait:
plusieurs fois redémarré le serveur.
plusieurs fois redémarré, NetworkManager, résolu par systemd.
comment et commentez "dns = dnsmasq" dans /etc/NetworkManager/NetworkManager.conf (avec le service de redémarrage et le serveur).
j'ai trouvé des conseils sur la façon de désactiver DNSSEC, mais comme je l'ai trouvé, il est déjà désactivé.
made /etc/resolv.conf fichier statique (pas de lien symbolique), retournez au lien symbolique - le tout avec des redémarrages.
Rien de cela n'aide ...
Aujourd'hui 16 octobre
Aujourd'hui, j'ai créé 'apt update' et 'apt upgrade' avec une astuce: j'ai changé les noms de domaines dans /etc/apt/source.list en leurs adresses ip. Donc le système est mis à jour et devient 16.04.3. Ça n'aide pas.
/ etc/nsswitch.conf
Supprimez certains paramètres pour "hôtes" et laissez des valeurs minimales.
~$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat
group: compat
shadow: compat
gshadow: files
#hosts: files mdns4_minimal [NOTFOUND=return] dns
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
nslookup sur un serveur DNS personnalisé
Cette chose me rend finalement fou. Je lance nslookup sur un serveur DNS personnalisé ...
~$ nslookup yandex.ru 208.67.222.222
;; connection timed out; no servers could be reached
tcpdump sur le port 5
... vérifier tcpdump - il montrait trop d'enregistrements avec "bad udp cksum" ...
~# Sudo tcpdump -vvv -B 4096 -i enp29s0 Host 208.67.222.222 and port 53
tcpdump: listening on enp29s0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:01:57.043326 IP (tos 0x0, ttl 64, id 30657, offset 0, flags [none], proto UDP (17), length 55)
#.#.#.#.55778 > 208.67.222.222.domain: [bad udp cksum 0x445e -> 0x6d74!] 47660+ A? yandex.ru. (27)
ethtool
... exécutez ethtool pour éviter de tels enregistrements ...
~$ Sudo ethtool --offload enp29s0 rx off tx off
Actual changes:
rx-checksumming: off
tx-checksumming: off
tx-checksum-ipv4: off
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
tx-tcp-ecn-segmentation: off [requested on]
... et vérifiez à nouveau tcpdump:
~# cat tcpdump.log
15:26:08.451181 IP (tos 0x0, ttl 64, id 65257, offset 0, flags [none], proto UDP (17), length 55)
#.#.#.#.54228 > 208.67.222.222.domain: [udp sum ok] 23065+ A? yandex.ru. (27)
15:26:08.498299 IP (tos 0x0, ttl 57, id 4778, offset 0, flags [DF], proto UDP (17), length 119)
208.67.222.222.domain > #.#.#.#.54228: [udp sum ok] 23065 q: A? yandex.ru. 4/0/0 yandex.ru. [4m4s] A 77.88.55.80, yandex.ru. [4m4s] A 5.255.255.80, yandex.ru. [4m4s] A 77.88.55.50, yandex.ru. [4m4s] A 5.255.255.60 (91)
15:26:13.451133 IP (tos 0x0, ttl 64, id 537, offset 0, flags [none], proto UDP (17), length 55)
#.#.#.#.54228 > 208.67.222.222.domain: [udp sum ok] 23065+ A? yandex.ru. (27)
15:26:13.498225 IP (tos 0x0, ttl 57, id 5523, offset 0, flags [DF], proto UDP (17), length 119)
208.67.222.222.domain > #.#.#.#.54228: [udp sum ok] 23065 q: A? yandex.ru. 4/0/0 yandex.ru. [3m59s] A 5.255.255.80, yandex.ru. [3m59s] A 77.88.55.50, yandex.ru. [3m59s] A 5.255.255.60, yandex.ru. [3m59s] A 77.88.55.80 (91)
15:26:18.451231 IP (tos 0x0, ttl 64, id 1389, offset 0, flags [none], proto UDP (17), length 55)
#.#.#.#.54228 > 208.67.222.222.domain: [udp sum ok] 23065+ A? yandex.ru. (27)
15:26:18.498305 IP (tos 0x0, ttl 57, id 6088, offset 0, flags [DF], proto UDP (17), length 119)
208.67.222.222.domain > #.#.#.#.54228: [udp sum ok] 23065 q: A? yandex.ru. 4/0/0 yandex.ru. [3m54s] A 77.88.55.50, yandex.ru. [3m54s] A 5.255.255.60, yandex.ru. [3m54s] A 77.88.55.80, yandex.ru. [3m54s] A 5.255.255.80 (91)
Il semble donc qu'Ubuntu fonctionne bien avec le serveur DNS, en envoyant des requêtes, en obtenant des réponses. Mais de toute façon ne peut pas analyser cette réponse ...
Pour l’instant, je n’ai plus d’idées sur la façon de remettre le système DNS au travail.
Est-ce que tout va bien ou quelque chose ne va pas, et que puis-je faire pour que cela fonctionne?
Mise à jour le 17 octobre:
sortie de route ip:
~$ ip route
default via x.x.x.41 dev enp29s0 metric 10 onlink
10.0.0.0/8 dev enp3s0 proto kernel scope link src 10.0.35.115
x.x.x.40/29 dev enp29s0 proto kernel scope link src x.x.x.42
169.254.0.0/16 dev enp3s0 scope link metric 1000
~$ ip route get 8.8.8.8
8.8.8.8 via x.x.x.41 dev enp29s0 src x.x.x.42
cache
traceroute to Google DNS:
~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 Hops max, 60 byte packets
1 x.x.x.41 (x.x.x.41) 1.413 ms 1.404 ms 1.420 ms
2 89.221.63.15 (89.221.63.15) 3.451 ms 3.473 ms 3.463 ms
3 195.208.208.232 (195.208.208.232) 3.360 ms 2.851 ms 2.843 ms
4 108.170.250.129 (108.170.250.129) 3.582 ms 108.170.250.97 (108.170.250.97) 4.029 ms 108.170.250.33 (108.170.250.33) 3.737 ms
5 108.170.226.91 (108.170.226.91) 3.679 ms 66.249.94.195 (66.249.94.195) 4.103 ms 108.170.227.65 (108.170.227.65) 3.828 ms
6 8.8.8.8 (8.8.8.8) 4.506 ms 3.786 ms 3.979 ms
x.x.x.42 - adresse du serveur.
x.x.x.40 et x.x.x.41 - "x" est identique à l'adresse du serveur.
Enfin, j'ai trouvé le problème: c’était le problème d’iptables. Je ne me rappelais pas où j'avais changé cette règle, mais tous les paquets UDP étaient réglés sur DROP:
iptables -A INPUT -p udp -i $EXT_INTERFACE -j DROP
Paramétrer pour ACCEPTER résoudre le problème:
iptables -A INPUT -p udp -i $EXT_INTERFACE -j ACCEPT
Après avoir effectué un apt update & apt upgrade, mon serveur (Ubuntu 16.04) n'a pas pu résoudre les hôtes également.
Assez ennuyeux car il a cassé la capacité de mon noeud délégué à générer des blocs ...
Quoi qu'il en soit. Je suis tombé sur ce sujet.
Au lieu d'accepter udp via iptables (j'utilise ufw) ...
J'ai utilisé cette commande: Sudo ufw reset pour effacer les règles précédentes.
Puis recréez mes règles. Je n'en ai pas eu beaucoup.
Ensuite, Sudo ufw enable pour redémarrer le pare-feu.
Fonctionne encore :)