маршрутизатор на linux

cranium · Сообщение **cranium** » 06 апр 2006, 13:24

а вот чего я нашел интересного на http://ebtables.sourceforge.net/examples.html#easy

Making a brouter:

Here is an example setup for a brouter with the following situation: br0 with ports eth0 and eth1.

ifconfig br0 0.0.0.0
ifconfig eth0 172.16.1.1 netmask 255.255.255.0
ifconfig eth1 172.16.2.1 netmask 255.255.255.0
ebtables -t broute -A BROUTING -p ipv4 -i eth0 --ip-dst 172.16.1.1 -j DROP
ebtables -t broute -A BROUTING -p ipv4 -i eth1 --ip-dst 172.16.2.1 -j DROP

cranium · Сообщение **cranium** » 06 апр 2006, 14:43

А во: http://www.spenneberg.com/talks/linux-k ... gewall.pdf
Эта штука все разъяснила, вроде бы, согласно этому документу eth0, eth1, eth2 при объединении их в мост "существуют".
Я забыл, что мне нужно было различать одинаковые пакеты с какого интерфейса они идут, и соответственно с одного их разрешать, с другого убивать. Этим и была вызвана необходимость иметь по Ip на сетевой.

cranium · Сообщение **cranium** » 09 апр 2006, 11:03

Хочу вернуться к вопросу маршрутизации. Не знаю как привязать таблицы маршрутизации для различных подсетей к этому br0, есть мысль использовать ARP. Пропуская через мост ARP, клиенты по разные стороны моста смогут узнать аппаратный адрес назначения (зная заранее IP). Ip пригодится для более высоких уровней.
Но есть же такая вещь как маска подсети, которая выделяет из IP адрес сети и адрес хоста в этой сети.
Т.е. например, мой IP 10.5.5.10 и маска 255.255.255.128.
Мне нужно сформировать ARP-запрос к адресу 10.254.1.1 с маской 255.0.0.0, чтобы узнать его mac адрес. Но если я ввожу в браузере например 10.254.1.1, то скорее всего формируется запрос к 10.254.1.1 с маской 255.255.255.128 (широковещательный ff:ff:ff:ff:ff:ff), т.е. мост прокинет ARP запрос в подсеть №2, но маска соответствовать не будет. Но глядя на формат кадра ARP запроса, видно что в заголовке он переносит информацию о IP отправителя и IP назначения (по 4 байта каждое поле) без каких либо масок подсети. Отсюда делаю вывод, что узел назначения корректно получит ARP-запрос и корректно выработает ARP-ответ, который получит первый хост. Хотелось бы через iptables пропускать IPv4 пакеты, и там для них создавать правила...
Все таки наверное придется как-то "делать" таблицу маршрутизации для br0, в соответствии с портами моста, но как?
И вобще, я так понимаю маска подсети служит только для генерирования различных широковещательных запросов.
Просто предчувствие у меня ккакое-то что можно "маршрутизировать на канальном уровне", вопрос в том, ложное ли оно?

Llama · Сообщение **Llama** » 09 апр 2006, 11:39

cranium, естестенно. мска подсети ни в IP ни ARP пакетах не существует. Она существует только в таблицах маршрутизации

Можно например классифицировать и помечать пакеты на канальном уровне и разрулитьвать из через таблицы таршрутизации на сетевом уровне.

cranium · Сообщение **cranium** » 09 апр 2006, 12:34

хм... из таблиц маршрутизации у меня сечас одна запись, связанная с br0 (что-то вроде 10.5.5.0 netmask 255.255.255.127 dev br0), можно ли еще добавить подсетей на этот br0 в таблицах маршрутизации, будет ли оно работать?
типа 10.0.0.0 netmask 255.0.0.0 dev br0
10.5.5.0 netmask 255.255.255.127 dev br0
192.168.1.0 netmask 255.255.255.0 dev br0

Llama · Сообщение **Llama** » 09 апр 2006, 13:22

естественно.
ссылку на LARTC я давал в самом начале

cranium · Сообщение **cranium** » 09 апр 2006, 13:30

, спс
вчера ЧП случилося... открыл я доступ на мосте во всех цепочках моему мак-адресу, хм... работал под рутом, нужно было удалить правило из таблицы broute цепочки BROITING, удалил я его....
ebtables -t broute -D BROUTING 2
заем случайно нажал, клавишу со стрелкой вверхой и enter машинально(следом ишло правила разрешения трафика с моего мак)........

. Теперь вот надо владельца квартиры у кого серв стоит ждать). Можно ли как-то работать не под рут, добавляя новые правила в цепочки, но не запрещая доступ к старым, предустановленным заранее?

Llama · Сообщение **Llama** » 09 апр 2006, 13:35

думаю что нет...
Единственный вариант - "рабочие" правила держать не в основных цепочках, и псячески перестраховываться - типа явного разрешения ssh в начале цепочки.

