Вопросы Теги

Твердость DNS не работает над 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, перечисленными там, никакие поиски не являются возможным использованием или роют, или 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

Править: вывод применяет команду

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

Править: Requsted

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 */

Любой знает ссылку/решение на эту проблему. Я в замешательстве.

6
задан 29 January 2019 в 13:30

7 ответов

TL; DR: позвольте порту 53 tcp и udp к интерфейсу lo.

Даже при том, что политика по умолчанию в отношении ВХОДА, ПРИНИМАЮТ, существует заключительное правило, которое отбрасывает что-либо еще принятое. Единственные правила, принимающие трафик в порте 53, находятся в интерфейсе lxdbr0. Вы могли покрыть, позволяют все на lo соедините интерфейсом или просто позвольте порты по мере необходимости.

Для продвижения правила позволить все на lo взаимодействуют через интерфейс перед другими правилами:

iptables -I INPUT 1 -i lo -j ACCEPT
5
ответ дан 23 November 2019 в 07:53

После изменения на конфигурацию 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: сделайте резервное копирование.

0
ответ дан 23 November 2019 в 07:53

При обновлении от 16,04 до 18,04 у меня была эта та же проблема. Испытанное вышеупомянутое плюс много других решений, которые вращались вокруг resolv.conf.

Мой истинный преступник: ПОСТФИКС. Так или иначе/некоторым образом постфикс вмешивался в мою конфигурацию DNS. После удаления постфикса с - автоудаляют, волшебно DNS начал решать снова.

Я могу теперь проверить с помощью ping-запросов, и склонный - добираются снова. Какой прекрасный день :)

0
ответ дан 23 November 2019 в 07:53

В моем обновлении случая от 16,04 до 18,04 загадочно отключил systemd-разрешенный сервис. Фиксация была вопросом включения его снова.

0
ответ дан 23 November 2019 в 07:53

Вы можете просто попробовать применить конфигурацию Netplan еще раз. После обновления на одном из моих докер-узлов я потерял разрешение DNS и просто использовал приведенную ниже команду, чтобы повторно применить конфигурацию сети на сервере:

sudo netplan apply

После этого все заработало, как и ожидалось.

0
ответ дан 22 December 2019 в 22:07

Дополнение к сообщению Дэйва. У меня возникла эта проблема после установки постфикса, и я не хотел удалять постфикс.

Я обнаружил, что добавление 8.8.8.8 в resolv.conf, как уже упоминалось, было временным решением, но потом я обнаружил, что в этом даже нет необходимости. Исправление, которое помогло мне, хотите верьте, хотите нет, заключалось в простом добавлении пустой строки перед 127.0.0.53 в resolv.conf.
0
ответ дан 13 April 2020 в 11:15

Честно говоря, единственным правильным ответом на этот современный б***** был:

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.

3
ответ дан 1 July 2020 в 14:02

Другие вопросы по тегам:

Похожие вопросы: