Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Убунту

Не удается настроить разрешение имен на сервере Ubuntu 22.04.

На чтение 7 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Порядок Действий
  4. Заключение

Вопрос или проблема

Я установил Ubuntu 22.04 и настроил интерфейс сервера с IP-адресом и DNS-серверами, которые он должен использовать:

root@m15jumplnxnoc01v:/# cat /etc/netplan/00-installer-config.yaml
network:
  ethernets:
    ens160:
      dhcp4: no
      addresses:
        - 10.248.0.235/24
      routes:
        - to: default
          via: 10.248.0.1
      nameservers:
        addresses:
          - 10.248.0.100
          - 10.248.0.103

  version: 2

После настройки и проверки интерфейса я подтвердил, что могу пинговать 8.8.8.8, но не смог получить разрешение для www.google.com с помощью nslookup.

Так что я добавил DNS-серверы глобально, добавив их в файл /etc/systemd/resolved.conf и перезапустив службу:

[Resolve]
DNS=10.248.0.100 10.248.0.103
FallbackDNS=8.8.8.8
Domains=~.
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no

Это не решило мою проблему, хотя я смог увидеть, что как глобальные, так и интерфейсные DNS-серверы правильно установлены:

root@m15jumplnxnoc01v:/# resolvectl
Global
           Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
  Current DNS Server: 10.248.0.103
         DNS Servers: 10.248.0.100 10.248.0.103
Fallback DNS Servers: 8.8.8.8
          DNS Domain: ~.

Link 2 (ens160)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.248.0.100
       DNS Servers: 10.248.0.100 10.248.0.103

Но я все еще получаю ошибку "тайм-аут" для DNS-серверов:

root@m15jumplnxnoc01v:/# nslookup www.google.com
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; no servers could be reached

Интересно, что соединение действительно работает:

root@m15jumplnxnoc01v:/# nc -uvz 172.0.0.53 53
Connection to 172.0.0.53 53 port [udp/domain] succeeded!

root@m15jumplnxnoc01v:/# nc -uvz 10.248.0.100 53
Connection to 10.248.0.100 53 port [udp/domain] succeeded!

root@m15jumplnxnoc01v:/# nc -uvz 10.248.0.103 53
Connection to 10.248.0.103 53 port [udp/domain] succeeded!

root@m15jumplnxnoc01v:/# nc -uvz 8.8.8.8 53
Connection to 8.8.8.8 53 port [udp/domain] succeeded!

Я сделал tcpdump, и нацелился на трафик UDP/53, и действительно вижу запросы, которые идут к правильным серверам:

