Не может преобразовать '/etc/network/interfaces' 'конфигурация маршрутизатора в' netplan ', помогите?

У меня есть маломощная двухъядерная машина Celeron, под управлением Ubuntu 19.04, действуя как мой маршрутизатор. Это также работает lxd виртуальная машина с PiHole для DNS.

Это все работает хорошо и было в течение нескольких месяцев. Ubuntu 19.10 теперь отсутствует, хотя, и я обнаружил на другой машине, что конфигурация, которую я использовал, который имеет сетевой мост, необходимый для lxd настроенный в /etc/network/interfaces, больше работы в 19,10. Я успешно переместил другую машину с подобной конфигурацией моста в NetPlan, но я, может казаться, не выясняю, как сделать так для маршрутизатора. Я надеюсь, что кто-то здесь мог бы показать мне, где я иду не так, как надо.

Вот оригинал и рабочий в настоящее время /etc/network/interfaces файл:

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

# The WAN interface.
auto ethwan
iface ethwan inet dhcp
        dns-nameservers 208.67.222.222 208.67.220.220

# The (old) LAN interface.
iface eth0 inet manual

# The new LAN interface, on the new USB-to-Ethernet connection.
iface ethlan inet manual

# The *new* LAN interface.
auto br0
iface br0 inet static
        address 192.168.1.1
        netmask 255.255.255.0
        dns-nameservers 208.67.222.222 208.67.220.220
        bridge-ifaces ethlan
        bridge-ports ethlan
        up ifconfig ethlan up

Вот то, для чего я пытался использовать /etc/netplan/01-network-manager-all.yaml, после комментирования всех кроме двух lo строки выше:

# Let NetworkManager manage all devices on this system
network:
  version: 2
  #renderer: NetworkManager
  renderer: networkd

  ethernets:
    # eth0 isn't used, as the hardware isn't reliable
    eth0:
      match:
        macaddress: f4:4d:30:67:0a:6c
      dhcp4: yes
      dhcp6: yes
      set-name: eth0

    ethlan:
      match:
        macaddress: 00:e0:4c:6a:03:3f
      set-name: ethlan
      dhcp4: no
      dhcp6: no

    ethwan:
      match:
        macaddress: 78:32:1b:a8:cc:1c
      dhcp4: yes
      dhcp6: yes
      set-name: ethwan

  bridges:
    br0:
      interfaces: [ethlan]
      dhcp4: no
      dhcp6: no
      addresses: [192.168.1.1/24]
      #gateway4: 192.168.1.1
      #nameservers:
      #  addresses:
      #  - 192.168.1.11

Сервер имен предоставляется через dnsmasq.

С этой установкой машина маршрутизатора может получить доступ к Интернету без проблем - но lxd виртуальная машина не может получить доступ к большинству сайтов вообще (когда я работаю sudo apt update на нем он говорит, что это совершает нападки http://security.ubuntu.com/ubuntu, но, может казаться, не достигает http://archive.ubuntu.com/ubuntu), и машины в другом месте в сети имеют подобные проблемы (я не могу добраться до Google или DuckDuckGo, но моя жена может достигнуть Facebook на своем iPad). Я подозреваю тех, что это может достигнуть происходят из-за DNS, кэширующегося где-нибудь вдоль строки.

Я попытался не комментировать обоих gateway4 строка и три строки сервера имен, вместе и отдельно. Строка шлюза, кажется, препятствует тому, чтобы он работал вообще (я не уверен во внутренних деталях, но это, кажется, имеет смысл); строки сервера имен, кажется, не имеют эффекта. Я также попробовал его NetworkManager как рендерер, который также, кажется, заставляет это не работать вообще.

Кто-либо может видеть, где я пошел не так, как надо или предлагаю изменение, которое могло бы зафиксировать его?Спасибо!

ОБНОВЛЕНИЕ:

ip route данные, с работой /etc/network/interfaces установка:

default via 45.74.106.33 dev ethwan
default dev eth0 scope link metric 1002 linkdown
default dev ethlan scope link metric 1003
default dev wlp2s0 scope link metric 1005 linkdown
45.74.106.32/27 dev ethwan proto kernel scope link src 45.74.106.51
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.5.39 linkdown
169.254.0.0/16 dev wlp2s0 proto kernel scope link src 169.254.8.207 linkdown
169.254.0.0/16 dev ethlan proto kernel scope link src 169.254.4.254
169.254.0.0/16 dev ethwan scope link metric 1000
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

Те же данные, с netplan установка:

default via 45.74.106.33 dev ethwan
default via 198.2.97.225 dev ethwan proto dhcp src 198.2.97.228 metric 100
default dev ethlan scope link metric 1003
default dev wlp2s0 scope link metric 1005 linkdown
45.74.106.32/27 dev ethwan proto kernel scope link src 45.74.106.51
169.254.0.0/16 dev wlp2s0 proto kernel scope link src 169.254.8.207 linkdown
169.254.0.0/16 dev ethlan proto kernel scope link src 169.254.4.254
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
198.2.97.224/27 dev ethwan proto kernel scope link src 198.2.97.228
198.2.97.225 dev ethwan proto dhcp scope link src 198.2.97.228 metric 100

Я думаю новое 198.2.97.225 адрес является дополнительным адресом что мой ISP, присвоенный во время моих попыток. Кроме этого и реконструкции строк, это смотрит главным образом то же мне, но я не знаю много о выводе той команды.

Однако при попытке его, я сделал очень странное исследование. Когда я использую netplan конфигурация выше, машины в локальной сети могут добраться до любого сайта кроме сайтов TLS/SSL. curl -v http://google.com возвращает данные с 301 перенаправлением, curl -v https://google.com добирается до строки, которая говорит * TLSv1.3 (OUT), TLS handshake, Client hello (1): и затем это просто останавливается. Я полагаю, что это объясняет, почему некоторые обработанные сайты и другие не сделали в соответствии с той конфигурацией.

Я думал, что это могло бы быть iptables проблема, за исключением того, что это хорошо работает под /etc/network/interfaces установка.

Еще более запутанный теперь.:-?