Contexto:
Eu tenho uma ponte Linux (Ubuntu 15.10, 64bit, nome Bridge B ) com duas interfaces físicas, eth0 e eth1, e o nome da interface da bridge é br0. Enviar A (Win 10) se conecta a eth0, e Receiver C (Win 10) se conecta a eth1. Como mostrado na figura abaixo.
Remetente A < ------ > (eth0) Ponte B (eth1) < ------ > Receptor C
Endereço MAC do remetente A : D4: EE: 07: 3F: F9: 0D, Endereço IP: 192.168.1.2
A eth0 da Bridge B Endereço MAC: B0: 51: 8E: FF: 2F: C8, Nenhum endereço IP
Endereço MAC eth1 de Bridge B : B0: 51: 8E: FF: 2F: C9, Sem IP Endereço do endereço MAC Bridge B br0 é o mesmo com eth0 (Auto), endereço IP: 192.168.1.1
endereço MAC do receptor C : 4C: CC: 6A: DC: 91: 60, endereço IP: 192.168.1.3
Envie um pacote de envio para o Receptor C , como o icmp ping.
Problema:
Antes de configurar a regra ebtable em Bridge B para redirecionar o pacote para a camada 3, tudo está OK, Receiver C recebe o pacote de ping Send A com Endereço MAC de origem D4: EE: 07: 3F: F9: 0D e endereço MAC de destino 4C: CC: 6A: DC: 91: 60, nada foi alterado após o envio do pacote de Enviar A .
Quando eu configuro regras ebtable no Bridge B para redirecionar pacotes encaminhados para a camada 3, então eu posso usar o iptables para filtragem de pacotes em Bridge B . O código é:
ebtables -t broute -A BROUTING -p IPv4 --logical-in br0 -j redirect
Então o problema aconteceu. Pacote de Enviar A para o Receptor C que através da camada 3 do Bridge B , eu posso ver em Receptor C que o endereço MAC de origem do pacote é B0: 51: 8E: FF: 2F: C8. Obviamente, o endereço MAC de origem é alterado para o endereço MAC br0 de Bridge B .
Eu estou querendo saber o problema é que quando o pacote é redirecionado da camada 2 para a camada 3 e, em seguida, reencaminhamento por Bridge B na camada 3, o endereço MAC de origem será alterado por Bridge O kernel de B .
Missões:/ etc / network / interface no Bridge B
auto eth0
iface eth0 inet manual
up ifconfig eth0 up
auto eth1
iface eth1 inet manual
up ifconfig eth1 up
auto br0
iface br0 inet static
address 192.168.1.1
netmask 255.255.255.0
pre-up ip link set eth0 promisc on
pre-up ip link set eth1 promisc on
pre-up echo "1">/proc/sys/net/ipv4/ip_forward
bridge_ports eth0 eth1
CGretski, eu li a página man do ebtables no link . Meu entendimento pessoal é que, ao usar ebtables “-j redirect”, o alvo de redirecionamento mudará o endereço target do MAC para o dispositivo de ponte, o pacote pode ser enviado para a ponte interface br0, como mencionado no exemplo acima. Assim, um pacote de Sender A para Receiver C , o endereço MAC de destino será alterado para o endereço MAC da bridge, nada será mencionado sobre endereço MAC de origem, se será alterado ou não.
Após a filtragem pela camada 3 do Bridge B (ou nada feito pela camada 3), o pacote agora deve ser reencaminhado para Receptor C . Em seguida, o endereço MAC de destino do pacote será alterado para Receiver C . Mas, ao mesmo tempo, o endereço MAC de origem do pacote será alterado para o endereço MAC do Bridge B .
Se eu usar "-j accept" no ebtables target, conforme seu conselho, o pacote não será enviado para a camada 3 e passará transparentemente por Bridge B , nada será alterado, incluindo origem e destino endereço MAC. Mas não consigo fazer nenhuma filtragem de camada 3.
A razão pela qual eu quero manter as informações da camada 2 do pacote é que eu não quero que o Receptor C perceba a existência de dispositivo entre Remetente A e ele mesmo. Outra razão importante é que, em alguns cenários, o Receptor C (especialmente quando é um gateway) eliminará o pacote após a verificação mac e ip de origem.
Perder informação da camada 2 é um efeito colateral esperado da introdução do roteamento da camada 3 e é a própria definição do alvo "-j redirecionado".
Da página man do ebtables:
The redirect target will change the MAC target address to that of the bridge device the frame arrived on.
você pode tentar "-j accept", embora isso não possa ser transmitido para a camada 3 de filtragem.
O que você está tentando alcançar mantendo as informações da camada 2?