Как он может сохранить исходный mac-адрес неизменным после фильтрации уровня 3 через мост Linux (который использует bridge-utils и ebtables)

Фон:
У меня есть мост Linux (Ubuntu 15.10, 64-битный, имя Bridge B) с двумя физическими интерфейсами, eth0 и eth1, и интерфейс моста называется br0. Send A (Win 10) подключается к eth0, а Receiver C (Win 10) подключается к eth1. Как показано на рисунке ниже.

Отправитель A <------> (eth0) Мост B (eth1) <------> Получатель C

MAC-адрес отправителя A: D4:EE:07:3F:F9:0D, IP-адрес: 192.168.1.2
MAC-адрес eth0 моста B: B0:51:8E:FF:2F:C8, IP-адрес отсутствует
MAC-адрес eth1 моста B: B0:51:8E:FF:2F:C9, IP-адрес отсутствует
MAC-адрес br0 моста B такой же, как у eth0 (Авто), IP-адрес: 192.168.1.1
MAC-адрес получателя C: 4C:CC:6A:DC:91:60, IP-адрес: 192.168.1.3

Send A отправляет пакет на приемник C, например, пинг icmp.

Проблема:
Прежде чем я настрою правило ebtable в мосте B для перенаправления пакета на уровень 3, все в порядке, получатель C получает ping-пакет отправки A с исходным MAC-адресом D4: EE: 07: 3F: F9: 0D и MAC-адресом назначения 4C: CC: 6A: DC: 91: 60, ничего не изменилось после отправки пакета от Send A.

Когда я устанавливаю правила ebtable на мосту B для перенаправления перенаправленного пакета на уровень 3, я могу использовать iptables для фильтрации пакетов на мосту B. Код является:

ebtables -t broute -A BROUTING -p IPv4 --logical-in br0 -j redirect

Тогда проблема произошла. Пакет от отправки A к приемнику C, который через уровень 3 моста B, я могу видеть в приемнике C, что MAC-адрес источника пакета B0:51:8E:FF:2F:C8. Очевидно, что MAC-адрес источника изменяется на MAC-адрес br0 моста B.

Мне интересно, проблема в том, что когда пакет перенаправляется с уровня 2 на уровень 3, а затем перенаправляется по мосту B на уровень 3, MAC-адрес источника затем изменяется ядром моста B.

Questing:
Что я могу сделать или настроить, чтобы сохранить исходный MAC-адрес без изменений после фильтрации уровня 3 через мост B?

/ etc / network / настройка интерфейса в мосте 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, я читал справочную страницу ebtables в http://ebtables.netfilter.org/misc/ebtables-man.html. Мое личное понимание состоит в том, что при использовании ebtables "-j redirect" цель перенаправления изменит целевой MAC-адрес на мостовое устройство, а затем пакет может быть отправлен на мостовой интерфейс br0, как упомянуто в примере выше. Таким образом, для пакета от Отправителя A к Получателю C целевой mac-адрес будет изменен на mac-адрес моста, при этом ничего не будет сказано об исходном mac-адресе, будет ли он изменен или нет.

После фильтрации по уровню 3 моста B (или по уровню 3 ничего не сделано) пакет теперь должен быть перенаправлен на приемник C. Тогда целевой mac-адрес пакета будет изменен на Receiver C. Но в то же время, MAC-адрес источника пакета должен быть изменен на MAC-адрес моста B.

Если я использую "-j accept" в цели ebtables, как вы советуете, пакет не будет отправлен на уровень 3 и прозрачно пройдет через мост B, ничего не изменится, включая MAC-адрес источника и назначения. Но я не могу сделать никакой фильтрации 3 уровня.

Причина, по которой я хочу сохранить информацию layer2 пакета, заключается в том, что я не хочу, чтобы Receiver C ощущал какое-либо существование устройства между Отправителем A и самим собой. Другая важная причина заключается в том, что в некоторых случаях Receiver C (особенно когда он является шлюзом) отбрасывает пакет после проверки исходного mac и ip.