cranium · Сообщение **cranium** » 09 апр 2006, 16:08

Прочитал это: http://cebka.pp.ru/my/iproute2.txt
Про LARTC я вначале не так понял, читал это http://mailman.ds9a.nl/pipermail/lartc/, вместо положенного HOWTO. Пока что на скорую руку набросал по аналогии с прочтенной статьей следующее:
$ ifconfig br0:1 10.5.5.100 netmask 255.0.0.0 up #даем второй IP мосту, чтобы был виден для второй подсети (изначально был 10.5.5.100, с маской 255.255.255.128)
$ echo 500 Lan1ToLan2 >> /etc/iproute2/rt_tables
$ echo 501 Lan2ToLan1 >> /etc/iproute2/rt_tables #создаем таблицы для правил маршрутизации пакетов
$ iptables -A PREROUTING -i eth0 -s 10.5.5.0/25 -d 10.0.0.0/8 -t mangle -j MARK --set-mark 12 #метим пакеты идущие из lan1 в lan2 меткой 12
$ iptables -A PREROUTING -i eth1 -s 10.0.0.0/8 -d 10.5.5.0/25 -t mangle -j MARK --set-mark 21 #метим пакеты идущие из lan2 в lan1 меткой 21
$ ip rule add fwmark 12 table Lan1ToLan2 #если метка на пакете 12, читаем правила из таблицы Lan1ToLan2 и применяем их к пакету
$ ip rule add fwmark 21 table Lan2ToLan1 # аналогично
$ ip route add default via 10.5.5.100 dev br0:1 table Lan1ToLan2 # заполняем таблицу Lan1ToLan2 правилом, следуя которому пакеты (отобранные по метке 12) должны отправлятся через интерфейс br0:1 |в этом месте я неуверен, будет ли работать br0:1|
$ ip route add default via 10.5.5.100 dev br0 table Lan2ToLan1 #аналогично...

Есть сомнения по поводу br0, ведь в данном случае в него входят 3 адаптера, т.е. если сервер будет следовать правилам, то пакеты будут повторятся на всех 3 портах!? А можно ли зделать так: eth0, eth1, eth2 устанавливаются в 0.0.0.0 (чтобы затем из них создать прозрачный мост), а затем на каждый eth сделать нечто подобное: eth0:1 eth1:1 eth2:1 со своим IP, ну и затем подредактировать вышеописанные команды.?

Llama · Сообщение **Llama** » 09 апр 2006, 19:46

гм, вместо ifconfig для единообразия рекомендую использовать ip address add 1.2.3.4 ..... dev br0
Насчет Есть сомнения по поводу br0, ведь в данном случае в него входят 3 адаптера, т.е. если сервер будет следовать правилам, то пакеты будут повторятся на всех 3 портах!?
Они появятся на br0 где согласно ARP будет определен destination MAC и согласно алгоритму прозрачного моста пакеты уйдут по нужному интерфейсу.

cranium · Сообщение **cranium** » 09 апр 2006, 20:00

Llama, точно, пакеты же на маршрутизаторе при переходе к мосту инкапсулируются в кадры ethernet... Спасибо за помощь, должно получится), ну и в автозагрузку как-нить это все поместить.
кстати насчет параметра /proc/sys/net/ipv4/ip_forward, то, если мне не изменяет память, в статье которую читал и на основе которой были подобраны правила, выставлен 0. Это нормально?

Llama · Сообщение **Llama** » 09 апр 2006, 22:30

cranium, как именно статья имеется ввиду? Если не используется ip-маршрутизаци, то этот параметр действительно не нужен.

cranium · Сообщение **cranium** » 10 апр 2006, 08:41

Не забывайте также о правильной настройке брандмауэра, а также, если
имеется несколько подсетей, желательно убедиться, что выключена прямая
передача пакетов из подсети в подсеть (т.е. если пакет направлен в другую
подсеть, он не должен передаваться на другой сетевой интерфейс без
обработки):

# echo 0 > /proc/sys/net/ipv4/ip_forward

В остальном, думаю разрешить передачу ARP через мост (хотя есть такой нюанс: неоднократно наблюдал, как машина заражнная вирусом рассылает ARP-запросы на какие-то несуществующие адреса, причем в строго последовательной форме). Протоколы IPv4 маршрутизировать, что даст большую гибкость в управлении, возможно еще NetBEUI разрешить через мост

cranium · Сообщение **cranium** » 10 апр 2006, 22:42

Проблемка небольшая... ведь получается каждому узлу из определенной подсети придется прописать в качестве шлюза Ip сервера7 Этот вариант не проходит... Могу "заставить" выставить шлюз только своих пользователей, а как тогда сделать видимыми пользователей через сервер.

Llama · Сообщение **Llama** » 10 апр 2006, 23:39

Либо NAT либо никак

NAT по своей прирле полупрозрачен, через него далеко не все может работать, к сожалению.