openvpn (tun0 + bridge): Ponte de comunicação - tun0 funciona mas não na direção oposta

Question

Minha rede é composta da seguinte forma:

• Host A com ip 9.x.x.x e vpn ip 192.15.206.x (cliente openvpn)

• Host B com ip 9.x.x.x e vpn ip 192.15.206.1 (servidor openvpn) este host tem uma ponte br0 com ip 192.168.206.1

• Host C com ip 192.168.206.2/192.168.206.255 que mora no vnet0 do host B. o vnet0 é preenchido com br0

Eu quero alcançar C de A. Isso é o que acontece:

• No host B, posso executar o ping em A (com 9.x.x.x ou 192.15.206.x) e C
• Do host C, posso fazer ping tanto em B como em A (com 192.15.206.x)
• Do host A, posso fazer o ping B com o IP 192.15.206.1 ou 192.168.206.1, mas não com o C que tem o IP 192.168.206.2

Então a questão é por quê? A tabela de rotas é:

192.15.206.2    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
9.168.58.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.15.206.0    192.15.206.2    255.255.255.0   UG    0      0        0 tun0
192.168.206.0   0.0.0.0         255.255.255.0   U     0      0        0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1004   0        0 br0
0.0.0.0         9.168.58.254    0.0.0.0         UG    0      0        0 eth0

a configuração da ponte é:

bridge name     bridge id               STP enabled     interfaces
br0             8000.005056a67d62       no              eth1
                                                        vnet0

O comando:

cat /proc/sys/net/ipv4/ip_forward

retorna 1

Com tcpdump -i tun0 se eu executar o ping 192.168.206.1 no host A:

14:33:23.927126 IP 192.15.206.6 > 192.168.206.1: ICMP echo request, id 768, seq 513, length 40
14:33:23.927191 IP 192.168.206.1 > 192.15.206.6: ICMP echo reply, id 768, seq 513, length 40

o replay é enviado de volta. Mas se eu executar o ping 192.168.206.2 no host A, o replay não será enviado de volta.

14:36:33.262959 IP 192.15.206.6 > 192.168.206.2: ICMP echo request, id 768, seq 1281, length 40
14:36:38.749631 IP 192.15.206.6 > 192.168.206.2: ICMP echo request, id 768, seq 1537, length 40

Parece que os pacotes chegam de A para B com o dispositivo tun0, mas eles não são encaminhados para br0, que devem enviar o pacote para o vnet0 que conecta o host C.

O problema está relacionado ao iptables, na verdade parando o serviço iptables eu posso pingar C de A. Eu tentei estas regras sem sucesso:

-A FORWARD -i br0 -j ACCEPT
-A FORWARD -o br0 -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -o br0 -j ACCEPT
-A FORWARD -i vnet0 -j ACCEPT
-A FORWARD -o vnet0 -j ACCEPT
-A FORWARD -i vnet0 -j ACCEPT
-A FORWARD -o vnet0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT

Alguma ideia?

    

Answer 1

Isso pode ser

1. um problema de firewall em B (Netfilter contra-intuitivo também bloqueia pacotes em uma ponte)
2. um problema de firewall em C (não muito provável)
3. um problema de roteamento em C

Portanto, verifique iptables -L -nv em B para encaminhamento e ip route em C.

Editar 1

O firewall em B pode ser configurado para permitir que esses pacotes passem, por exemplo,

iptables -I FORWARD 2 -m physdev --physdev-in vnet0 -j ACCEPT
iptables -I FORWARD 2 -m physdev --physdev-out vnet0 -j ACCEPT

Claro, você pode usar os endereços de origem e de destino (ou além).

Editar 2

Como:

iptables -I FORWARD 2 -s 192.15.206.2 -d 192.168.206.2 -j ACCEPT
iptables -I FORWARD 2 -d 192.15.206.2 -s 192.168.206.2 -j ACCEPT

    

Answer 2

O problema provavelmente não é mais relevante para você, mas eu ainda queria deixar isso aqui, já que tive o mesmo problema.

Emita o seguinte comando:

#brctl showstp br0
.... other interfaces ....
tun0 (8)
 port id                8008                    state                disabled
 designated root        8000.0cc47a95b66f       path cost                100
 designated bridge      8000.0cc47a95b66f       message age timer          0.00
 designated port        8008                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

Observe que o estado do seu tun0 está provavelmente desativado. Isso significa que a máquina acha que o link está inativo, portanto, ignora todos os pacotes. Você simplesmente precisa emitir o seguinte comando, e a interface irá para o estado de aprendizado, ficará lá por cerca de 10 segundos e então entrará no estágio de encaminhamento no qual tudo passará.

ip link set dev tun0 up