Назад | Перейти на главную страницу

Невозможно ssh или ping имя хоста, но dig и nslookup работают в Ubuntu 18.04

В эти выходные я обновил ядро ​​и теперь использую 5.3.1.

christopher@HAL4:~$ uname -r
5.3.1-050301-generic

Мне нужно войти на серверы, но я больше не могу делать это по имени хоста. Например, у меня есть сервер «web4», и его локальный IP-адрес 192.168.64.140. Если я запустил копать:

christopher@HAL4:~$ dig web4

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> web4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1580
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;web4.              IN  A

;; ANSWER SECTION:
web4.           0   IN  A   192.168.64.140

;; Query time: 0 msec
;; SERVER: 192.168.3.222#53(192.168.3.222) <---- Correct! 
;; WHEN: Mon Sep 30 09:50:31 CDT 2019
;; MSG SIZE  rcvd: 49

То же самое и с nslookup:

christopher@HAL4:~$ nslookup web4
Server:     192.168.3.222
Address:    192.168.3.222#53

Name:   web4
Address: 192.168.64.140

Однако ни ping, ни ssh не работают ('login' - это сценарий bash, который использует мой ключ):

christopher@HAL4:~$ ping web4
ping: web4: Name or service not known
christopher@HAL4:~$ login web4
ssh: Could not resolve hostname web4: Name or service not known 

Мой /etc/resolv.conf:

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#


# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 192.168.3.222
nameserver 192.168.70.80

Это символическая ссылка на /run/systemd/resolve/resolv.conf.

Вот мой файл /etc/netplan/01-network-manager-all.yaml:

christopher@HAL4:~$ cat /etc/netplan/01-network-manager-all.yaml 
# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager
  ethernets:
          enp4s0:
                  dhcp4: no
                  addresses: [192.168.2.47/19]
                  gateway4: 192.168.1.1
                  nameservers:
                          addresses: [192.168.3.222,192.168.70.80]

Что случилось с моим DNS ?!

Проверьте /etc/nsswitch.conf

ищи строку, которая начинается hosts и убедитесь, что это dns в теме.

hosts: files dns

Обновление - как вы говорите в комментариях, в вашем nsswitch.conf есть:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

Это означает, что разрешение хостов сначала будет смотреть в / etc / hosts, а затем использовать mdns4_minimal, что означает, что вы используете службу демона avahi, возможно, она не работает? Если не удается разрешить с помощью mdns, разрешение хоста не удастся - обычно это сделано намеренно, чтобы гарантировать, что разрешение обязательно будет использовать avahi, факт, что вы получили resolve [!UNAVAIL=return] после этого, означает, что преобразователь systemd тоже может быть настроен ... [!UNAVAILBLE=return] означает, что systemd-resolved всегда будет использоваться, если он запущен, но продолжит использовать nss-dns, если нет. Итак, определите, как вы хотите разрешать имена в адреса, если вы не используете mdns, вы можете удалить mdns4_minimal [NOTFOUND=return] так что это может быть лучше для вас:

hosts: files resolve [!UNAVAIL=return] dns myhostname

или даже:

hosts: files dns myhostname

ping проходит системное разрешение, тем временем с dig вы отправляете запросы напрямую. Вот почему бывают разные исходы.

Что касается того, как это решить - не использовать отдельную зону для хостов - это не лучшая (и даже не хорошая) практика. Скажем, служба mDNS (Multicast DNS), поставляемая с Ubuntu 18.04, ожидает .local быть зоной по умолчанию, если это явно не указано.

Если вам не нужен mDNS в вашей системе, конечно, вы можете просто настроить /etc/nsswitch.conf соответственно. Но в целом (прочтите «следующие передовые практики») у вас должна быть отдельная зона DNS для вашей локальной сети, которую вы можете настроить по умолчанию, даже если вы не укажете ее имя.