Пакеты, не входящие в цепочку FORWARD

Прежде всего, это не ежедневная проблема маршрутизации. Настройка довольно сложная, поэтому позвольте мне заявить об этом раньше.

У меня есть роутер, давайте будем проще, 3 интерфейса. eth0, eth1, eth2. eth2 используется для pppoe. у eth0 & eth1 есть клиенты.

Ладно, пока все хорошо, все основные... Теперь вот сложная вещь: я создаю кучу macvlan-интерфейсов поверх eth0 и eth1, схема имени:

g1eth0 : g1 for gate1, eth0 indicates on what physical interface its laying on

Это я получил за каждую предоставленную мной линию связи, скажем, 3, 1 pppoe и 2 VPN. Затем они объединяются в мосты, названные в честь ворот.

Пока мы получили эти интерфейсы:

<iface>:<description>
eth0   : our 1st subnet is here
eth1   : our 2nd subnet is here
eth2   : our pppoe is hooked here
ppp0   : our pppoe uplink
tap0   : our vpn1 uplink
tap1   : our vpn2 uplink
g1eth0 : advertised gate over uplink1 on clients in eth0
g1eth1 : advertised gate over uplink1 on clients in eth1
g2eth0 : advertised gate over uplink2 on clients in eth0
g3eth1 : advertised gate over uplink3 on clients in eth1
gate1  : bridge containing g1eth0 and g1eth1
gate2  : bridge containing g2eth0
gate3  : bridge containing g3eth1

Как я уже сказал, несколько интерфейсов... Обратите внимание, что восходящий канал может быть объявлен через несколько физических интерфейсов, поэтому мы получили мосты.

Хорошо, теперь давайте посмотрим на правила маршрутизации:

32763:  from all fwmark 0x3 lookup 202
32764:  from all fwmark 0x2 lookup 201
32765:  from all fwmark 0x1 lookup 200

Ладно, это не так впечатляюще, очевидно, он только проверяет, что FWMARK имеет pkg, и помещает его в соответствующую таблицу.

Таблицы маршрутизации:

200:default via 1.2.3.4 dev ppp0 src 4.3.2.1

201:default via 5.6.7.8 dev tap0 src 8.7.6.5

202:default via 9.10.11.12 dev tap1 src 12.11.10.9

Хорошо, IP-адреса только для того, чтобы заполнить пробелы, вы должны быть знакомы с синтаксисом;)

Прямо сейчас у нас есть таблицы маршрутизации, правила маршрутизации и интерфейсы - но мы пропускаем маркировку pkg, так что это делается в iptables:

iptables -t mangle -A PREROUTING -i gate1 -s 10.0.0.0/16 -j MARK --set-xmark 0x1/0xffffffff
iptables -t mangle -A PREROUTING -i gate2 -s 10.0.0.0/16 -j MARK --set-xmark 0x2/0xffffffff
iptables -t mangle -A PREROUTING -i gate3 -s 10.0.0.0/16 -j MARK --set-xmark 0x3/0xffffffff

Хорошо для объяснения, мы помечаем все pkgs, пришедшие на наши мосты, с правильным значением для правил маршрутизации.

Теперь я также должен был сделать некоторые изменения в arp_announce а также arp_ignore так что правильный MAC рекламируется для g*eth*-интерфейс. Этот пост становится довольно полным, поэтому я пропущу его описание, оба настроены на 2,

filter:FORWARD цепочка пока пуста, она просто записывает полученные pkgs.

Теперь NAT'ing:iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -j MASQUERADE,

Все стандартные политики для iptables ACCEPT,

tcpdump показывает, что поступающие pkgs направлены на правильный MAC в соответствии с g*eth*-интерфейс.

mangle:PREROUTING счетчики для приращения правил, как они должны.

ip_forward подтверждено быть 1,

filter:FORWARD счетчики НЕ увеличиваются.

я получил LOG правила в каждой цепочке, но pkgs исчезают, как только mangle:PREROUTING,

Есть идеи почему?

Дополнение I: я разместил TRACE Править в PREROUTING, как подсказал мне комментарий, по иронии судьбы он не показывает ни одного из пингов, выполняемых моими клиентами.

Дополнение II: После некоторой игры с правилами, отслеживанием, промисками,... я заметил, что вижу, как данные поступают на ethX но не на gateX, Похоже, что brigde-интерфейс просто удаляет его, неудивительно, что ядро ​​не может продвинуть его вперед.

Почему мой мост-интерфейс делает это?

bridge name     bridge id               STP enabled     interfaces
gate1           8000.dead000200b5       no              g1eth0
                                                        g1eth1