Terminologia de rede virtual: uma ponte NATed ou roteada é um oxímoro?

Question

De acordo com p. 166 de Dominando Virtualização KVM por Chirammal et al (Packt, 2016), a aba "Redes Virtuais" em O Virt-Manager permite a criação de três tipos de redes virtuais:

• NATed
• encaminhado
• Isolado

Olhando para a caixa de diálogo de criação de rede vinculada a essa guia, isso parece ser amplamente verdade.

Ter permitido que o Virt-Manager crie, por padrão, uma rede virtual NATed em um PC executando Debian 9" Stretch ", vejo que sudo brctl show yields (ID de ponte modificada para privacidade):

bridge name bridge id       STP enabled interfaces
virbr0      8000.5254009dcac5   yes     virbr0-nic

Isso gera dúvidas, por exemplo:

• Se virbr0 for uma ponte , como também pode funcionar como um NAT ?
• A virbr0 é a única coisa que o Virt-Manager criou quando eu permiti que ele criasse uma rede virtual ou criava alguma outra coisa (por exemplo, um roteador NAT virtual, ao qual virbr0 estava conectado)?
• Pergunta adicional: Supondo que o host tenha uma NIC física (Ethernet) conectada a uma LAN e que duas máquinas virtuais guest, VM1 e VM2, estejam conectadas a virbr0 , qual é a topologia da rede? como?

Adendo

Aqui estão os estados iptables e ebtables, como mencionado no comentário e respostas até agora:

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             192.168.122.0/24     ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootpc

$ sudo iptables -t nat -vL
Chain PREROUTING (policy ACCEPT 1556 packets, 130K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 726 packets, 82025 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 15148 packets, 953K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 15148 packets, 953K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   84 11805 RETURN     all  --  any    any     192.168.122.0/24     base-address.mcast.net/24 
    0     0 RETURN     all  --  any    any     192.168.122.0/24     255.255.255.255     
  267 16020 MASQUERADE  tcp  --  any    any     192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
  206 15656 MASQUERADE  udp  --  any    any     192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
    1    84 MASQUERADE  all  --  any    any     192.168.122.0/24    !192.168.122.0/24    


$ sudo ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

    

Answer 1

If virbr0 is a bridge, then how can it also function as a NAT?

Bem, isso não acontece. Mas o sistema em si tem uma porta na ponte, e se houver um endereço IP configurado na ponte, ele poderá fazer o encaminhamento / encaminhamento / NAT entre a ponte e alguma outra interface.

Portanto, supondo que você tenha, digamos eth0 como o uplink e virbr0 vinculando as VMs, que aparecem como vmnic0 e assim por diante. Então você teria algo assim:

      ^
      |
    eth0 (192.0.2.111 - your external IP)
      |
[[ routing / NAT ]]
      |
   virbr0 (10.0.1.1 - this system on the VM bridge)
      |
   +--+-----+-----+-------+       (the bridging part)
   |        | ... |       |
  vmnic0               vmnicN

Aqui, eth0 não faz parte da ponte. Se fosse, as VMs seriam conectadas à rede externa sem roteamento. (O vmnic s pode ser nomeado de alguma outra forma, não consigo lembrar as convenções de nomenclatura usadas ...)

ifconfig ou ip addr deve poder mostrar o IP da bridge, e você precisa de iptables -t nat -vL para ver as regras NAT do iptables.

Agora, o virbr0-nic do seu exemplo é aparentemente um dispositivo fictício criado para fornecer à bridge um endereço MAC imutável. De acordo com uma explicação na lista de discussão libvirt-users :

It's a workaround for kernel bug/feature. The bridge's MAC is copied from the first NIC attached. So if one detach all interfaces from a bridge and then attach just one, the bridge will lost previous MAC and gain a new one - just the same as the attached interface has.

So if libvirt has to ensure a MAC for virtual bridge - it creates this dummy device (no traffic is routed through though) and just attach it to the virtual bridge.