Проблема с разрешением доменных имен на 16.04

[shniperson]

Добрый день.
У меня очень странная проблема с разрешением доменных имен на Убунте 16.04.
Бьюсь над проблемой с пятницы, и до сих пор не нашел решения...

Есть сервер в локальной сети с двумя интерфейсами: внутренний и наружный. Оба со статическими адресами (чуть ниже будет конфигурация). Внешний интерфейс без прокси - то есть там реальный внешний ip адрес.

С марта все работало нормально, периодически обновлялось. В пятницу я решил снова обновить его (последний раз обновление было пару месяцев назад где-то), и вот тут началось...

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.

При предыдущих обновлениях такого не было, соответственно баг возник при последнем обновлении, как мне кажется. И тем более, что сервер используется в основном с ip-адресами, поэтому точно отследить эту ошибку по времени не представляется возможным.

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.

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)

/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

При этом nmcli не показывает, что DNS настроен.
nmcli

Код: [Выделить]

~$ nmcli dev show | grep 'DNS'

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

Что я делал:

• рестарты systemd-resolved, NetworkManager
• рестарты сервера
• играл с настройками "dns=dnsmasq" в /etc/NetworkManager/NetworkManager.conf
• играл с настройкой DNSSEC
• делал /etc/resolv.conf статическим файлом, а не символической ссылкой, возвращал символическую ссылку

Ничего не помогло.

Сегодня, Пнд 16 Окт

Сегодня смог обновить систему до 16.04.3 - в /etc/apt/source.list заменил доменные имена на их ip-адреса. Не помогло (сервер перезагружал).

/etc/nsswitch.conf
Удалил "лишнее" для строки hosts, и оставил самый минимум.

Код: [Выделить]

~$ 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 на другой сервер
И, наконец, то, что я вообще никак не могу понять. Сделал запрос на OpenDNS сервер...

Код: [Выделить]

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

...снял tcpdump - показывал много записей "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 выключил создание контрольных сумм...</p>

Код: [Выделить]

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

...и проверил 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)

То есть получается, что система вполне себе нормально отрабатывает - посылает запрос, получает ответ. Но почему-то не может разобрать этот ответ что ли...
И теперь мои мысли закончились.

Все ли выполнено правильно? Или чего-то не хватает?
Куда еще посмотреть, какие настройки?

[Azure]

Apt для работы через прокси требует персональной дополнительной настройки. См help.ubuntu.ru/wiki/прокси

[shniperson]

М, прошу прощения, забыть указать - сервер смотрит напрямую в интернет, без прокси и прочего. То есть там реальный внешний ip адрес.

[Aceler]

У тебя провайдер не блочит случаем DNS-запросы, чтобы ты пользовался только провайдерским DNS? Попробуй выставить провайдерские DNS и если они работают, увы.

[Azure]

netmask 255.255.255.248

Что это за сеть из 6 машин?

Пользователь добавил сообщение 16 Октября 2017, 18:42:26:Покажите

Код: [Выделить]

ip r

[shniperson]

У тебя провайдер не блочит случаем DNS-запросы, чтобы ты пользовался только провайдерским DNS? Попробуй выставить провайдерские DNS и если они работают, увы.

Нет, провайдет не блокирует. Другой сервер (на Windows) нормально работает с Гугловскими ДНС-серверами.

Что это за сеть из 6 машин?

Без понятия сетевые настройки давал администратор. Но такая же маска "на другом сервере на Windows"

ip r

Код: [Выделить]

~$ ip r
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

x.x.x.42 - адрес сервера, x.x.x.40 и x.x.x.41 - соответственно первые три числа те же самые, что и в адресе сервера.

[Azure]

сервер смотрит напрямую в интернет, без прокси и прочего

Хочу Вас огорчить, но

default via x.x.x.41 dev enp29s0  metric 10 onlink

говорит о том что «с интернетом» Ваш сервер общается не «напрямую», а через x.x.x.41. А что это: proxy, vpn, NAT и пр., а также его особенности узнавайте у

настройки давал администратор

[shniperson]

говорит о том что «с интернетом» Ваш сервер общается не «напрямую», а через x.x.x.41.

не совсем понимаю - это плохо?
снаружи сервер отвечает именно по адресу .42 - на нем крутится несколько сервисов.

кроме того, ведь telnet и tcpdump говорят о том, что 53 порт открыт (на сервере и у провайдера), не блокируется, пакеты ходят туда-сюда нормально?!

[Azure]

это плохо?

Это не хорошо и не плохо. Это факт. А факт говорит о том, что между Вашим сервером и «интернетом» существует «промежуточная станция» и её наличие надо учитывать. Например, проблемы с обновлением и пр. могут иметь происхождение в этом дополнительном «звене»

[shniperson]

Какое-то колдовство.
Оказалось, что в iptables стояло правило DROP для всех входящих UDP пакетов. И оно было выше правил по 53 порту, и поэтому ответ от DNS сервера блокировался на уровне iptables...
Видимо когда я проверял правила - пропустил его.

[AnrDaemon]

Видимо, поэтому вас просят показывать iptables-save ?