Доброго времени суток!Возникла проблема:
есть роутер и два провайдера на нем:eth1: 192.168.75.200 gw 192.168.75.1 (default) - 1-й пров
eth3: 192.168.82.200 gw 192.168.82.1 - 2-й пров
192.168.80.0/24, 192.168.81.0/24, 192.168.83.0/24 - локальная сеть (не спрашивайте почему так криво - так получилось ;) )Так вот, при помощи iproute2+iptables все разруливается между юзверями нормально - проблем ноль:
iptables -A POSTROUTING -d ! 192.168.0.0/255.255.0.0 -o eth2 -j SNAT --to-source 192.168.82.200
#ip route list
192.168.81.0/24 dev eth1 proto kernel scope link src 192.168.81.1
192.168.80.0/24 dev eth0 proto kernel scope link src 192.168.80.1
192.168.83.0/24 dev eth4 proto kernel scope link src 192.168.83.1
192.168.82.0/24 dev eth2 proto kernel scope link src 192.168.82.200
192.168.75.0/24 dev eth3 proto kernel scope link src 192.168.75.200
127.0.0.0/8 dev lo scope link
default via 192.168.75.1 dev eth3 metric 1
#ip rule list
0: from all lookup local
10: from 192.168.81.16 to 192.168.0.0/16 lookup main
15: from 192.168.81.16 lookup reserv
32766: from all lookup main
32767: from all lookup default# ip route show table reserv
default via 192.168.82.1 dev eth2
Но... возникла необходимость на сам роутер подать и-нет не через 75.200, а через 82.200Вот тут то я и застрял:
ip rule add from 192.168.82.200 to 192.168.0.0/16 table main priority 10
ip rule add from 192.168.82.200 table reserv priority 15
ip route add default via 192.168.82.1 dev eth2 table reserv
ip route flush cacheрезультата - ноль. Все равно лезет на через 75.1
Курение манов результата тоже не дало.
Вопрос: как заставить сам роутер ходить через 82.1 а не через 75.1 ?
>Доброго времени суток!
>
>Возникла проблема:
>есть роутер и два провайдера на нем:
>
>eth1: 192.168.75.200 gw 192.168.75.1 (default) - 1-й пров
>eth3: 192.168.82.200 gw 192.168.82.1 - 2-й пров
>192.168.80.0/24, 192.168.81.0/24, 192.168.83.0/24 - локальная сеть (не спрашивайте почему так криво -
>так получилось ;) )
>
>Так вот, при помощи iproute2+iptables все разруливается между юзверями нормально - проблем
>ноль:
>
>
>iptables -A POSTROUTING -d ! 192.168.0.0/255.255.0.0 -o eth2 -j SNAT --to-source 192.168.82.200
>
>
>
>#ip route list
>192.168.81.0/24 dev eth1 proto kernel scope link src 192.168.81.1
>
>192.168.80.0/24 dev eth0 proto kernel scope link src 192.168.80.1
>
>192.168.83.0/24 dev eth4 proto kernel scope link src 192.168.83.1
>
>192.168.82.0/24 dev eth2 proto kernel scope link src 192.168.82.200
>
>192.168.75.0/24 dev eth3 proto kernel scope link src 192.168.75.200
>
>127.0.0.0/8 dev lo scope link
>default via 192.168.75.1 dev eth3 metric 1
>
>
>#ip rule list
>0: from all lookup local
>10: from 192.168.81.16 to 192.168.0.0/16 lookup main
>15: from 192.168.81.16 lookup reserv
>32766: from all lookup main
>32767: from all lookup default
>
># ip route show table reserv
>default via 192.168.82.1 dev eth2
>
>
>Но... возникла необходимость на сам роутер подать и-нет не через 75.200, а
>через 82.200
>
>Вот тут то я и застрял:
>
>ip rule add from 192.168.82.200 to 192.168.0.0/16 table main priority 10
>
>ip rule add from 192.168.82.200 table reserv priority 15
>ip route add default via 192.168.82.1 dev eth2 table reserv
>ip route flush cache
>
>результата - ноль. Все равно лезет на через 75.1
>
>Курение манов результата тоже не дало.
>
>Вопрос: как заставить сам роутер ходить через 82.1 а не через 75.1
>?Ну правильно он лезет по таблице main.
Если не править таблиц то rules'ов будет маловато.
замаркировать все пакеты в цепочке OUTPUT потом их отловить и отправить в соответствующую таблицу.
Или проще поменять main и reserv местами.
По адресу источника отловить саму машину... :(
У меня примерно такая же проблема. Linux-router (он же web-server, smtp-server, ftp-server) с сетевухой в локалную сеть (eth0), и два канала ppp0(дорогой со стат. айпи) и ppp1(дешевый с динам. айпи).
Дефолтовый путь - через дешевый канал 1. И надо сделать так, чтоб трафик, генерируемый smtp-, ftp-, web-серверами (которые находятся на самом роутере), шел через дорогой канал.
Например, чтоб попытаться завернуть трафик (рассылка обновлений) от моего сендмэйла на дорогой канал:
iptables -t mangle -I PREROUTING -p tcp -i ppp1 --dport 25 -j MARK --set-mark 1
ip rule add fwmark 1 table expensive
ip route add default via xxx.xxx.xxx.xxx dev ppp0 table expensiveНо проблема в том, что пакет помечаеться уже после того, как пришел на интерфейс по умолчанию, и переправить его на другой - невозможно (во всяком случае, я не понимаю как).
Укажите, плз, как решить эту проблему...
Может, я несколько неправильно формулирую вопрос, но мне надо задать шлюз по умолчанию для "маршрутизации по порту назначения" (понятно, что в ip не фигурируют порты). А проблема в том, что решение о маршрутизации пакетов, которые генерируются локальным процессом (программой-сервером), принимается до того, как эти пакеты попыдут в таблицы iptables.
>Может, я несколько неправильно формулирую вопрос, но мне надо задать шлюз по
>умолчанию для "маршрутизации по порту назначения" (понятно, что в ip не
>фигурируют порты). А проблема в том, что решение о маршрутизации пакетов,
>которые генерируются локальным процессом (программой-сервером), принимается до того, как эти пакеты
>попыдут в таблицы iptables.
пришла такая бешенная идея - может, как-то можно использовать u32 classifier...
>У меня примерно такая же проблема. Linux-router (он же web-server, smtp-server, ftp-server)
>с сетевухой в локалную сеть (eth0), и два канала ppp0(дорогой со
>стат. айпи) и ppp1(дешевый с динам. айпи).
>Дефолтовый путь - через дешевый канал 1. И надо сделать так, чтоб
>трафик, генерируемый smtp-, ftp-, web-серверами (которые находятся на самом роутере), шел
>через дорогой канал.
>Например, чтоб попытаться завернуть трафик (рассылка обновлений) от моего сендмэйла на дорогой
>канал:
>iptables -t mangle -I PREROUTING -p tcp -i ppp1 --dport 25 -j
>MARK --set-mark 1
>ip rule add fwmark 1 table expensive
>ip route add default via xxx.xxx.xxx.xxx dev ppp0 table expensive
>
>Но проблема в том, что пакет помечаеться уже после того, как пришел
>на интерфейс по умолчанию, и переправить его на другой - невозможно
>(во всяком случае, я не понимаю как).
>Укажите, плз, как решить эту проблему...1. Если запрос пришел из внешнего мира на интерфейс А то его надо обрабатывать на интерфейсе А
По этой прчине входящий паке не перезапихнуть в другой интерфейс.
2. Сессии к-е устанавливает наш сервер они по умолчанию обрабатываются таблицей main.
если маркировать их то только так:
iptables -t mangle -A OUTPUT ...... --mark....
iptables -t mangle -I OUTPUT -p tcp --dport 25 -j MARK --set-mark 1
Метить надо то, что сервер обрабатывает.
И ловить их:
ip rule add fwmark 1 table expensiv
т.о. все свои сессии на удаленный порт 25 будут обрабатываться через таблицу expensiv
ip rule add fwmark 1 table expensiveВходящие сессии контролировать не возможно (в данном случае):
относительно 25 порта прописать MX на необходимый линк и к-й не хотим обрабатывать -j DROP
iptables -t mangle -I OUTPUT -p tcp --dport 25 -j MARK --set-mark 1
но интерфейс надо же указать? иначе будет замкнутый круг, будут метиться все пакеты на 25 порт. я попоробовал, это не работает.
кроме того, я думаю, что поздно метить пакеты для маршрутизации, когда принято решение об их маршрутизации (т.е. пакет вышел из цепочки PREROUTING).
>iptables -t mangle -I OUTPUT -p tcp --dport 25 -j MARK --set-mark
>1
>но интерфейс надо же указать? иначе будет замкнутый круг, будут метиться все
>пакеты на 25 порт. я попоробовал, это не работает.
>кроме того, я думаю, что поздно метить пакеты для маршрутизации, когда принято
>решение об их маршрутизации (т.е. пакет вышел из цепочки PREROUTING).Не все а только те к-е отправляет сам хост.
В том то все и дело, что надо метить в цепочке OUTPUT без привязки к интерфейсу.
А интерфейс выхода это результат обработки метки.
OUTPUT - обрабатывает только пакеты к-е отправляет сама машина и решение о маршрутизации на данном этапе еще не приято.http://www.opennet.me/docs/RUS/iptables/ - Глава 3. Порядок прохождения таблиц и цепочек
Система 100% рабочая. У меня работает без проблем.
Если не работает - проверить не перемаркируются ли они в последствии.
>>iptables -t mangle -I OUTPUT -p tcp --dport 25 -j MARK --set-mark
>>1
>>но интерфейс надо же указать? иначе будет замкнутый круг, будут метиться все
>>пакеты на 25 порт. я попоробовал, это не работает.
>>кроме того, я думаю, что поздно метить пакеты для маршрутизации, когда принято
>>решение об их маршрутизации (т.е. пакет вышел из цепочки PREROUTING).
>
>Не все а только те к-е отправляет сам хост.
>В том то все и дело, что надо метить в цепочке OUTPUT
>без привязки к интерфейсу.
>А интерфейс выхода это результат обработки метки.
>OUTPUT - обрабатывает только пакеты к-е отправляет сама машина и решение о
>маршрутизации на данном этапе еще не приято.
>
>http://www.opennet.me/docs/RUS/iptables/ - Глава 3. Порядок прохождения таблиц и цепочек
>
>Система 100% рабочая. У меня работает без проблем.
>Если не работает - проверить не перемаркируются ли они в последствии.___________ Решил добавить пример из рабочей системы _______________________
/sbin/iptable -t mangle -A OUTPUT -p tcp -d ! 192.168.0.0/16 --dport 25 -j MARK --set-mark 0x64
/sbin/ip rule add fwmark 0x64 table mailtable
Спасибо, попробую. Из мануала, от локальных процессов:
Шаг Таблица Цепочка Примечание
1 Локальный процесс
2 Принятие решения о маршрутизации
3 mangle OUTPUT Здесь производится внесение изменений в заголовок пакета.
4 nat OUTPUT Эта цепочка используется для трансляции сетевых адресов (NAT)
5 Filter OUTPUT Здесь фильтруется исходящий траффик.
6 mangle POSTROUTING
7 nat POSTROUTING
8 Сетевой интерфейс (например, eth0)
Похоже уважаемый vbv неправ. Решение о маршрутизации принимается ДО!!! начала прохождения пакетом цепочек интерфейса. Просто у меня такая-же проблема и ваш совет абсолютно не работает. Приведу свои аргументы:
1. в цепочке mangle output маркирую все пакеты на 25 порт
2. далее смотрю в LOG в той-же цепочке, а они уже пошли в интерфейс по дефолту.Так что подобный финт для пакетов отправляемых с локальной машины не катит. буду искать другой выход.
>Похоже уважаемый vbv неправ. Решение о маршрутизации принимается ДО!!! начала прохождения пакетом
>цепочек интерфейса. Просто у меня такая-же проблема и ваш совет абсолютно
>не работает. Приведу свои аргументы:
>1. в цепочке mangle output маркирую все пакеты на 25 порт
>2. далее смотрю в LOG в той-же цепочке, а они уже пошли
>в интерфейс по дефолту.
>
>Так что подобный финт для пакетов отправляемых с локальной машины не катит.
>буду искать другой выход.
Ничего подобного!!!
Повторюсь: У меня работает!
Что значит "смотрю в LOG"? В той же цепочке?
И что значит пошли в интерфейс по дефоулту?Если не работает - давайте разбираться.
>>Похоже уважаемый vbv неправ. Решение о маршрутизации принимается ДО!!! начала прохождения пакетом
>>цепочек интерфейса. Просто у меня такая-же проблема и ваш совет абсолютно
>>не работает. Приведу свои аргументы:
>>1. в цепочке mangle output маркирую все пакеты на 25 порт
>>2. далее смотрю в LOG в той-же цепочке, а они уже пошли
>>в интерфейс по дефолту.
>>
>>Так что подобный финт для пакетов отправляемых с локальной машины не катит.
>>буду искать другой выход.
>
>
>Ничего подобного!!!
>Повторюсь: У меня работает!
>Что значит "смотрю в LOG"? В той же цепочке?
>И что значит пошли в интерфейс по дефоулту?
>
>Если не работает - давайте разбираться.И еще конфигурацию меток(полный вид команды) и рулесы в студию.
Точно не работает, т.к. решение о маршрутизации пакетов от локальных серверов принимается сразу же, как появился соответствующий пакет, и повлиять на это сложно (т.к. непонятно с какого интерфейса он идет и с какого адреса). См. таблицу, которую я привел выше. Использовал различные вариации на темуiptable -t mangle -A OUTPUT -p tcp -d ! $LOCALNET --dport 25 -j MARK --set-mark 0x64
ip rule add fwmark 0x64 table expensive
ip route add default via expesive_gate_ip dev ppp0 table expensive
ip route flush cacheПакеты идут по маршруту по умолчанию и действительно маркируются в цепочке output, но никуда не перенаправляются, и с этой меткой покидают интерфейс по умолчанию (метка уничтожается). Вот так-то (((.
Временно проблему решил так: указал smtp серверу смартрелей на сервер провайдера, добавил source route
ip rule add from expensive_inteface_ip table expensive
ip rule add to prov_smart_relay_ip table expensive
ip route add default via expesive_gate_ip dev ppp0 table expensive
ip route flush cache
>Точно не работает, т.к. решение о маршрутизации пакетов от локальных серверов принимается
>сразу же, как появился соответствующий пакет, и повлиять на это сложно
>(т.к. непонятно с какого интерфейса он идет и с какого адреса).
>См. таблицу, которую я привел выше. Использовал различные вариации на тему
>
>
>iptable -t mangle -A OUTPUT -p tcp -d ! $LOCALNET --dport 25
>-j MARK --set-mark 0x64
>ip rule add fwmark 0x64 table expensive
>ip route add default via expesive_gate_ip dev ppp0 table expensive
>ip route flush cache
>
>Пакеты идут по маршруту по умолчанию и действительно маркируются в цепочке output,
>но никуда не перенаправляются, и с этой меткой покидают интерфейс по
>умолчанию (метка уничтожается). Вот так-то (((.
>Временно проблему решил так: указал smtp серверу смартрелей на сервер провайдера, добавил
> source route
>ip rule add from expensive_inteface_ip table expensive
>ip rule add to prov_smart_relay_ip table expensive
>ip route add default via expesive_gate_ip dev ppp0 table expensive
>ip route flush cacheПосмотрел ближе:
Да в моем случае есть одно НО:
они уходят таки с сорцами из таблицы main.
Что у меня не вызвало проблем т.к. живу на своих адресах. :)
т.о.
Пакет таки обрабатывается соответствующей таблицей и запихиватется в правильный интерфейс но с неожиданным адресом srс который он действительно берет из главной таблицы. :(
Специально перестроил маршруты и протестил полный вариант.
Полечилось с добавлением:
iptables -t nat -I POSTROUTING -p tcp -d ! 192.168.0.0/16 --dport 25 -j SNAT --to-source $SOURCE_MAIL_TABLE
Стало уходить с правильным адресом источника и соответственно возвращаться через заявленный интерфейс.Проверено!
В таком случае полный вид выглядет так:
iptables -t nat -I POSTROUTING -p tcp --dport 25 -j SNAT --to-source $SOURCE_MAIL_TABLE
iptables -t mangle -I OUTPUT -p tcp --dport 25 -j MARK --set-mark 0x64
ip rule add fwmark 0x64 lookup mailtabletcpdump -vi $INTERFACE
показал правильные tcp сессии на нужном интерфейсе.PS: Вообще странно, что при обработке другой таблицей, подставляется не тот src адрес.
Хотя возможно так и должно быть.
Почитаю мануал - тогда напишу. Видимо это надо еще задать где-то.PPS: Хотя если уже смотреть в манипуляцию адресом источника - можно всего этого и не делать.
1. Иметь правильную таблицу для почтового линка.
2. Иметь правильные правила для адреса т.е.
ip rule add to $SOURCE_MAIL_TABLE lookup mailtable
ip rule add from $SOURCE_MAIL_TABLE lookup mailtable
3. Одну строчку с
iptables -t nat -I POSTROUTING -p tcp --dport 25 -j SNAT --to-source $SOURCE_MAIL_TABLE
И в маркировке надобность отпадает т.к. пакеты поймаются по адресу источника....
Не пробовал но скорее всего такой вариант имеет право на жизнь.
>PS: Вообще странно, что при обработке другой таблицей, подставляется не тот src
>адрес.
>Хотя возможно так и должно быть.
>Почитаю мануал - тогда напишу. Видимо это надо еще задать где-то.
Так и должно быть. И никак это не изменить. Посмотри внимательней, те пакеты, которые должны уходить через интерфейс, предназначенный для почты, уходят с интерфейса по умолчанию, но с правильным адресом для почтового интерфейса, а метка не действует. Т.е. исходящий трафик все равно идет по интерфейсу по умолчанию, а входящий - по соответствующему "правильному" интерфейсу...>ip rule add to $SOURCE_MAIL_TABLE lookup mailtable
>ip rule add from $SOURCE_MAIL_TABLE lookup mailtable
>3. Одну строчку с
>iptables -t nat -I POSTROUTING -p tcp --dport 25 -j SNAT --to-source
>$SOURCE_MAIL_TABLE
>И в маркировке надобность отпадает т.к. пакеты поймаются по адресу источника....
>Не пробовал но скорее всего такой вариант имеет право на жизнь.
На варианте с source routing я пока и остановился.
>>PS: Вообще странно, что при обработке другой таблицей, подставляется не тот src
>>адрес.
>>Хотя возможно так и должно быть.
>>Почитаю мануал - тогда напишу. Видимо это надо еще задать где-то.
>Так и должно быть. И никак это не изменить. Посмотри внимательней, те
>пакеты, которые должны уходить через интерфейс, предназначенный для почты, уходят с
>интерфейса по умолчанию, но с правильным адресом для почтового интерфейса, а
>метка не действует. Т.е. исходящий трафик все равно идет по интерфейсу
>по умолчанию, а входящий - по соответствующему "правильному" интерфейсу...
>
>>ip rule add to $SOURCE_MAIL_TABLE lookup mailtable
>>ip rule add from $SOURCE_MAIL_TABLE lookup mailtable
>>3. Одну строчку с
>>iptables -t nat -I POSTROUTING -p tcp --dport 25 -j SNAT --to-source
>>$SOURCE_MAIL_TABLE
>>И в маркировке надобность отпадает т.к. пакеты поймаются по адресу источника....
>>Не пробовал но скорее всего такой вариант имеет право на жизнь.
>На варианте с source routing я пока и остановился.Странно это :?( Скажи, а у тебя получилось если маркировать проходящие пакеты запихнуть их в другую таблицу?
Дело в том, что у меня они таки запихиваются в маилтабле используя маркировку от процесса (таблица OUTPUT)на сервере....
Возможно тут дело в настройке ядра и загруженных модулях.
Даже не могу придумать как это показать.... У меня работает с маркировкой без проблем....2.6.15 ядро ручной сборки Advanced routing вкопилен в ядро. Пачено только добавлением imq.
Distr - Slackware.
~# ip -V
ip utility, iproute2-ss05033
>Странно это :?( Скажи, а у тебя получилось если маркировать проходящие
>пакеты запихнуть их в другую таблицу?
>Дело в том, что у меня они таки запихиваются в маилтабле используя
>маркировку от процесса (таблица OUTPUT)на сервере....
>Возможно тут дело в настройке ядра и загруженных модулях.
>Даже не могу придумать как это показать.... У меня работает с маркировкой
>без проблем....
>
>2.6.15 ядро ручной сборки Advanced routing вкопилен в ядро. Пачено только добавлением
>imq.
>Distr - Slackware.
>~# ip -V
>ip utility, iproute2-ss05033
проходящие пакеты (не от локальных процессов) маркируются без проблем в таблице mangle цепочка PREROUTING и перенаправляются в нужный интерфейс
iptables -t mangle -I PREROUTING -p tcp --dport 25 -j MARK --set-mark 1
ip rule add fwmark 1 table tab1
ip route add default via xxx.xxx.xxx.xxx dev ppp0 table tab1
Это уж точно работает
>>Странно это :?( Скажи, а у тебя получилось если маркировать проходящие
>>пакеты запихнуть их в другую таблицу?
>>Дело в том, что у меня они таки запихиваются в маилтабле используя
>>маркировку от процесса (таблица OUTPUT)на сервере....
>>Возможно тут дело в настройке ядра и загруженных модулях.
>>Даже не могу придумать как это показать.... У меня работает с маркировкой
>>без проблем....
>>
>>2.6.15 ядро ручной сборки Advanced routing вкопилен в ядро. Пачено только добавлением
>>imq.
>>Distr - Slackware.
>>~# ip -V
>>ip utility, iproute2-ss05033
>проходящие пакеты (не от локальных процессов) маркируются без проблем в таблице mangle
>цепочка PREROUTING и перенаправляются в нужный интерфейс
>iptables -t mangle -I PREROUTING -p tcp --dport 25 -j MARK --set-mark
>1
>ip rule add fwmark 1 table tab1
>ip route add default via xxx.xxx.xxx.xxx dev ppp0 table tab1
>Это уж точно работаетНу тогда ХЕЗ.
Не могу объяснить причины не работоспособности в твоем случае.
У меня это живет без проблем и уже не один год.
Любые идеи приветствуются.
Были некоторые проблемы, когда настраивал - пакеты перемаркировались в другом месте для других целей (QoS). Но нашел причину и устранил - все стало в норму.
Заработало с пол-пинка. Даже вопросов не возникло.