Во-первых, это не повседневная проблема маршрутизации. Настройка довольно сложна, поэтому позвольте мне сказать об этом раньше.
У меня есть роутер с 3 интерфейсами. эт0, эт1, эт2. 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 есть в пакете, и помещает его в соответствующую таблицу.
Таблицы маршрутизации:
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
Хорошо для объяснения, мы помечаем все пакеты, поступающие в наши мосты, с правильным значением для правил маршрутизации.
Теперь мне также пришлось внести некоторые изменения в arp_announce и arp_ignore так что правильный MAC объявляется для g*eth*-интерфейсы. Этот пост становится довольно полным, поэтому я пропущу его описание, оба настроены на 2.
В filter:FORWARD цепочка пока пуста, она просто регистрирует полученные пакеты.
Теперь NAT'ing: iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -j MASQUERADE.
Все политики по умолчанию для iptables: ACCEPT.
tcpdump показывает, что входящие пакеты пакетов направляются на правильный MAC в соответствии с g*eth*-интерфейсы.
mangle:PREROUTING счетчики правил увеличиваются должным образом.
ip_forward подтверждено, чтобы быть 1.
filter:FORWARD счетчики НЕ увеличиваются.
я получил LOG правил в каждой цепочке, но кажется, что пакеты исчезают после прохождения mangle:PREROUTING.
Есть идеи, почему?
Дополнение I: Я разместил TRACE в PREROUTING, как мне подсказал комментарий, по иронии судьбы он не показывает ни одного пинга, запущенного моими клиентами.
Дополнение II: После некоторой игры с правилами, трассировкой, промисками ... я заметил, что данные попадают в ethX но не на gateX. Похоже, что brigde-interface просто отбрасывает его, неудивительно, что ядро не может его запустить.
Почему мой мост-интерфейс делает это?
bridge name bridge id STP enabled interfaces
gate1 8000.dead000200b5 no g1eth0
g1eth1
Он мог быть заблокирован из-за фильтрации обратного пути.
Попробуйте выключить: http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html