it-swarm.com.de

Ubuntu 16.04 Hostnamen können nicht aufgelöst werden

Ich habe ein seltsames Problem beim Auflösen von Hostnamen unter Ubuntu 16.04. Ich suche nach einer Lösung ab Freitag (4 Tage!), Daher denke ich, dass es sich bei ähnlichen Fragen nicht um eine Wiederholung handelt.

Ich habe einen Server im lokalen Netzwerk mit zwei Schnittstellen: extern (zum Internet) und intern (zum lokalen Netzwerk). Beide sind statisch konfiguriert. Ich zeige die Konfiguration unten.

Seit der Installation im März hat es einwandfrei funktioniert. Mehrmals habe ich erfolgreich ein 'passendes Update' ohne Probleme durchgeführt. Am Freitag habe ich versucht, es erneut zu aktualisieren, und hier beginnt die Hauptgeschichte ...

passendes 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.

Bei früheren Updates gab es keine derartigen Probleme beim Auflösen von Hostnamen. Der Server wird hauptsächlich im lokalen Netzwerk nach IP-Adresse verwendet, daher weiß ich nicht, wann dieses Problem auftritt. Also hier sind einige Befehle, die ich ausgeführt habe (externe IP-Adresse durch # ersetzt):

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

Aber nmcli hat kein DNS konfiguriert: nmcli

~$ nmcli dev show | grep 'DNS'

~$ nmcli dev show | grep 'IP4'
IP4.ADDRESS[1]:                         #.#.#.#/29
IP4.GATEWAY:                            #.#.#.#

Was ich getan habe:

  • mehrmals neu gestartet Server.

  • mehrmals neu gestartet systemd gelöst, NetworkManager.

  • kommentar und Kommentar "dns = dnsmasq" in /etc/NetworkManager/NetworkManager.conf (mit Neustart von Dienst und Server).

  • tipps zum Ausschalten von DNSSEC gefunden, aber wie ich festgestellt habe, ist es bereits ausgeschaltet.

  • statische Datei /etc/resolv.conf erstellt (kein symbolischer Link), zurück zum symbolischen Link - alles mit Neustart.

Nichts davon hilft ...

Heute 16 Okt

Heute habe ich 'apt update' und 'apt upgrade' mit einem Trick gemacht: Die Domainnamen in /etc/apt/source.list wurden in ihre IP-Adressen geändert. Also System aktualisiert und 16.04.3 werden. Es hilft nicht.

/ etc/nsswitch.conf

Entfernen Sie einige Einstellungen für "Hosts" und lassen Sie minimale Werte.

~$ 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 auf benutzerdefiniertem DNS-Server

Dieses Ding macht mich schließlich verrückt. Ich führe nslookup auf einem benutzerdefinierten DNS-Server aus ...

~$ nslookup yandex.ru 208.67.222.222
;; connection timed out; no servers could be reached

tcpdump on 53 port

... check tcpdump - es wurden zu viele Datensätze mit "bad udp cksum" angezeigt ...

~# 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

... ethtool ausführen, um solche Einträge zu vermeiden ...

~$ 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]

... und überprüfe tcpdump erneut:

~# 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)

Es scheint also, dass Ubuntu gut mit DNS-Servern zusammenarbeitet, die Anfragen senden und Antworten erhalten. Aber irgendwie kann ich diese Antwort nicht analysieren ...

Im Moment habe ich keine Ideen mehr, wie ich die DNS-Auflösung wieder zum Laufen bringen kann.

Habe ich alles richtig gemacht oder war etwas nicht und was kann ich noch tun, damit es funktioniert?

Aktualisierung am 17. Oktober:

iP Route Ausgabe:

~$ 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 zu 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 - Serveradresse.

x.x.x.40 und x.x.x.41 - "x" entspricht der Serveradresse.

2
zhoriq

Endlich habe ich die Problemstelle gefunden: Es handelte sich um ein Iptables-Problem. Ich konnte mich nicht erinnern, wo ich diese Regel geändert habe, aber alle UDP-Pakete wurden auf DROP gesetzt:

iptables -A INPUT -p udp -i $EXT_INTERFACE -j DROP

Einstellung zum Akzeptieren des Problems:

iptables -A INPUT -p udp -i $EXT_INTERFACE -j ACCEPT
2
zhoriq

Nach einem apt update & apt upgrade konnte mein Server (Ubuntu 16.04) auch keine Hosts auflösen.

Sehr ärgerlich, da die Fähigkeit meines Stellvertreterknotens, Blöcke zu generieren, unterbrochen wurde ...

Sowieso. Ich bin auf dieses Thema gestoßen.

Anstatt udp über iptables zu akzeptieren (ich benutze ufw) ...

Ich habe diesen Befehl verwendet: Sudo ufw reset, um vorherige Regeln zu löschen.

Dann erstelle meine Regeln neu. Ich hatte nicht so viele.

Dann Sudo ufw enable, um die Firewall neu zu starten.

Geht wieder :)

0
MSwezey