Security Lab



Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти  
Форум » Администрирование » UNIX системы
Страницы: 1 2 След.
RSS
Port Routing
 
#1
Это нравится:0Да/0Нет
05.11.2004 18:45:36
Некоторое время я мучаюсь с поиском решения. Исходные данные: RH 7.3, на машине подняты eth0 и ppp0
Оба интерфейса разными путями смотрят в инет.
Есть особенность. ppp0 - медленный (относительно), но на нем я могу пробится по любым портам (ssh, Игры и т.д.)
eth0 - значительно быстрее, но позволяет коннктиться только к определенным портам (dports 80, 10, 25, 3128)
Этот же компутер является гейтвэем для локальной сети.
Хочется.. чтоб трафик к/от 80, 25, 110 портов ходил через eth0, а все остальные порты ходили через ppp0
если можно с конкретным примером. Как я понимаю бороться нужно с ip, но пока не получается.
Зараннее благодарю за помощь

---------------------------------
от модератора: как вы можете объяснить совпадение слово в слово этого же вопроса в другой конференции?
---------------------------------
 
 
 
#2
Это нравится:0Да/0Нет
05.11.2004 18:50:41
посмотри внимательно на iptables --- сдается мне оно это умеет....
 
 
 
#3
Это нравится:0Да/0Нет
05.11.2004 18:54:09
delirium:
Так тебе кажется, или оно умеет ?
Насколько я понимаю, то iptables не занимается роутингом. Да, я могу помечать выборочно пакеты по любым признакам, но дальше мне нужно чтоб "что-то" адекватно реагировало на метки. Как я понимаю реализуется это iproute2, и конфигурится ip. Но я не могу найти ниодного примера.
 
 
 
#4
Это нравится:0Да/0Нет
05.11.2004 18:59:44
Уточняю детали:
Мне не нужно перенаправлять пакет по другому адресу или порту. Мне нужно направить пакет именно туда куда он должен идти, только в одном случае через ppp0 а в другом через eth0 (зависит от порта)
Ну например: обычный (привычный) роутинг - по IP назначения. Т.е. ты указываешь например IP адреса такой-то сети должны ходить по такому-то интерфесу. Тут тоже самое, но в качестве условия должны быть порты назначения.
 
 
 
#5
Это нравится:0Да/0Нет
05.11.2004 19:02:04
Должно быть примерно так:
#iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 25 -j MARK --set-mark 1
-пометили пакеты
Далее рутинг:
# echo 201 mail.out >> /etc/iproute2/rt_tables
# ip rule add fwmark 1 table mail.out
# ip rule ls
0: from all lookup local
32764: from all fwmark 1 lookup mail.out
32766: from all lookup main
32767: from all lookup default

# /sbin/ip route add default via $ip_address dev ppp0 table mail.out

Это фрагмент из "Linux Advanced Routing & Traffic Control HOWTO", где я его взял не помню .
 
 
 
#6
Это нравится:0Да/0Нет
05.11.2004 19:10:54
смотреть надо на iptables (-j MARK) и пакет iproute2.
Идеология такая:
1)iptables помечает интересующие нас пакеты.
2)iproute2 на основе меток iptables выполняет маршрутизацию.
короче, читаем тут
PS: а как такое сделать на *BSD?
 
 
 
#7
Это нравится:0Да/0Нет
05.11.2004 19:13:49
пред. сообщение от меня.
2delirium:немного опередил ;)
2boffin: зовётся сиё не "Port routing", А "source routing", т.е. маршрутизация от источика.
PS: boffin, простите, вы - бот?
вопрос один в один
 
 
 
#8
Это нравится:0Да/0Нет
05.11.2004 19:25:19
Схема с маркировкой и маршрутизацией по маркерам действительно работает, только для ее использования может потребоваться заново собрать ядро, поскольку требуемые опции не всегда включены в распространяемых с дистрибутивами ядрах. В ядре нужно включить опцию MARK target support

Маршрутизировать по маркерам умеет, насколько мне известно, не только iproute2. Дополнительную информацию можно найти здесь
 
 
 
#9
Это нравится:0Да/0Нет
05.11.2004 19:40:37
мне кажется надо посмотреть на опцию iptables REDIRECT

source routing никак не поможет в решении данного вопроса. source routing это лишь специальный бит в теле IP пакета, который означает что в поле OPTIONS есть явное указание всей последовательности маршрутизаторов, которые пакет должен пройти на своем пути. Маршрутизаторы только отрабатывают выбранный маршрут, осуществляя коммутацию пакетов, то есть передачу их с одного порта на другой. Теоретически алгоритм Source Routing применяется в сетях IP только для отладки, поэтому я обычно рекомендую сразу запрещать такие пакеты в сети, чтобы никому не захотелось "отладить" вашу сеть. На Cisco интерфейсах это делает команда
no ip source-route
 
 
 
#10
Это нравится:0Да/0Нет
05.11.2004 19:53:49
поможет. дело в том, что на самом деле никаких отметок в пакете не делается и fw-метка существует только в пределах интерфейса.
(т.е. фактически об этом знает только ядро, а идея с метками - лишь для наглядности).
 
 
 
#11
Это нравится:0Да/0Нет
05.11.2004 20:00:19
Цитата
ksiva пишет:
мне кажется надо посмотреть на опцию iptables REDIRECT
Увы, не подходит REDIRECT для этого.
Код
Операция REDIRECT позволяет переправлять пакеты и потоки трафика на данный хост. Операция может использоваться в цепочках PREROUTING и OUTPUT таблицы nat, а также пользовательских цепочках, которые могут вызываться только из указанных цепочек. При использовании REDIRECT изменяется IP-адрес получателя и пакеты перенаправляются маршрутизатором на себя. Опция

--to-ports port[-port]

позволяет задать порт или диапазон портов, куда будут перенаправляться пакеты. Эту опцию можно использовать только в правилах, задающих протокол -p tcp или -p udp.

Цитата
ksiva пишет:

source routing никак не поможет в решении данного вопроса. source routing это лишь специальный бит в теле IP пакета, который означает что в поле OPTIONS есть явное указание всей последовательности маршрутизаторов, которые пакет должен пройти на своем пути.
Написанное о source routing совершенно правильно, но вывод делается не совсем корректный. Source routing можно использовать для решения этой задачи, но, увы, только теоретически, поскольку в этом случае пользовательские приложения или стек протоколов на клиентской машине должны задавать маршрут, а обычные приложения этого как правило не умеют. Кроме того, опции source routing и сам маршрут не всегда обрабатываются маршрутизаторами, поэтому судьба таких пакетов слабо предсказуема.
 
 
 
