“Временная ошибка в разрешении имени (DNS)”

Сведения:

Я работаю в области безопасности здравоохранения с приблизительно 125 серверами для десятка клиентов в США. Устройства включают как физические машины, так и ВМ, 1U серверы и маломощные устройства. Хотя изначально мы работали на Ubuntu 16.04, в прошлом году мы перешли на Ubuntu 20.04.

Эти машины запускают популярную open source SIEM. Они работают с интерфейсом управления на одном сетевом интерфейсе/адаптере и зеркалом порта на втором сетевом интерфейсе/адаптере.

Одним из самых больших изменений в этом переходе было то, как изменилась настройка сети: от использования файлов интерфейсов в /etc/network к использованию файлов YAML с Netplan. Поскольку мы небольшая компания, только я занимаюсь обслуживанием серверов. Как уже упоминалось, они расположены на разных сайтах по всей территории США, поэтому у меня нет физического доступа к более чем 80% этих серверов из-за их географического положения. Я выполняю любое обслуживание и обновления через Microsoft Azure или через DWS, клиент RDS. За последние четыре года все проходило относительно гладко. Однако недавно я стал замечать, что та же проблема возникает на нескольких сайтах. Нет общих характеристик у затронутых машин: некоторые были собраны в течение последних 30 дней, другие работали без проблем в течение более года или двух без предыдущих проблем.

Проблема:

В последнее время многие машины теряют сетевое соединение. Некоторые работали более года без каких-либо проблем. Они не могут отправлять ping на внешние IP-адреса и возвращают ошибку “Временная ошибка в разрешении имени”. Я изучил десятки сообщений, которые обсуждают, что, похоже, является довольно распространенной проблемой, и пытался внедрить общие решения. Никакое из них не сработало. Я записал эти разные решения и их результаты, а также другую информацию, которая, как мне кажется, может быть полезной, ниже, в надежде, что кто-то сможет посоветовать мне, как исправить эту ошибку.

NET/NET:

ping 8.8.8.8 работает без проблем

ping www.google.com возвращает “временная ошибка в разрешении имени”

Я МОГУ отправлять ping на шлюз и локальные ресурсы

Ifconfig

enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.171.18.6  netmask 255.255.255.0  broadcast 10.171.18.255
        inet6 fe80::201:2eff:fea3:a56e  prefixlen 64  scopeid 0x20<link>
        ether 00:01:2e:a3:a5:6e  txqueuelen 1000  (Ethernet)
        RX packets 1040415  bytes 77072784 (77.0 MB)
        RX errors 0  dropped 36599  overruns 0  frame 0
        TX packets 1929257  bytes 81061339 (81.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.171.255.1  netmask 255.255.255.0  broadcast 10.171.255.255
        inet6 fe80::201:2eff:fea3:a56f  prefixlen 64  scopeid 0x20<link>
        ether 00:01:2e:a3:a5:6f  txqueuelen 1000  (Ethernet)
        RX packets 4184943678  bytes 2571645450748 (2.5 TB)
        RX errors 0  dropped 17  overruns 0  frame 0
        TX packets 604  bytes 52418 (52.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

• Все адаптеры работают
• Все адаптеры отображают правильный IPv4 адрес и маску сети, соответствующие файлу netplan YAML (см. ниже)
• Здесь все выглядит нормально. Полученный/переданный трафик на первом адаптере (enp1s0) соответствует ожиданиям, полученный трафик на enp2s0, зеркале порта, также соответствует ожиданиям.

/etc/netplan

drwxr-xr-x   2 root root  4096 Jul  7 11:48 .
drwxr-xr-x 146 root root 12288 Jun 29 13:44 ..
-rw-r--r--   1 root root   330 May 19 17:47 01-static-ip.yaml

• Присутствует только один файл, файл конфигурации 01-static-ip.yaml
• На данный момент у него права chmod 644

network:
   version: 2
   renderer: NetworkManager
   ethernets:
      enp1s0:
         dhcp4: нет
         addresses:
            - 10.171.18.6/24
         nameservers:
            addresses: [10.30.3.29, 10.30.3.30]
         gateway4: 10.171.0.1
      enp2s0:
         dhcp4: нет
         addresses:
            - 10.171.255.1/24

• Это содержимое 01-static-ip.yaml
• IP-адреса для обоих сетевых адаптеров отображаются правильно в IFCONFIG (выше), как и маска подсети (/24 / 255.255.255.0) для адаптера управления

/etc/network

drwxr-xr-x   6 root root  4096 Jul  7 11:48 .
drwxr-xr-x 146 root root 12288 Jun 29 13:44 ..
drwxr-xr-x   2 root root  4096 May 19 14:56 if-down.d
drwxr-xr-x   2 root root  4096 May 19 14:56 if-post-down.d
drwxr-xr-x   2 root root  4096 May 19 14:56 if-pre-up.d
drwxr-xr-x   2 root root  4096 May 19 14:56 if-up.d
-rwxr-xr-x   1 root root     0 Jul 13 09:34 interfaces

• Я пробовал sudo touch interfaces для создания пустого файла interfaces и пробовал это без наличия файла interfaces вообще
• Я знаю, что технически вы все еще можете использовать файл interfaces для настройки сети в Ubuntu 20.04, но Netplan является предпочтительным / рекомендуемым способом конфигурации сети с Ubuntu 18.04. По этой причине я НЕ пробовал создавать старый файл interfaces здесь и удалять файл YAML netplan

/etc/resolv.conf

nameserver 127.0.0.53
options edns0 trust-ad

• Я пробовал добавить nameserver 10.30.3.29 перед nameserver 127.0.0.53
• Я пробовал удалить nameserver 127.0.0.53 и оставить только nameserver 10.30.3.29
• Ничто из этого не сработало

resolvectl status

Link 2 (enp1s0)
      Current Scopes: DNS       
DefaultRoute setting: yes       
       LLMNR setting: yes       
MulticastDNS setting: no        
  DNSOverTLS setting: no        
      DNSSEC setting: no        
    DNSSEC supported: no        
  Current DNS Server: 10.30.3.29
         DNS Servers: 10.30.3.29
                      10.30.3.30
          DNS Domain: ~.    

• Похоже, что DNS-серверы здесь настроены правильно…

/etc/systemd/resolved.conf

[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#DNSOverTLS=no
#Cache=no-negative
#DNSStubListener=yes
#ReadEtcHosts=yes         

• Самое распространенное решение, похоже, заключается в том, чтобы раскомментировать первую строку здесь и добавить свой DNS nameserver – это не решило ситуацию.

nmcli -f ipv4.addresses,ipv4.dns,ipv4.gateway,IP4.ADDRESS,IP4.DNS,IP4.GATEWAY con show netplan-enp1s0

[NMCLI con show SPECIFIC]
ipv4.addresses:                         10.171.18.6/24
ipv4.dns:                               10.30.3.29,10.30.3.30
ipv4.gateway:                           10.171.0.1
IP4.ADDRESS[1]:                         10.171.18.6/24
IP4.DNS[1]:                             10.30.3.29
IP4.DNS[2]:                             10.30.3.30
IP4.GATEWAY:                            10.171.0.1

• Снова подтверждаю, что вся сетевую информацию на месте

/usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:gsm,except:type:cdma,except:type:ethernet

• У меня были проблемы в прошлом, когда мне нужно было вручную отредактировать этот файл, чтобы включить “except:type:ethernet”, но это уже сделано

systemctl status NetworkManager

<warn>  [1657208914.3825] ifupdown: интерфейсный файл /etc/network/interfaces не существует

• Это было сгенерировано, когда нет файла interfaces в /etc/network
• Как уже упоминалось ранее, я пробовал это и с файлом, и без него
• После создания пустого файла interfaces и перезагрузки NetworkManager проблема исчезла

<warn>  [1657208914.4014] Ошибка: не удалось открыть /run/network/ifstate

• Я видел эту ошибку ранее. Обычно она решается редактированием 10-globally-managed-devices.conf

<warn>  [1657208914.3941] устройство (enp1s0): подключение: "/proc/sys/net/ipv4/conf/enp1s0/rp_filter" установлено в "1". Это может нарушить проверку подключения для IPv4 на этом устройстве

• Я также видел эту ошибку ранее и пробовал редактировать это значение на 0. Ранее это помогало; здесь же не было результатов.

Спасибо заранее за ваше время и мысли. Я готов предоставить любую дополнительную информацию, которую вы захотите увидеть!

Разница между Ubuntu 16.04 и Ubuntu 20.04 заключается в использовании локального резолвера по умолчанию – systemd-resolved. Однако, в процессе обслуживания вы отметили, что пытались отключить этот резолвер в вашем конфигурационном файле resolve.conf, оставив только сервер 10.x.x.x. Это указывает на то, что проблема связана с подключением к вашему DNS-серверу, а не с самим systemd-resolved. Если возможно, следует протестировать с системой Ubuntu 16.04, чтобы исключить, связано ли это действительно с обновлением клиентской ОС или же что-то другое произошло одновременно, что привело к этим временным сбоям.

Инструмент tcpdump может быть полезен для захвата сетевых трассировок DNS-трафика, чтобы увидеть, что происходит на уровне протоколов: tcpdump -i enp1s0 -n -s 1500 port 53. Если вы используете опцию -w, чтобы записать этот вывод в файл pcap, вы можете дополнительно проанализировать с помощью инструмента, такого как ethereal.