DNS Resolve не работает на сервере 18.04
Я провел довольно обширный поиск и, похоже, не могу найти иголку в стоге сена, которая решает эту проблему.
У меня есть сервер под управлением Ubuntu 18.04
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic
Я использую LXC/LXD на сервере в настоящее время только с одним контейнером, который на самом деле представляет собой изображение 16.04. DNS отлично работает изнутри контейнера. Я считаю, что это устраняет любую потенциальную проблему сети как проблему.
При установке 18.04 происходит следующее при использовании nslookup
nslookup google.com
;; connection timed out; no servers could be reached
Однако при подключении DNS-сервера непосредственно как таковой я получаю поиск для работы. Снова, казалось бы, исключение проблем с брандмауэром / сетью
nslookup google.com 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: google.com
Address: 172.217.5.238
Name: google.com
Address: 2607:f8b0:4006:802::200e
В качестве части следующих советов / хитростей / руководств ниже приведены некоторые из следующих вещей, которые я пробовал, а также различные выводы, которые могут быть полезны для улучшения этого.
Я изменил следующий файл, чтобы выглядеть так. Я только добавил серверы имен. Я сделал это после одного из исправлений там.
$ cat /etc/netplan/50-cloud-init.yaml
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: <redacted for post>
set-name: ens3
nameservers:
addresses: [8.8.4.4, 8.8.8.8, 1.1.1.1, 1.1.0.0]
Это, кажется, добавить DNS-серверы на устройство
sudo systemd-resolve --status
Global
DNS Domain: openstacklocal
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 5 (vethTR4JCU)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 3 (lxdbr0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 2 (ens3)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 8.8.4.4
8.8.8.8
1.1.1.1
1.1.0.0
<redacted for post>
DNS Domain: openstacklocal
Даже с указанными там DNS-серверами поиск невозможен ни с помощью dig, ни с помощью nslookup.
Я установил resolvconf как часть руководства, хотя я думаю, что это было излишним и просто привело к еще большему беспорядку.
$ ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 29 Jan 29 12:55 /etc/resolv.conf -> ../run/resolvconf/resolv.conf
cat /run/resolvconf/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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
search openstacklocal
Это, насколько я могу судить. Если я добавлю действительные серверы имен (8.8.8.8, 8.8.4.4, 1.1.1.1 и т. Д.) В файл /run/resolveconf/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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
nameserver 8.8.8.8 # manually added in for testing
search openstacklocal
Я могу заставить поиски работать, как показано ниже. Если курс, как указано в файле, эти изменения перезаписываются при перезагрузке.
nslookup google.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 172.217.15.78
Name: google.com
Address: 2607:f8b0:4004:810::200e
РЕДАКТИРОВАТЬ: вывод команды apply
sudo netplan --debug apply
** (generate:15710): DEBUG: 14:11:34.829: Processing input file /etc/netplan/50-cloud-init.yaml..
** (generate:15710): DEBUG: 14:11:34.830: starting new processing pass
** (generate:15710): DEBUG: 14:11:34.878: ens3: setting default backend to 1
** (generate:15710): DEBUG: 14:11:34.879: Generating output files..
** (generate:15710): DEBUG: 14:11:34.879: NetworkManager: definition ens3 is not for us (backend 1)
DEBUG:netplan generated networkd configuration exists, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:ens3 not found in {}
DEBUG:Merged config:
network:
bonds: {}
bridges: {}
ethernets:
ens3:
dhcp4: true
match:
macaddress: <redacted for post>
nameservers:
addresses:
- 8.8.4.4
- 8.8.8.8
- 1.1.1.1
- 1.1.0.0
set-name: ens3
vlans: {}
wifis: {}
DEBUG:Skipping non-physical interface: lo
DEBUG:device ens3 operstate is up, not changing
DEBUG:Skipping non-physical interface: lxdbr0
DEBUG:Skipping non-physical interface: vethTR4JCU
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for ens3
DEBUG:netplan triggering .link rules for lxdbr0
DEBUG:netplan triggering .link rules for vethTR4JCU
РЕДАКТИРОВАТЬ: требуется
sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- lxdbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 /* generated for LXD network lxdbr0 */
0 0 ACCEPT udp -- lxdbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 /* generated for LXD network lxdbr0 */
0 0 ACCEPT udp -- lxdbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 /* generated for LXD network lxdbr0 */
0 0 ACCEPT tcp -- ens3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8443 /* allow connection to lxd */
2336 152K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
1 60 ACCEPT tcp -- lxdbr0 * 10.100.106.40 0.0.0.0/0 tcp dpt:22
1279 73342 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
8207 2604K ACCEPT all -- * lxdbr0 0.0.0.0/0 0.0.0.0/0 /* generated for LXD network lxdbr0 */
9496 3318K ACCEPT all -- lxdbr0 * 0.0.0.0/0 0.0.0.0/0 /* generated for LXD network lxdbr0 */
Chain OUTPUT (policy ACCEPT 70 packets, 8606 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * lxdbr0 0.0.0.0/0 0.0.0.0/0 tcp spt:53 /* generated for LXD network lxdbr0 */
0 0 ACCEPT udp -- * lxdbr0 0.0.0.0/0 0.0.0.0/0 udp spt:53 /* generated for LXD network lxdbr0 */
0 0 ACCEPT udp -- * lxdbr0 0.0.0.0/0 0.0.0.0/0 udp spt:67 /* generated for LXD network lxdbr0 */
Кто-нибудь знает ссылку / решение этой проблемы. Я в недоумении.
2 ответа
TL;DR: разрешить порт 53 tcp & udp для интерфейса lo.
Несмотря на то, что по умолчанию для INPUT используется политика ПРИНЯТЬ, существует последнее правило, которое отбрасывает все, что еще не принято. Единственные правила, принимающие трафик через порт 53, - это интерфейс lxdbr0. Вы могли бы позволить все на lo интерфейс или просто разрешить порты по мере необходимости.
Чтобы выдвинуть правило, разрешающее все на интерфейсе lo, опередить другие правила:
iptables -I INPUT 1 -i lo -j ACCEPT
Откровенно говоря, единственным правильным ответом этой современной суке был:
apt remove ifupdown
apt install cloud-init
# comment out settings in /etc/network/interfaces
# complete settings in /etc/netplan/config.yaml
# Apply settings or reboot
netplan apply
Удаление
ifupdown необходим для правильной работы DNS-преобразователя.
В моем случае обновление с 16.04 до 18.04 таинственным образом отключило службу systemd-resolved. Исправление заключалось в том, чтобы снова включить его.
При обновлении с 16.04 до 18.04 у меня была такая же проблема. Попробовал вышеупомянутое плюс много других решений, которые вращались вокруг resolv.conf.
Мой настоящий виновник: POSTFIX. Почему-то / как-то постфикс мешал моей конфигурации DNS. После удаления postfix с помощью --auto-remove волшебным образом DNS снова начал разрешаться.
Теперь я могу пинговать и снова получать. Какой прекрасный день:)
После того, как вы изменили конфигурацию NetPlan. Бежать
sudo netplan apply
Расширить изменения. Чтобы оценить изменения, выполните:
sudo netplan --debug apply
Обновление с дополнительной информацией.
У меня есть эта конфигурация файла: /etc/netplan/01-netcfg.yaml
Параметры, которые вы указали, верны. Почему бы не попробовать:
sudo mv /etc/netplan/50-cloud-init.yaml /etc/netplan/01-netcfg.yaml
PS: сделайте резервную копию.
Продолжение сообщения Дэйва. У меня возникла эта проблема после установки postfix, и я не хотел удалять postfix.
Я обнаружил, что добавление 8.8.8.8 в resolv.conf, как уже упоминалось, было временным исправлением, но затем я обнаружил, что это даже не нужно.Исправление, которое сработало для меня, хотите верьте, хотите нет, заключалось в добавлении пустой строки перед 127.0.0.53 в resolv.conf.Вы можете просто попробовать снова применить конфигурацию Netplan. После обновления на одном из моих узлов докеров я потерял разрешение DNS и просто использовал приведенную ниже команду, чтобы повторно применить конфигурацию сети на сервере:
sudo netplan apply
После этого все заработало как положено.