web-dev-qa-db-fra.com

La résolution DNS ne fonctionne pas sur le serveur 18.04

J'ai fait des recherches assez approfondies et je n'arrive pas à trouver l'aiguille dans la botte de foin qui résout ce problème.

J'ai un serveur exécutant 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

J'utilise LXC/LXD sur le serveur actuellement avec un seul conteneur qui est en fait une image 16.04. DNS fonctionne très bien à l'intérieur du conteneur. Je crois que cela élimine tout problème de réseau potentiel comme problème.

Dans l'installation 18.04, ce qui suit se produit lors de l'utilisation de nslookup

nslookup google.com
;; connection timed out; no servers could be reached

Cependant, lorsque j'inclus un serveur DNS directement en tant que tel, je reçois une recherche de travail. Encore une fois apparemment exclu les problèmes de pare-feu/réseau

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

Dans le cadre des conseils/astuces/guides suivants, certaines des choses suivantes que j'ai essayées sont ci-dessous, ainsi que diverses sorties qui pourraient être utiles pour aider à résoudre ce problème.

J'ai modifié le fichier suivant pour qu'il ressemble à cela. J'ai seulement ajouté les serveurs de noms. J'ai fait cela en suivant l'un des correctifs.

$ 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]

Cela a semblé ajouter les serveurs DNS à l'appareil

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

Même avec les serveurs DNS répertoriés ici, aucune recherche n'est possible en utilisant Dig ou nslookup.

J'ai installé resolvconf dans le cadre d'un guide, bien que je pense que ce n'était pas nécessaire et que cela s'est avéré plus compliqué.

$ 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

C'est tout ce que je semble pouvoir obtenir. Si j'ajoute des serveurs de noms valides (8.8.8.8, 8.8.4.4, 1.1.1.1, etc.) au fichier /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

Je peux obtenir des recherches comme indiqué ci-dessous. Si bien sûr, comme indiqué dans le fichier, ces modifications sont écrasées au redémarrage.

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

EDIT: sortie de la commande 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

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

Tout le monde connaît le lien/la solution à ce problème. Je suis à perte.

networkingserver18.04dns
7
Dave

TL; DR: autorise le port 53 tcp & udp à l'interface lo.

Même si la politique par défaut sur INPUT est ACCEPT, il existe une règle finale qui supprime tout ce qui n'est pas encore accepté. Les seules règles acceptant le trafic sur le port 53 se trouvent sur l'interface lxdbr0. Vous pouvez autoriser tout sur l'interface lo ou tout simplement autoriser les ports selon vos besoins.

Pour pousser une règle pour autoriser tout sur l'interface lo avant les autres règles:

iptables -I INPUT 1 -i lo -j ACCEPT
6
mjb2kmn

Dans mon cas, passez du 16.04 au 18.04, service mystérieusement désactivé par le système. Fix consistait à le réactiver.

0
zgoda

Après avoir modifié la configuration NetPlan. Courir

Sudo netplan apply

Pour étendre les modifications. Pour évaluer les modifications, exécutez:

Sudo netplan --debug apply

Mise à jour avec plus d'informations.

J'ai cette configuration de fichier: /etc/netplan/01-netcfg.yaml

Les paramètres que vous mettez sont corrects. Pourquoi ne pas essayer:

Sudo mv /etc/netplan/50-cloud-init.yaml /etc/netplan/01-netcfg.yaml

PS: faites une sauvegarde.

0
Carlos Dagorret

Lors de la mise à niveau du 16.04 au 18.04, j'ai eu ce même problème. J'ai essayé ce qui précède ainsi que de nombreuses autres solutions qui tournaient autour de resolv.conf.

Mon vrai coupable: POSTFIX. D'une manière ou d'une autre, le suffixe interférait avec ma configuration DNS. Après avoir supprimé le suffixe avec --auto-remove, comme par magie, le DNS a recommencé à se résoudre.

Je peux maintenant ping et apt-get à nouveau. Quelle belle journée :)

0
Goner

Vous pouvez simplement essayer d'appliquer à nouveau la configuration Netplan. Après une mise à jour sur l'un de mes nœuds docker, j'ai perdu la résolution DNS et j'ai simplement utilisé la commande ci-dessous pour réappliquer la configuration réseau sur le serveur:

Sudo netplan apply

Tout a fonctionné comme prévu après cela.

0
Nikolay Andonov