Хм... Вроде бы немного понятно стало за прошедший день. В ebtables есть таблица Broute. Вот через нее все пакеты и проходят изначально. На этом уровне можно делать ACCEPT или DROP (по критерию естественно например поля TYPE заголовка кадра).
Ситуация немного нетипичная. Заключается это в следующем: есть 2 подсети, в них по одному модему от одного провайдера, работающего по протоколу PPPoE. Опираясь на RFC2516 можно сделать вывод, что вместе (в единой логической сети) они работать корректно не будут. Поэтому уже на канальном уровне нужно drop'ать пакеты соединения PPPoE (ethertype 0x8863 и 0x8864). Сделать это можно, как я понял, в цепочке FORWARD (например исходя из имени порта моста --in-interface).
Постараюсь описать более подробно где что. (см. рис)
eth0 - порт "нашей" подсети
eth1 - порт "не нашей" подсети (в ней находится модем, трафик которого не должен проникать через brouter)
eth2 - подсеть для "нашего" модема (трафик этого модема должен проходить только через eth0 и eth2, но не через eth1, дабы не возникли проблемы с инетом в "не нашей" подсети).
--------------------------
Теперь пару вопросов:
мост работает на канальном уровне, т.е. должен иметь при себе матрицу маршрутизации, типа ID_порта <--> mac_адрес_машины. (т.е. как маршрутизатор имеет ID_порта <--> ip_адрес_сети). Как просмотреть данную таблицу и как ее корректировать? Частично ответ на этот вопрос есть: мост в Ethernet работает в прозрачном обучающемся режиме, т.е. копирует байты адреса источника, поступающие на определенный порт и по ним строит таблицу. Это что-то типа динамического режима. Есть ли возможность прописывать такия соответствия вручную (или наприемр задавать статические маршруты)?
-----------------------
Теперь далее. Предположим, машина "нашей подсети" хочет установить PPPoE соединение с провайдером. Механизм следующий:
клиент посылает широковещательный запрос на mac уровне (ff:ff:ff:ff:ff:ff) с соотв. полем TYPE (по которому собственно говоря и хочу идентифицировать сеанс обнаружения). Но т.к. пакеты будут идти еще и с eth1, то в цепочке BROUTING мы их пропускаем, т.е.:
ebtables -P BROUTING DROP #основная политика для всех кадров, т.к. DROP, то все они должны передаться на обработки на более высоком уровне (сетевом) фильтру iptables, если ниже не заданы исключения.
ebtables -t broute -A BROUTING -p 8863 -j ACCEPT # будем эти пкадры пропускать через мост, НЕ более!
ebtables -t broute -A BROUTING -p 8863 -j ACCEPT # и эти тоже, т.к. они являются следствием установленного соединения
Т.к. они широковещательные, то попадут в цепочку FORWARD и INPUT. Здесь (по-моему) должна происходить фильтрация. На INPUT можно смело все drop'ать, т.к. наш сервер не является сервером PPPoE, а в цепочке FORWARD производить фильтрацию. Опять же, если кадр пришел с eth0, то мост должен его повторить на eth1 и eth2 (широковещательный запрос). Каким-то образом нужно это организовать так, чтобы на eth1 ничего не пошло, идея такова:
ebtables -t filter -A FORWARD -i eth0 -o eth2 -p 8863 -j ACCEPT #т.е. разрешить только тем, которые пришли с eth0 и идут на eth2
ebtables -t filter -A FORWARD -i eth0 -o eth1 -p 8863 -j DROP #не пускаем кадры генерируемые в "нашей" подсети в "не нашу" подсеть.
Вопрос: будет ли это работать в том смысле, в котором я задумал?
Ну и соответственно для "не нашей" подсети:
ebtables -t filter -A FORWARD -i eth1 -o eth0 -p 8863 -j DROP #в нашу подсеть не надо
ebtables -t filter -A FORWARD -i eth1 -o eth2 -p 8863 -j DROP #к нашему модему не надо
После широковещательных запросов пойдут направленные передачи, mac адрес сервера провайдера известен, да и опираясь все на тот же тип поля кадра ethernet можно все организовать.
----------------------------
А весь трафик, исходя из ранее заданной политики (ebtables -P BROUTING DROP) будет перенаправлен на iptables, где уже понятно что как строить).
Все. Поправте меня, если я не прав. У меня сейчас в голове именно такой способ фильтрации-маршрутизации, хотелось бы чтобы на самом деле все так и было
.
Спасибо за внимание.