#12
Это нравится:0Да/0Нет
05.11.2004 20:08:21
Цитата
^rage^ пишет:
поможет. дело в том, что на самом деле никаких отметок в пакете не делается и fw-метка существует только в пределах интерфейса.
(т.е. фактически об этом знает только ядро, а идея с метками - лишь для наглядности).
Это все-таки не source routing, поскольку отправитель не задает маршрута и не используется опций source routing в пакетах, равно как и маршрут в пакетах не указывается. В документации ядра Linux такая штука зовется use netfilter MARK value as routing key (опция IP_ROUTE_FWMARK в параметрах конфигурации ядра.
Применительно к описанной boffin ситуации я бы назвал это destination port based routing - маршрутизация в зависимости от порта получателя.
О наличии метки (маркера) знает не только ядро, эта информация через структуру skb доступна и для приложений пользовательского пространства.
 
 
 
#13
Это нравится:0Да/0Нет
05.11.2004 20:20:06
nmalykh, мне кажется мы слишком усложняем. Вопрос надо решить на одном маршрутизаторе-компьютере. Тем более что вы сами намекнули, про то, что мы можем использовать REDIRECT для tcp. А нам нужно перенаправлять только TCP протокол на порт 80, 25, 110. UDP 80, 25, 100 пусть себе в ppp0 уходят.
 
 
 
#14
Это нравится:0Да/0Нет
05.11.2004 20:20:10
да, зовётся оно не так. А про ядро не совсем точно выразил мысль: имелось в виду что метка существует в пределах хоста.
PS: а raw таблицы у кого-нибудь работают?
PPS: нашёл новый для себя таргет:
------------------------------------
CLASSIFY
       This  module  allows you to set the skb->priority value (and thus classify the packet into a
       specific CBQ class).

       --set-class MAJOR:MINOR
               Set the major and minor class value.
------------------------------------
2ksiva: редирект не годится. кусок мана:
------------------------------------
REDIRECT
       This  target  is only valid in the nat table, in the PREROUTING and OUTPUT chains, and user-
       defined chains which are only called from  those  chains.   It  alters  the  destination  IP
       address  to  send  the packet to the machine itself (locally-generated packets are mapped to
       the 127.0.0.1 address).
------------------------------------
 
 
 
#15
Это нравится:0Да/0Нет
05.11.2004 20:36:05
Цитата
ksiva пишет:
nmalykh, мне кажется мы слишком усложняем. Вопрос надо решить на одном маршрутизаторе-компьютере. Тем более что вы сами намекнули, про то, что мы можем использовать REDIRECT для tcp. А нам нужно перенаправлять только TCP протокол на порт 80, 25, 110. UDP 80, 25, 100 пусть себе в ppp0 уходят.
Дело в том, что REDIRECT перенаправляет пакеты только на адрес того хоста, на котором запущена (т. е., этот шлюз делает себя конечным получателем).

Кроме того, изначальная постановка задачи была немножко другой (IMHO) - нужно было отправлять все пакеты, адресованные в порты, отличные от указанного набора, на интерфейс ppp0, а прочие (указанные в списке boffin) и так уйдут в дефолтный интерфейс.

Поэтому мне и представляется разумным пометить все нужные пакеты и дальше создать для пакетов с маркером маршрут в ppp0. Все делается одной строкой в правилах iptables и одним дополнительным маршрутом в таблице для пакетов.
 
 
 
#16
Это нравится:0Да/0Нет
05.11.2004 20:54:58
Цитата
^rage^ пишет:

PS: а raw таблицы у кого-нибудь работают?
Я как-то любопытства ради посмотрел - работает эта таблица без проблем. Потребности использования для реальных задач пока не возникало, поэтому особо и не экспериментировал.

Мне представляется эффективным использование этой таблицы для снижения нагрузки на систему отслеживания соединений за счет отключения (NOTRACK) контроля. Например, если за брандмауэром стоит web-сервер с большим трафиком, это поможет снизить нагрузку на брандмауэр.
 
 
 
#17
Это нравится:0Да/0Нет
05.11.2004 21:06:38
Цитата
nmalykh пишет:
 
Цитата
^rage^ пишет:

PS: а raw таблицы у кого-нибудь работают?
Я как-то любопытства ради посмотрел - работает эта таблица без проблем.
а подробнее можно? Чем/как смотрели?
Цитата
nmalykh пишет:

Мне представляется эффективным использование этой таблицы для снижения нагрузки на систему отслеживания соединений за счет отключения (NOTRACK) контроля. Например, если за брандмауэром стоит web-сервер с большим трафиком, это поможет снизить нагрузку на брандмауэр.
именно для этого она и нужна.
 
 
 
#18
Это нравится:0Да/0Нет
05.11.2004 21:41:03
Цитата
^rage^ пишет:
 
Цитата
nmalykh пишет:
 
Цитата
^rage^ пишет:

PS: а raw таблицы у кого-нибудь работают?
Я как-то любопытства ради посмотрел - работает эта таблица без проблем.
а подробнее можно? Чем/как смотрели?
Честно говоря, рассказывать особо и не о чем - я просто сделал тупо, как сказано в описании NOTRACK
Код
iptables -t raw -A PREROUTING -d 1.2.3.4 -p tcp --dport 80 -j NOTRACK
iptables -t raw -A PREROUTING -s 1.2.3.4 -p tcp --sport 80 -j NOTRACK
...

iptables -A FORWARD -m state --state UNTRACKED -j ACCEPT

и смотрел файл /proc/net/ip_conntrack. Убедился, что все работает и на этом закончил. Вот, собственно, и весь эксперимент. Делалось все на ядре 2.6.8 с iptables 1.2.11 и последней версией POM.

Мне представляется весьма продуктивной и другая операция таблицы raw - TRACE. Она метит пакеты и для такого пакета делаются записи в лог (или ulog) при каждом совпадении с условиями любого из последующих правил (учитывая, что raw работает первой, можно смело говорить - всех правил). При отлаживании сложных конфигураций это может быть вемьма полезно. Но, увы, руки пока не дошли проверить эту возможность в работе.
 
 
 
#19
Это нравится:0Да/0Нет
05.11.2004 21:49:51
Цитата
^rage^ пишет:

Цитата
nmalykh пишет:

Мне представляется эффективным использование этой таблицы для снижения нагрузки на систему отслеживания соединений за счет отключения (NOTRACK) контроля. Например, если за брандмауэром стоит web-сервер с большим трафиком, это поможет снизить нагрузку на брандмауэр.
именно для этого она и нужна.
Согласен, но у меня просто нет такой нагрузки, чтобы это стало актуальным. И судя по моему брандмауэру таблицы в которых число правил превышает 10К (фильтрация спама в основном) не очень сильно нагружают машинку при уровне трафика порядка гигабайта в сутки. А большего трафика у меня пока нет в доступном окружении.
 
 
 
#20
Это нравится:0Да/0Нет
05.11.2004 22:02:00
Цитата
nmalykh пишет:

и смотрел файл /proc/net/ip_conntrack. Убедился, что все работает и на этом закончил. Вот, собственно, и весь эксперимент. Делалось все на ядре 2.6.8 с iptables 1.2.11 и последней версией POM.
аналогично и близко к ответу на мой вопрос. А какие записи говорят о том что "ок, всё работает"?
 
 
 
Страницы: 1 2 След.
Читают тему