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

Справочная информация:
У меня есть мост Linux (Ubuntu 15.10, 64bit, имя Bridge B ) с двумя физическими интерфейсами, eth0 и eth1, а имя интерфейса моста - br0. Отправка A (Win 10) подключается к eth0, а Получатель 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

Отправить отправить пакет на приемник C , например icmp ping.

Проблема:
Перед настройкой правила ebtable в мосте B для перенаправления пакета на уровень 3 все в порядке, Получатель C получает пакет эхо-запроса 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 , который через Мост B уровень 3, я могу видеть в Получателе C , что MAC-адрес источника Адрес пакета: B0: 51: 8E: FF: 2F: C8. Очевидно, что исходный MAC-адрес изменяется на MAC-адрес br0 моста B .

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

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

/ etc / network / interface в 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, Я прочитал справочную страницу 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-адрес Bridge B .

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

Я хочу сохранить информацию о пакете на уровне 2, потому что не хочу, чтобы Получатель C обнаруживал какое-либо устройство между Отправителем A ] и себя. Другая важная причина заключается в том, что в некоторых сценариях Получатель C (особенно когда это шлюз) отбрасывает пакет после проверки Mac и IP источника.