Llama, вроде то, что надо, сенк
сразу возник вопрос: а iptables и ebtables вместе на одной машине работать будут? (не мешая друг другу)
маршрутизатор на linux
что-то совсем не могу сообразить, не варит репа последнее время и все тут... Читаю офиц сйт, посвященый ebtables (кстати там куча примеров + рассматривается описание работы с iptables). Так вот у меня вопрос. Объясните плиз в пару словах как эти 2 вещи вместе работают? Боюсь у меня очень далекое от истинного представление.
Что я понял так это что ebtables работает на канальном уровне, а iptables на сетевом (чуть выше). Поэтому пакеты попадая на устройство мост-маршрутизатор сначала обрабатываются мостом (считываются заголовки кадра Ethernet, и скорее всего тип кадров - Ethernet II) затем пакет передается для обработки вышележащих запакованных данных (работать начинает маршрутизатор, т.е. цепочки iptables). Непонятен следующий момент: пакеты проходящие через цепочки правил ebtables попадают на iptables? И как "научить" пересылать мост пакеты с одного порта на другой? (по определенным критериям), нужны ли для этого интерфейсы типа br0,1 и т.д., или можно обойтись "стандартными средствами"?
Что я понял так это что ebtables работает на канальном уровне, а iptables на сетевом (чуть выше). Поэтому пакеты попадая на устройство мост-маршрутизатор сначала обрабатываются мостом (считываются заголовки кадра Ethernet, и скорее всего тип кадров - Ethernet II) затем пакет передается для обработки вышележащих запакованных данных (работать начинает маршрутизатор, т.е. цепочки iptables). Непонятен следующий момент: пакеты проходящие через цепочки правил ebtables попадают на iptables? И как "научить" пересылать мост пакеты с одного порта на другой? (по определенным критериям), нужны ли для этого интерфейсы типа br0,1 и т.д., или можно обойтись "стандартными средствами"?
Debian GNU/Linux 3.1 Sarge
Kernel 2.6.16
Kernel 2.6.16
Хм... Вроде бы немного понятно стало за прошедший день. В 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, где уже понятно что как строить).
Все. Поправте меня, если я не прав. У меня сейчас в голове именно такой способ фильтрации-маршрутизации, хотелось бы чтобы на самом деле все так и было
.
Спасибо за внимание.
Ситуация немного нетипичная. Заключается это в следующем: есть 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, где уже понятно что как строить).
Все. Поправте меня, если я не прав. У меня сейчас в голове именно такой способ фильтрации-маршрутизации, хотелось бы чтобы на самом деле все так и было
. Спасибо за внимание.
Debian GNU/Linux 3.1 Sarge
Kernel 2.6.16
Kernel 2.6.16
Немного назад... проблема в следующем: для фильтрации на 2 уровне OSI нужно на сервере организовать мост. Хорошо, делаю мост, добавляя:
brctl addbr br0
ifconfig br0 192.168.2.100 netmask 255.255.255.0
brctl addif br0 eth0
brctl addif br0 eth2
Через eth1 подключаю свой комп. (на eth1 192.168.1.100/24). Беру себе ip 192.168.1.10/24, шлюз ip_eth1. В таблицах маршрутизации (route -n) все по-прежнему, только добавилась запись типа 192.168.2.100 0.0.0.0 U 255.255.255.0 br0.
Пробую пинговать модем (10.5.5.1). Он писался сначала на шлюз 10.5.5.100 (eth0), затем на шлюз ip_br0, предварительно сменив его ip, чтобы был в подсети 192.168.2.0/24. Пинги не проходят!
Удаляю интерфейс моста (brctl delbr br0, предварительно ifconfig br0 down). Пинг идет...
А в идеале стоит задача объединить все 3 адаптера в мост, чтобы каждый при этом сохранил свой IP для вышележащих уровней. В инете описываются случаи чтобы мост работал прозрачно, без своих IP. Это не то в данном случае. И можно ли так сделать, сочетая мост и маршрутизатор на одних и тех же сетевых интерфейсах, соединяющих разные подсети (192.168.1.х, 10.х.х.х, etc.)?
P.S. порой кажется, что сама идея бессмысленна (
brctl addbr br0
ifconfig br0 192.168.2.100 netmask 255.255.255.0
brctl addif br0 eth0
brctl addif br0 eth2
Через eth1 подключаю свой комп. (на eth1 192.168.1.100/24). Беру себе ip 192.168.1.10/24, шлюз ip_eth1. В таблицах маршрутизации (route -n) все по-прежнему, только добавилась запись типа 192.168.2.100 0.0.0.0 U 255.255.255.0 br0.
Пробую пинговать модем (10.5.5.1). Он писался сначала на шлюз 10.5.5.100 (eth0), затем на шлюз ip_br0, предварительно сменив его ip, чтобы был в подсети 192.168.2.0/24. Пинги не проходят!
Удаляю интерфейс моста (brctl delbr br0, предварительно ifconfig br0 down). Пинг идет...
А в идеале стоит задача объединить все 3 адаптера в мост, чтобы каждый при этом сохранил свой IP для вышележащих уровней. В инете описываются случаи чтобы мост работал прозрачно, без своих IP. Это не то в данном случае. И можно ли так сделать, сочетая мост и маршрутизатор на одних и тех же сетевых интерфейсах, соединяющих разные подсети (192.168.1.х, 10.х.х.х, etc.)?
P.S. порой кажется, что сама идея бессмысленна (
Debian GNU/Linux 3.1 Sarge
Kernel 2.6.16
Kernel 2.6.16
вот такая ситуация: подсеть 100 машин 192.168.1.0/24 (eth0) и 10.1.1.0/24 (eth1) на 50 машин, к eth2 модем, без разницы с каким ип и маской данный модем и интерфейс. Если я все 3 eth включаю в мост, то как тогда будет происходить маршрутизация, обращение к ресурсам сервера, обращение к машинам одной подсети к машинам из другой, как будет выглядеть шлюз на клиентах, и как будет работать iptables?
Этого я немного не понимаю, мот чего и прокатит, не знаю.
Впринципе то ведь в ethernet по mac идет маршрутизация. Вот как быть, если надо будет контролировать на сетевом уровне пакеты, drop'ать по протоколу, Ip, портам и т.д.
Уже посоветовали читать про vlan...
Этого я немного не понимаю, мот чего и прокатит, не знаю.
Впринципе то ведь в ethernet по mac идет маршрутизация. Вот как быть, если надо будет контролировать на сетевом уровне пакеты, drop'ать по протоколу, Ip, портам и т.д.
Уже посоветовали читать про vlan...
Debian GNU/Linux 3.1 Sarge
Kernel 2.6.16
Kernel 2.6.16
немного понятно, уже лучше, спасиб
но вот сразу возник вопрос, например переходя на 3 уровень OSI, в цепочках iptables например: iptables -A FORWARD -i eth0 -o eth1....
Вот такая вещь во что преобразится должна в данном случае? Т.е. продолжают ли существовать в представлении машины eth0, eth1, etc.... или же надо как-то с br0 извращаться?
но вот сразу возник вопрос, например переходя на 3 уровень OSI, в цепочках iptables например: iptables -A FORWARD -i eth0 -o eth1....
Вот такая вещь во что преобразится должна в данном случае? Т.е. продолжают ли существовать в представлении машины eth0, eth1, etc.... или же надо как-то с br0 извращаться?
Debian GNU/Linux 3.1 Sarge
Kernel 2.6.16
Kernel 2.6.16
