Как гостевые виртуальные машины могут получить доступ к узлу в сети с помощью сетевого моста?

После запроса этот вопрос Я смог настроить свои виртуальные машины для прямого подключения к локальной сети. Это сработало, как и предполагалось, за исключением того, что гостевые виртуальные машины не могут взаимодействовать с хостом.

Сервер Ubuntu 20.04.03 LTS.

Вот мой сетевой план хоста:

сеть:
  Ethernet:
    enp3s0:
      DHCP4: правда
      необязательно: правда
    enp4s0:
      DHCP4: ложь
      DHCP6: ложь
  мосты:
    бр0:
      интерфейсы:
      - enp4s0
      адреса:
      - 192.168.1.200/24
      шлюз4: 192.168.1.1
      серверы имен:
        адреса:
        - 1.1.1.1
        - 1.0.0.1
        - 8.8.8.8
        - 8.8.4.4
        поиск: []
      параметры:
        стп: правда
      DHCP4: нет
      DHCP6: нет
  вланы:
    влан15:
      принять-ра: нет
      идентификатор: 15
      ссылка: enp4s0
  версия: 2

А вот и конфигурация сети vm (virsh net-edit по умолчанию)

<network>
  <name>default</name>
  <uuid>e0235996-534d-49c8-94d6-f213acd1552e</uuid>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>

В то время как гостевая виртуальная машина появляется в локальной сети и имеет доступ извне, и к ней можно получить доступ с других реальных компьютеров в сети, гостевая виртуальная машина не может получить доступ к своему хосту.

Вот вывод из командной строки Windows Server в виртуальной машине для проверки связи и трассировки: (хост — 192.168.1.200, гость — 192.168.1.33, который он получил от DHCP маршрутизатора в локальной сети)

C:\Пользователи\Администратор> пинг 192.168.1.200

Пинг 192.168.1.200 с 32 байтами данных:
Ответ от 192.168.1.33: Узел назначения недоступен.

Статистика пинга для 192.168.1.200:
    Пакеты: отправлено = 1, получено = 1, потеряно = 0 (0% потерь),

C:\Пользователи\Администратор>трассировка 192.168.1.200


Отслеживание маршрута до 192.168.1.200 с использованием не более 30 переходов

  1 SVR-BACKUP [192.168.1.33] сообщает: Целевой хост недоступен.

Трассировка завершена.

Что еще мне нужно сделать, чтобы завершить подключение, чтобы гостевые виртуальные машины могли взаимодействовать с хостом?

Изменить: по запросу, вот вывод судо iptables-xvnL

Цепочка INPUT (политика ACCEPT 195866 пакетов, 25432549 байт)
    pkts bytes target prot opt ​​in out source target

Цепочка FORWARD (политика DROP 0 пакетов, 0 байт)
    pkts bytes target prot opt ​​in out source target
       0 0 DOCKER-USER все -- * * 0.0.0.0/0 0.0.0.0/0
       0 0 DOCKER-ISOLATION-STAGE-1 все -- * * 0.0.0.0/0 0.0.0.0/0
       0 0 ПРИНЯТЬ все -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate СВЯЗАННО, УСТАНОВЛЕНО
       0 0 DOCKER все -- * docker0 0.0.0.0/0 0.0.0.0/0
       0 0 ПРИНЯТЬ все -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
       0 0 ПРИНЯТЬ все -- docker0 docker0 0.0.0.0/0 0.0.0.0/0

Цепочка OUTPUT (политика ACCEPT 252563 пакетов, 775126408 байт)
    pkts bytes target prot opt ​​in out source target

Сеть DOCKER (1 ссылка)
    pkts bytes target prot opt ​​in out source target
       0 0 ПРИНЯТЬ TCP -- !docker0 docker0 0.0.0.0/0 172.17.0.2 TCP dpt:3690

Сеть DOCKER-ISOLATION-STAGE-1 (1 ссылка)
    pkts bytes target prot opt ​​in out source target
       0 0 DOCKER-ISOLATION-STAGE-2 все -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
       0 0 ВОЗВРАТ все -- * * 0.0.0.0/0 0.0.0.0/0

Сеть DOCKER-ISOLATION-STAGE-2 (1 ссылка)
    pkts bytes target prot opt ​​in out source target
       0 0 УДАЛИТЬ все -- * docker0 0.0.0.0/0 0.0.0.0/0
       0 0 ВОЗВРАТ все -- * * 0.0.0.0/0 0.0.0.0/0

Сеть DOCKER-USER (1 ссылка)
    pkts bytes target prot opt ​​in out source target
       0 0 ВОЗВРАТ все -- * * 0.0.0.0/0 0.0.0.0/0

И sudo iptables -t nat -xvnL

Цепочка PREROUTING (политика ACCEPT 39583 пакетов, 13257450 байт)
    pkts bytes target prot opt ​​in out source target
    8156 2476484 DOCKER all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE соответствует dst-type LOCAL

Цепочка INPUT (политика ACCEPT 8712 пакетов, 2524965 байт)
    pkts bytes target prot opt ​​in out source target

Цепочка OUTPUT (политика ACCEPT 10911 пакетов, 606007 байт)
    pkts bytes target prot opt ​​in out source target
       6 1768 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE соответствует dst-типу LOCAL

Цепочка POSTROUTING (политика ACCEPT 10911 пакетов, 606007 байт)
    pkts bytes target prot opt ​​in out source target
       0 0 МАСКАРАДировать все -- * !docker0 172.17.0.0/16 0.0.0.0/0
       0 0 МАСКАРАД tcp -- * * 172.17.0.2 172.17.0.2 tcp dpt:3690

Сеть DOCKER (2 ссылки)
    pkts bytes target prot opt ​​in out source target
       0 0 ВОЗВРАТИТЬ все -- docker0 * 0.0.0.0/0 0.0.0.0/0
       0 0 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3690 to:172.17.0.2:3690

Проблема была в сетевом фильтре.

После инструкции здесь Я отключил сетевой фильтр для мостов и смог установить надлежащую сетевую связь между виртуальными машинами, локальной сетью и хостом. Соответствующая часть:

По соображениям производительности и безопасности отключите сетевой фильтр для мостов. Создайте файл /etc/sysctl.d/bridge.conf со следующим содержимым:

net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0
net.bridge.bridge-nf-call-arptables=0

Создайте файл /etc/udev/rules.d/99-bridge.rules со следующим содержимым. Это правило udev применяет указанные выше настройки sysctl при загрузке модуля моста. (При использовании ядра Linux 3.18 или более поздней версии измените KERNEL=="bridge" на KERNEL=="br_netfilter".)

ACTION=="добавить", SUBSYSTEM=="модуль", KERNEL=="мост", RUN+="/sbin/sysctl -p /etc/sysctl.d/bridge.conf"

После этого все мои проблемы исчезли.