Ask Ubuntu Asked by il_mix on November 26, 2021
I’m setting up an Ubuntu Server 20.04 system as a gateway between my LAN and the WAN. I’m not able to configure the DNS properly.
I have 2 netplan config files for my 2 interfaces.
Internal eth interface (LAN)
root@gate:~# cat /etc/netplan/01-eth_int.yaml
# This is the network config written by 'subiquity'
network:
ethernets:
enp4s0:
addresses: ['10.0.10.1/24']
match:
macaddress: 00:60:e0:76:9e:e7
set-name: eth_int
version: 2
External eth interface (WAN)
root@gate:~# cat /etc/netplan/02-eth_ext.yaml
# This is the network config written by 'subiquity'
network:
ethernets:
enp5s0:
addresses: ['10.200.56.254/24']
gateway4: 10.200.56.1
nameservers:
addresses: [195.78.215.228, 195.78.223.228]
addresses: [8.8.8.8, 8.8.4.4]
match:
macaddress: 00:60:e0:76:9e:e8
set-name: eth_ext
version: 2
On reboot the interfaces are configured according to netplan config files. But /etc/resolv.conf is misconfigured
root@gate:~# cat /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 to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# 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 127.0.0.53
options edns0
Test/check performed:
root@gate:~# systemd-resolve --status
Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
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 (eth_ext)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 195.78.215.228
195.78.223.228
8.8.8.8
8.8.4.4
Link 4 (enp0s31f6)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 3 (eth_int)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 2 (enp3s0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Obviously, this mismatch will prevent DNS to work properly
root@gate:~# ping google.com
ping: google.com: Temporary failure in name resolution
root@gate:~# nslookup heise.de 127.0.0.53
;; connection timed out; no servers could be reached
How can I solve this?
You've mentioned, your /etc/resolv.conf is symlink of /run/systemd/resolve/stub-resolv.conf
To resolve this issue:
$ sudo unlink /etc/resolv.conf$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.confsudo systemctl restart systemd-resolved.serviceThe following information from man systemd-resolved:
/ETC/RESOLV.CONF
Four modes of handling /etc/resolv.conf (see resolv.conf(5)) are supported:
• systemd-resolved maintains the /run/systemd/resolve/stub-resolv.conf file for compatibility with
traditional Linux programs. This file may be symlinked from /etc/resolv.conf. This file lists the
127.0.0.53 DNS stub (see above) as the only DNS server. It also contains a list of search domains that are
in use by systemd-resolved. The list of search domains is always kept up-to-date. Note that
/run/systemd/resolve/stub-resolv.conf should not be used directly by applications, but only through a
symlink from /etc/resolv.conf. This file may be symlinked from /etc/resolv.conf in order to connect all
local clients that bypass local DNS APIs to systemd-resolved with correct search domains settings. This
mode of operation is recommended.
• A static file /usr/lib/systemd/resolv.conf is provided that lists the 127.0.0.53 DNS stub (see above) as
only DNS server. This file may be symlinked from /etc/resolv.conf in order to connect all local clients
that bypass local DNS APIs to systemd-resolved. This file does not contain any search domains.
• systemd-resolved maintains the /run/systemd/resolve/resolv.conf file for compatibility with traditional
Linux programs. This file may be symlinked from /etc/resolv.conf and is always kept up-to-date, containing
information about all known DNS servers. Note the file format's limitations: it does not know a concept of
per-interface DNS servers and hence only contains system-wide DNS server definitions. Note that
/run/systemd/resolve/resolv.conf should not be used directly by applications, but only through a symlink
from /etc/resolv.conf. If this mode of operation is used local clients that bypass any local DNS API will
also bypass systemd-resolved and will talk directly to the known DNS servers.
• Alternatively, /etc/resolv.conf may be managed by other packages, in which case systemd-resolved will read
it for DNS configuration data. In this mode of operation systemd-resolved is consumer rather than provider
of this configuration file.
Note that the selected mode of operation for this file is detected fully automatically, depending on whether
/etc/resolv.conf is a symlink to /run/systemd/resolve/resolv.conf or lists 127.0.0.53 as DNS server.
Answered by Gryu on November 26, 2021
I notice you didn't specify dhcp4: false on your lan and didn't assign a nameserver - that may be your problem?
I just recently setup my ubuntu machine as a router and after a lot of struggle I gave up on naming the interfaces and let them as eno1 / enp1s0 in the yaml file (BTW I combined their description in a single file that I named 01-router-all.yaml so that I only have one file to edit when making changes). I think that I faced a race condition with the dhcp server service starting before the network service had named the interfaces as per my .yaml.
Here is my working /etc/netplan/01-router-all.yaml if it helps (I am somewhat cheating and assigning public DNS, as I still need to setup a DNS server on my machine):
network:
version: 2
renderer: networkd
ethernets:
# eno1 = wan1
eno1:
dhcp4: false
addresses: [192.168.1.8/24]
nameservers:
addresses: [9.9.9.9, 1.1.1.1]
search: []
# enp1s0 = lan
enp1s0:
dhcp4: false
addresses: [192.168.9.1/24]
nameservers:
addresses: [9.9.9.9, 1.1.1.1]
search: []
Answered by bobmorane on November 26, 2021
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP