Ponte do Linux para o KVM

Question

Eu tenho uma máquina Debian Wheezy em que eu tentei configurar o KVM com redes em ponte. Infelizmente, a ponte não parece encaminhar o tráfego corretamente.

Minha configuração é a seguinte:

A máquina física tem um eth0 conectado a um roteador com o endereço IP 192.168.0.1.
Esse eth0 é um membro da interface de ponte br0 , que é configurada estaticamente para o endereço IP 192.168.0.101.
A interface de rede da máquina virtual é vnet0 no host físico e eth0 na máquina virtual. Na máquina virtual, a interface é configurada estaticamente para o endereço IP 192.168.0.110.

No host físico, posso executar o ping na máquina virtual e no roteador:

# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=0.331 ms

# ping 192.168.0.110
PING 192.168.0.110 (192.168.0.110) 56(84) bytes of data.
64 bytes from 192.168.0.110: icmp_req=1 ttl=64 time=0.417 ms

Na máquina virtual, posso fazer ping na máquina física:

# ping 192.168.0.101:
PING 192.168.0.101 (192.168.0.101) 56(84) bytes of data.
64 bytes from 192.168.0.101: icmp_req=1 ttl=64 time=0.133 ms

Mas não consigo fazer o ping no roteador:

# ping 192.168.0.1:
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.110 icmp_seq=10 Destination Host Unreachable

Pelo que posso dizer, a ponte está configurada corretamente e todas as portas conectadas estão no estado de encaminhamento:

# brctl show
bridge name bridge id           STP enabled interfaces
br0         8000.2cd444acf8ad   no          eth0
                                            vnet0
# brctl showstp br0
br0
 bridge id               8000.2cd444acf8ad
 designated root         8000.2cd444acf8ad
 root port               0                    path cost        0
 max age                 20.00                bridge max age           20.00
 hello time              2.00                 bridge hello time         2.00
 forward delay           0.00                 bridge forward delay      0.00
 ageing time             300.01
 hello timer             1.20                 tcn timer                 0.00
 topology change timer   0.00                 gc timer                 28.95
 flags          


eth0 (1)
 port id            8001                state            forwarding
 designated root    8000.2cd444acf8ad   path cost              4
 designated bridge  8000.2cd444acf8ad   message age timer      0.00
 designated port    8001                forward delay timer    0.00
 designated cost       0                hold timer             0.20
 flags          

vnet0 (2)
 port id            8002                state            forwarding
 designated root    8000.2cd444acf8ad   path cost            100
 designated bridge  8000.2cd444acf8ad   message age timer      0.00
 designated port    8002                forward delay timer    0.00
 designated cost       0                hold timer             0.20
 flags          

Tanto iptables como ebtables estão vazios com uma política padrão de ACCEPT :

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination   
# 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

Alguém tem uma ideia do que causa este problema e como posso resolvê-lo?

Editar:

Aparentemente, a bridge reconhece que há algo conectado a ela, já que ela constrói uma tabela MAC:

# brctl showmacs br0
port no mac addr            is local?   ageing timer
  1     2c:76:8a:ff:88:1d   no            1.28   <- ???
  1     2c:d4:44:ac:f8:ad   yes           0.00   <- MAC of br0 and physical eth0
  2     52:54:00:53:dd:34   no          143.80   <- MAC of VM's eth0
  1     c8:1f:66:ba:83:33   no            0.00   <- MAC of router interface
  2     fe:54:00:53:dd:34   yes           0.00   <- MAC of vnet0

Editar 2:

Acabei de criar uma segunda máquina virtual. Esta máquina tem a interface vnet1 na máquina física, sua eth0 virtual foi atribuída ao endereço IP 192.168.0.111. Essa VM também pode fazer ping apenas na máquina física e nem no roteador nem na VM original. brctl showstp mostra todas as portas, incluindo vnet1, no estado de encaminhamento e brctl showmacs mostra os MACs de vnet1 e a eth0 virtual da nova máquina, além do que escrevi acima.

    

Answer 1

Verifique se o kernel está configurado para ativar o encaminhamento de IP:

sysctl -a | grep forwarding

Você pode ativar com:

sudo sysctl net.ipv4.conf.all.forwarding=1
sudo sysctl net.ipv6.conf.all.forwarding=1

Também pode haver um problema com o proxy ARP. Verifique com:

sysctl -a | grep proxy_arp

E defina com o comando:

sudo sysctl net.ipv4.conf.eth0.proxy_arp=1

Você pode colocar as chaves e valores em um arquivo em /etc/sysctl.d para que os valores sejam redefinidos na reinicialização.

O teste de outro dispositivo na sub-rede do roteador pode ajudar a determinar o problema.

• O ping da máquina virtual pode fornecer diagnósticos úteis.
• A verificação se você pode ARP para a máquina virtual indicará se você pode encontrar o endereço MAC para o servidor. Use "arp -a" depois de fazer o ping para ver se o endereço MAC foi encontrado com sucesso.
• O traceroute pode indicar onde o problema é iniciado.

O teste com tcpdump na interface eth0 também pode indicar onde a conexão está falhando.

• Solicitações repetidas de arp sem uma resposta válida indicam um problema de alcance.
• A falta de echo ou echo reply tráfego pode indicar qual lado tem um problema.
• As respostas do traceroute ao roteador ou aos endereços por trás dele podem fornecer informações adicionais.