Cum pot VM-urile invitate să ajungă la gazda din rețea cu o rețea în punte?

După ce a întrebat această întrebare Am putut să-mi configurez mașinile virtuale să se conecteze direct la LAN. Acest lucru a funcționat conform intenției, cu excepția faptului că VM-urile invitate nu pot comunica cu gazda.

Ubuntu Server 20.04.03 LTS.

Iată planul meu de rețea gazdă:

reţea:
  ethernet:
    enp3s0:
      dhcp4: adevărat
      opțional: adevărat
    enp4s0:
      dhcp4: fals
      dhcp6: fals
  poduri:
    br0:
      interfete:
      - enp4s0
      adrese:
      - 192.168.1.200/24
      gateway4: 192.168.1.1
      servere de nume:
        adrese:
        - 1.1.1.1
        - 1.0.0.1
        - 8.8.8.8
        - 8.8.4.4
        căutare: []
      parametri:
        stp: adevărat
      dhcp4: nu
      dhcp6: nu
  vlans:
    vlan15:
      accept-ra: nu
      id: 15
      link: enp4s0
  versiunea: 2

Și aici este configurația rețelei vm (virsh net-edit implicit)

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

În timp ce VM-ul invitat apare pe LAN și are acces exterior și poate fi accesat de pe alte computere reale din rețea, VM-ul invitat nu poate ajunge la gazda sa.

Iată rezultatul din promptul de comandă Windows Server din VM pentru un ping și un tracert: (gazda este 192.168.1.200, invitatul este 192.168.1.33, pe care l-a primit de la DHCP-ul routerului pe LAN)

C:\Utilizatori\Administrator>ping 192.168.1.200

Ping 192.168.1.200 cu 32 de octeți de date:
Răspuns de la 192.168.1.33: Gazda destinație inaccesibilă.

Statistici ping pentru 192.168.1.200:
    Pachete: trimise = 1, primite = 1, pierdute = 0 (0% pierdere),

C:\Utilizatori\Administrator>tracert 192.168.1.200


Urmărirea rutei la 192.168.1.200 pe maximum 30 de hopuri

  1 SVR-BACKUP [192.168.1.33] raportează: Gazda destinație inaccesibilă.

Urmărirea completă.

Ce altceva trebuie să fac pentru a finaliza conectivitatea, astfel încât mașinile virtuale invitate să poată comunica cu gazda?

Editare: așa cum a fost solicitat, aici este rezultatul sudo iptables -xvnL

INTRARE în lanț (politica ACCEPTĂ 195866 pachete, 25432549 octeți)
    pkts bytes target prot opt ​​in out source destination

Lanț FORWARD (politica DROP 0 pachete, 0 octeți)
    pkts bytes target prot opt ​​in out source destination
       0 0 DOCKER-USER toate -- * * 0.0.0.0/0 0.0.0.0/0
       0 0 DOCKER-ISOLATION-STAGE-1 toate -- * * 0.0.0.0/0 0.0.0.0/0
       0 0 ACCEPT toate -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,STABLISHED
       0 0 DOCKER toate -- * docker0 0.0.0.0/0 0.0.0.0/0
       0 0 ACCEPT toate -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
       0 0 ACCEPT toate -- docker0 docker0 0.0.0.0/0 0.0.0.0/0

IEȘIRE în lanț (politica ACCEPTĂ 252563 pachete, 775126408 octeți)
    pkts bytes target prot opt ​​in out source destination

Lanț DOCKER (1 referințe)
    pkts bytes target prot opt ​​in out source destination
       0 0 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:3690

Lanț DOCKER-ISOLATION-STAGE-1 (1 referințe)
    pkts bytes target prot opt ​​in out source destination
       0 0 DOCKER-ISOLATION-STAGE-2 toate -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
       0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0

Lanț DOCKER-ISOLATION-STAGE-2 (1 referințe)
    pkts bytes target prot opt ​​in out source destination
       0 0 DROP all -- * docker0 0.0.0.0/0 0.0.0.0/0
       0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0

Lanț DOCKER-USER (1 referințe)
    pkts bytes target prot opt ​​in out source destination
       0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0

Și sudo iptables -t nat -xvnL

PRERUUTARE în lanț (politica ACCEPTĂ 39583 pachete, 13257450 octeți)
    pkts bytes target prot opt ​​in out source destination
    8156 2476484 DOCKER toate -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE se potrivește cu dst-type LOCAL

INTRARE în lanț (politica ACCEPTĂ 8712 pachete, 2524965 octeți)
    pkts bytes target prot opt ​​in out source destination

IEȘIRE în lanț (politica ACCEPTĂ 10911 pachete, 606007 octeți)
    pkts bytes target prot opt ​​in out source destination
       6 1768 DOCKER toate -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE se potrivește cu dst-type LOCAL

POSTROUTING în lanț (politica ACCEPTĂ 10911 pachete, 606007 octeți)
    pkts bytes target prot opt ​​in out source destination
       0 0 MASQUERADE toate -- * !docker0 172.17.0.0/16 0.0.0.0/0
       0 0 MASQUERADE tcp -- * * 172.17.0.2 172.17.0.2 tcp dpt:3690

Lanț DOCKER (2 referințe)
    pkts bytes target prot opt ​​in out source destination
       0 0 RETURN all -- 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 la:172.17.0.2:3690

Problema a fost netfilter.

Urmărind instrucțiuni aici Am dezactivat netfilter pentru poduri și am reușit să obțin o comunicare adecvată în rețea între VM, LAN și gazdă. Porțiunea relevantă:

Din motive de performanță și securitate, dezactivați netfilter pentru poduri. Creați /etc/sysctl.d/bridge.conf cu acest conținut:

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

Creați /etc/udev/rules.d/99-bridge.rules cu următorul conținut. Această regulă udev aplică setările sysctl de mai sus atunci când modulul bridge este încărcat. (Dacă utilizați Linux kernel 3.18 sau o versiune ulterioară, schimbați KERNEL=="bridge" în KERNEL=="br_netfilter".)

ACTION=="add", SUBSYSTEM=="modul", KERNEL=="bridge", RUN+="/sbin/sysctl -p /etc/sysctl.d/bridge.conf"

După ce am făcut asta, toate problemele mele au dispărut.