root@m15jumplnxnoc01v:/#  tcpdump -nni any udp and port 53
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
17:33:25.372379 lo    In  IP 127.0.0.1.43642 > 127.0.0.53.53: 4933+ [1au] A? detectportal.firefox.com. (53)
17:33:25.372418 lo    In  IP 127.0.0.1.43642 > 127.0.0.53.53: 34751+ [1au] AAAA? detectportal.firefox.com. (53)
17:33:26.008362 lo    In  IP 127.0.0.1.42621 > 127.0.0.53.53: 45529+ [1au] A? ntp.ubuntu.com. (43)
17:33:26.008405 lo    In  IP 127.0.0.1.42621 > 127.0.0.53.53: 32209+ [1au] AAAA? ntp.ubuntu.com. (43)
17:33:30.012481 lo    In  IP 127.0.0.1.38425 > 127.0.0.53.53: 5001+ A? www.google.com. (32)
17:33:30.377639 lo    In  IP 127.0.0.1.45370 > 127.0.0.53.53: 62098+ [1au] A? detectportal.firefox.com. (53)
17:33:30.377837 lo    In  IP 127.0.0.1.45370 > 127.0.0.53.53: 5017+ [1au] AAAA? detectportal.firefox.com. (53)
17:33:31.013169 lo    In  IP 127.0.0.1.39636 > 127.0.0.53.53: 1505+ [1au] A? ntp.ubuntu.com. (43)
17:33:31.013201 lo    In  IP 127.0.0.1.39636 > 127.0.0.53.53: 19416+ [1au] AAAA? ntp.ubuntu.com. (43)
17:33:35.016648 lo    In  IP 127.0.0.1.54656 > 127.0.0.53.53: 5001+ A? www.google.com. (32)
17:33:35.383028 lo    In  IP 127.0.0.1.45370 > 127.0.0.53.53: 62098+ [1au] A? detectportal.firefox.com. (53)
17:33:35.383062 lo    In  IP 127.0.0.1.45370 > 127.0.0.53.53: 5017+ [1au] AAAA? detectportal.firefox.com. (53)
17:33:36.018367 lo    In  IP 127.0.0.1.39636 > 127.0.0.53.53: 1505+ [1au] A? ntp.ubuntu.com. (43)
17:33:36.018411 lo    In  IP 127.0.0.1.39636 > 127.0.0.53.53: 19416+ [1au] AAAA? ntp.ubuntu.com. (43)
17:33:40.022204 lo    In  IP 127.0.0.1.41749 > 127.0.0.53.53: 5001+ A? www.google.com. (32)
17:33:41.020464 lo    In  IP 127.0.0.1.48022 > 127.0.0.53.53: 27022+ [1au] A? ntp.ubuntu.com. (43)
17:33:41.020506 lo    In  IP 127.0.0.1.48022 > 127.0.0.53.53: 51079+ [1au] AAAA? ntp.ubuntu.com. (43)
17:33:46.025666 lo    In  IP 127.0.0.1.48022 > 127.0.0.53.53: 27022+ [1au] A? ntp.ubuntu.com. (43)
17:33:46.025709 lo    In  IP 127.0.0.1.48022 > 127.0.0.53.53: 51079+ [1au] AAAA? ntp.ubuntu.com. (43)
17:33:46.026381 ens160 Out IP 10.248.0.235.34103 > 10.248.0.100.53: 35474+ A? detectportal.firefox.com. (42)
17:33:46.026533 ens160 Out IP 10.248.0.235.33402 > 10.248.0.100.53: 40994+ A? ntp.ubuntu.com. (32)
17:33:46.026700 ens160 Out IP 10.248.0.235.60090 > 10.248.0.100.53: 36947+ AAAA? ntp.ubuntu.com. (32)
17:33:46.026813 ens160 Out IP 10.248.0.235.33960 > 10.248.0.100.53: 10092+ A? www.google.com. (32)
17:33:46.026930 ens160 Out IP 10.248.0.235.39671 > 10.248.0.100.53: 26888+ AAAA? detectportal.firefox.com. (42)
17:33:51.028884 lo    In  IP 127.0.0.1.39871 > 127.0.0.53.53: 58427+ [1au] A? ntp.ubuntu.com. (43)
17:33:51.028924 lo    In  IP 127.0.0.1.39871 > 127.0.0.53.53: 14641+ [1au] AAAA? ntp.ubuntu.com. (43)
17:33:51.029477 ens160 Out IP 10.248.0.235.42022 > 10.248.0.103.53: 26888+ AAAA? detectportal.firefox.com. (42)
17:33:51.029655 ens160 Out IP 10.248.0.235.34400 > 10.248.0.103.53: 10092+ A? www.google.com. (32)
17:33:51.029776 ens160 Out IP 10.248.0.235.38663 > 10.248.0.103.53: 36947+ AAAA? ntp.ubuntu.com. (32)
17:33:51.029894 ens160 Out IP 10.248.0.235.58453 > 10.248.0.103.53: 40994+ A? ntp.ubuntu.com. (32)
17:33:51.030040 ens160 Out IP 10.248.0.235.51256 > 10.248.0.103.53: 35474+ A? detectportal.firefox.com. (42)
17:33:56.032396 lo    In  IP 127.0.0.1.39871 > 127.0.0.53.53: 58427+ [1au] A? ntp.ubuntu.com. (43)
17:33:56.032440 lo    In  IP 127.0.0.1.39871 > 127.0.0.53.53: 14641+ [1au] AAAA? ntp.ubuntu.com. (43)
17:34:00.365067 lo    In  IP 127.0.0.1.44129 > 127.0.0.53.53: 8050+ [1au] A? detectportal.firefox.com. (53)
17:34:00.365104 lo    In  IP 127.0.0.1.44129 > 127.0.0.53.53: 4987+ [1au] AAAA? detectportal.firefox.com. (53)
17:34:01.036519 lo    In  IP 127.0.0.1.34244 > 127.0.0.53.53: 36036+ [1au] A? ntp.ubuntu.com. (43)
17:34:01.036568 lo    In  IP 127.0.0.1.34244 > 127.0.0.53.53: 59855+ [1au] AAAA? ntp.ubuntu.com. (43)
^C
37 пакетов захвачено
64 пакета получено фильтром
0 пакетов отброшено ядром

