Чому мій брандмауер (iptables) втручається в мій міст (brctl)?

Я встановив міст, br0"прикріплений" до двох інтерфейсів:

• eth0, мій фізичний інтерфейс, підключений до реальної локальної мережі,
• vnet0, віртуальний інтерфейс KVM (підключений до Windows VM).

І я маю це єдине правило брандмауера у прямому ланцюзі:

iptables -A FORWARD -j REJECT

Тепер єдиний ping, який працює, - від VM до хоста.

br0Інтерфейс належить IP - адреса мого хоста. eth0і vnet0не "володіти" жодним IP-адресою з точки зору хоста. Windows VM має статичну конфігурацію IP.

Якщо змінити моє iptablesправило на ACCEPT(або навіть використовувати більш обмежувальне iptables -A FORWARD -o br0 -j ACCEPT), все працює нормально! (тобто я можу пінг будь-якої локальної машини з VM, і навпаки).

Усі параметри ядра переадресації IP відключені (як net.ipv4.ip_forward = 0).

Отже, як може брандмауер Netfilter блокувати щось, що навіть не ввімкнено?

Крім того, трафік VM - LAN повинен передбачати лише eth0та vnet0. І все-таки виглядає так, щоб дозволити рух -o br0" Вперед " з "роботами" (я не перевіряв дуже уважно).

Коментар від Stéphane Chazelas дає натяк на відповідь.

Відповідно до Bridge-nf часто задаваних питань bridge-nf дозволяє iptables, ip6tables або arptables бачити мостиковий трафік.

У версії 2.6.1 ядра є п'ять записів sysctl для контролю поведінки міст-nf:

• bridge-nf-call-arptables - передати мостифікований трафік ARP до ланцюга FORWARD arptables.
• bridge-nf-call-iptables - передавати місткий IPv4 трафік до мереж iptables.
• bridge-nf-call-ip6tables - передавати місткий трафік IPv6 до ip6tables.
• bridge-nf-filter-vlan-tagged - передайте мости ARP / IP-трафіку з мостом Vlan до аргументів / iptables.
• net.bridge.bridge-nf-filter-pppoe-tagged - передайте місткі протоколи IP / IPv6 з міткою pppoe до таблиць {ip, ip6}

Ви можете відключити блокування брандмауера Netfilter за допомогою:

# sysctl -w net.bridge.bridge-nf-call-iptables=0
# sysctl -w net.bridge.bridge-nf-call-ip6tables=0