Я создаю инструмент настройки брандмауэра на основе iptables и пытаюсь заставить работать сценарий «удар в проводе».
Учитывая настройку с eth0 и eth1 в мосту br0 и третий интерфейс eth2:
| | |
eth0 eth1 eth2
| == br0== | |
| |
| |
--- linux node ---
В этом сценарии, скажем, я хочу, чтобы трафик TCP-порта 80 был сброшен, если он идет в сеть, подключенную к eth0, но позвольте ему eth1.
Поэтому я пытаюсь надежно сопоставить пакеты, которые выходят через определенный интерфейс. eth0.
Если я добавлю следующее правило iptables в filter стол:
-A FORWARD -o br0 --physdev-out eth0 -j LOG
Учитывая пакет, который исходит от eth1 (другая половина моста), тогда правило отлично подходит, ведя журнал:
... IN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 ...
Однако если пакет исходит от eth2, то правило больше не соответствует.
Мне кажется, что алгоритм маршрутизации не может определить, какой из мостовых интерфейсов выбрать, поэтому пакет отправляется через оба интерфейса в мосте.
Если я добавлю еще одно правило, более беспорядочное, то получу следующий вывод журнала для этого пакета:
... IN=eth2 OUT=br0 ...
Я предполагаю, что в первом случае алгоритм маршрутизации может просто выбрать другой интерфейс на мосту, поскольку этот пакет не должен выходить тем же путем, которым пришел. Во втором случае он не выбрал конкретный интерфейс, и вы вообще не получите никакой информации о физическом разработчике!
Однако, если мост узнал MAC-адрес назначения (как показано brctl showmacs br0), то он может определить правильный интерфейс, и вы снова получите физдев информатино.
(Существует также третий случай: когда мост состоит из трех интерфейсов, к которым это, кажется, относится, тогда он все еще не может установить единственный интерфейс для отправки пакета, просто исключая исходный интерфейс.)
Итак, вопрос в том, как я могу надежно сопоставить пакеты, которые выходят eth0 несмотря на?
Учитывая пример, который я привел в начале, недостаточно просто сопоставить пакеты, которые будут маршрутизироваться через несколько интерфейсов, один из которых eth0 (хотя это было бы полезно в других сценариях). Я хочу иметь возможность обрабатывать трафик для eth0 и eth1 иначе, разрешая трафику eth1, но нет eth0.
Причины наблюдаемого поведения
Причина, по которой iptables не получает информацию о физическом мосте, когда пакет прибывает из интерфейса без моста, заключается в том, что пакет никогда не находился рядом с механизмом моста, хотя на данный момент мы знаем, что отправляем его по мосту.
В случае, когда пакет действительно прибыл через порт моста, но это мост N> 2, проблема в том, что расширение iptables PHYSDEV предусматривает только одно значение для «out», поэтому оно просто не беспокоит нас, если их двое.
Решение
Используйте ebtables вместо iptables. Ebtables OUTPUT chain будет знать, на какой физический мостовой интерфейс он отправляет пакеты.
В приведенном выше сценарии вы хотите отфильтровать пакеты, которые уходят через определенный мостовой интерфейс (eth0), независимо от того, как оно попало в систему, добавьте правило ebtables в следующих строках:
-A OUTPUT -o eth0 -j <target>
В более сложном сценарии, когда вы хотите фильтровать пакеты, поступающие из определенного интерфейса и уходящие через мостовой интерфейс, становится сложнее. Допустим, мы хотим удалить весь трафик с eth2 (без моста) собирается eth0 (мостик как часть br0) нам нужно добавить это правило в iptables:
-A FORWARD -i eth2 -o br0 -j MARK --set-mark 1234
Это будет отмечать любой пакет, исходящий из eth2 и направляется к мосту. Затем мы добавляем это правило в ebtables:
-A OUTPUT -physdev-out eth0 --m mark --mark 1234 -j DROP
Который будет DROP любой пакет, помеченный iptables (как от eth2), который выходит через определенный порт моста eth0.
Благодарности
Выражаем благодарность Паскалю Хамбургу из списка рассылки netfilter iptables за его помощь в разработке этого решения.