Я даже пытался изменить службу DNS на resolvconf и редактировал конфигурационный файл /etc/resolvconf/resolv.conf.d/head, чтобы добавить туда DNS-серверы, а также использовать dnsmasq и добавлял DNS-сервисы в /etc/resolv.conf (что используется dnsmasq).

Неважно, какую службу я пробую или как я ее настраиваю, она все время выдает тайм-ауты, но соединение определенно работает, как показано выше.

Есть идеи, что еще я могу проверить?

Заранее спасибо!

Спасибо всем за ваши комментарии и предложения.

Проблема была разрешена, DNS-серверы, на которые я указывал, 10.248.0.100 и 10.248.0.103, были созданы, но не полностью готовы. Мне предоставили другой набор DNS-серверов 10.248.1.100 и 10.248.1.103, и использование их решило проблему.

Все еще интересно, почему это не работало с 8.8.8.8…

Спасибо!

Ответ или решение

Установка серверной версии Ubuntu 22.04 может быть сложной задачей, особенно когда возникает проблема с разрешением имен. В данной ситуации, несмотря на корректную настройку сетевого интерфейса, с DNS-серверами наблюдаются проблемы, которые проявляются в виде тайм-аутов. Давайте внимательно разберёмся в этой ситуации и рассмотрим основные шаги, которые могли бы помочь в её решении.

Порядок Действий

  1. Проверка Конфигурации Сети
    Вы правильно настроили сетевой интерфейс в файле /etc/netplan/00-installer-config.yaml. Убедитесь, что маршруты и DNS-серверы указаны верно. После внесения изменений обязательно примените их командой:

    sudo netplan apply

  2. Проверка DNS с помощью systemd-resolved
    Использование systemd-resolved в Ubuntu 22.04 предполагает, что DNS-запросы обрабатываются через локальный стуб DNS, который по умолчанию слушает на 127.0.0.53. Ваши проверки с использованием resolvectl показали, что конфигурация правильная, и вы видите активные DNS-серверы.

  3. Тестирование На Уровне Сети
    Совершенно верно, что вы можете пинговать IP-адреса, включая 8.8.8.8, что подтверждает наличие сетевого соединения. Однако nslookup указывает на тайм-аут при попытке разрешения имени. Следует проверить, действительно ли пакет DNS уходит от вашего сервера.

  4. Анализ Трафика с помощью tcpdump
    Вы правильно использовали tcpdump, и это помогает убедиться, что запросы на 53 порт действительно отправляются. Однако важно также удостовериться, что ответы от DNS-серверов приходят. Возможно, что либо серверы зависли, что и привело к проблемы с разрешением.

  5. Проверка Состояния DNS-серверов
    Наиболее распространенной причиной тайм-аутов при разрешении имен является недоступность указанных DNS-серверов. Вы обнаружили, что ваши DNS-серверы 10.248.0.100 и 10.248.0.103 оказались в процессе настройки и не были полностью готовы. Это типичная ситуация в средах с динамической конфигурацией серверов, где существующие записи могут временно не работать.

  6. Использование Альтернативных DNS-серверов
    Ваша идея использовать запасные DNS-серверы 10.248.1.100 и 10.248.1.103 оказалась успешной. Это яркий пример того, как быстрое переключение на резервные ресурсы может решить проблему в любой сетевой архитектуре.

Заключение

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

Если вы столкнётесь с подобной проблемой вновь, запомните все вышеперечисленные шаги и поддерживайте фундаментальные принципы по обеспечению надежной сетевой инфраструктуры.

dns networking server
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности