Первый вопрос заключается в том, как организовать маршрутизацию таким образом, чтобы ответы на запросы, приходящие через определенного провайдера, скажем ровайдера 1, уходили через того же провайдера.
Давайте определим некоторые переменные. Пусть $IF1 будет именем первого интерфейса (if1 на рисунке), а $IF2 — именем второго. Тогда $IP1 будет IP адресом $IF1 , а $IP2 — IP адресом $IF2 . Далее, $P1 это IP-адрес шлюза провайдера 1, а $P2 — IP адрес шлюза провайдера 2. Наконец, $P1_NET это IP сеть, к которой принадлежит $P1 , а $P2_NET — сеть, к которой принадлежит $P2 .
Создадим две дополнительные таблицы маршрутизации, скажем T1 и T2 . Добавим их в файл /etc/iproute2/rt_tables . Теперь можно настроить эти таблицы следующими командами:
ip route add $P1_NET dev $IF1 src $IP1 table T1 ip route add default via $P1 table T1 ip route add $P2_NET dev $IF2 src $IP2 table T2 ip route add default via $P2 table T2
Ничего особо эффектного, маршрут к шлюзу и маршрут по-умолчанию через этот шлюз. Точно так же, как и в случае одного провайдера, но по таблице на каждого провайдера. Заметьте, что маршрута к сети, в которой находится шлюз достаточно, потому что он определяет как найти все хосты в этой сети, включая сам шлюз.
Теперь нужно настроить главную таблицу маршрутизации. Хорошо бы маршрутизировать пакеты для сетей провайдеров через соответствующие интерфейсы. Обратите внимание на аргумент `src’, который обеспечивает правильный выбор исходного IP-адреса.
ip route add $P1_NET dev $IF1 src $IP1 ip route add $P2_NET dev $IF2 src $IP2
Теперь задаем маршрут по умолчанию:
ip route add default via $P1
Зададим правила маршрутизации. Они будут отвечать за то, какая таблица будет использоваться при маршрутизации. Вы хотите, чтобы пакет с определенным адресом источника маршрутизировался через соответствующий интерфейс:
ip rule add from $IP1 table T1 ip rule add from $IP2 table T2
Этот набор команд обеспечивает маршрутизацию ответов через интерфейс, на котором был получен запрос.
Заметка читателя Рода Роака (Rod Roark): ‘ если $P0_NET это локальная сеть, а $IF0 — соответствующий ей интерфейс, желательно задать следующие команды:
ip route add $P0_NET dev $IF0 table T1 ip route add $P2_NET dev $IF2 table T1 ip route add 127.0.0.0/8 dev lo table T1 ip route add $P0_NET dev $IF0 table T2 ip route add $P1_NET dev $IF1 table T2 ip route add 127.0.0.0/8 dev lo table T2
Второй вопрос заключается в балансировке нагрузки между двумя провайдерами. Это не сложно, если у вас уже настроен раздельный доступ, описанный в предыдущем разделе.
Вместо выбора одного из провайдеров в качестве маршрута по-умолчанию, вы настраиваете т.н. многолучевой (multipath) маршрут. В стандартном ядре это обеспечит балансировку нагрузки между двумя провайдерами. Делается это следующим образом (повторюсь, мы основываемся на примере из раздела Раздельный доступ ):
ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \ nexthop via $P2 dev $IF2 weight 1
Результатом команды будет попеременный выбор маршрута по-умолчанию. Вы можете изменить параметр weight , так чтобы один из провайдеров получал большую нагрузку.
Обратите внимание, что балансировка не будет идеальной, так как она основывается на маршрутах, а маршруты кэшируются. Это означает, что маршруты к часто посещаемым сайтам не будут проходить через разных провайдеров.
вот у меня статика, и можно сделать так. подсети мне не нужны, нужна доступность хоста по 2м адресам. для динамических ip скрипт пишется в папку ifup.d
еще раз — 1. изучение iptables — полностью на вашей совести. пусть люди сами изучают 2. если понять фишку с маркировкой пакетов, то потом можно ее использовать при создании других правил как маршрутизации, так и фильтрации. считаю, что этот момент полезен и не столь очевиден при самостоятельном изучении как SNAT и MASQUERADE
>В очередной раз повторюсь, что использование SNAT в данном случае лучше чем >MASQUERADE. >Использование MASQUERADE вообще оправданно только в случае динамического IP на внешнем интерфейсе. > > >Не очень понимаю зачем нужно маркировать пакеты, если прямо в POSTROUTING можно >задавать условие -d
Уважаемый demon не могли бы вы привести кусок примера ?? просто получилось у меня только с использованием меток.. но он мешают при написании скрипта с шейпеньем. кстати неукого не завалялся скриптик 🙂 Т.З. дано два канала 1)eth1-унлим 2)eth2-обычный ну и мега сеть 10.x.x.x с внутренней маршрутизацией OSPF(L3 коммутаторы) где дефолтный гетвей наш линукс сервер. билинг создает правило 10.1.1.1 на первый интерфейси ограничиваем его 128к, а на второй интерфейс 10.1.1.2 и на скорость наплевать. сделал пока только первое. а вот с двумя интерфейсами уже нет так как метка уже стоит.
1.3 , rusya ( ok ), 16:40, 22/04/2008 [ответить] [﹢﹢﹢] [ · · · ]
+ / –
а какой айпишник указать в качестве гейта во второй локальной подсети? Или поднимать виртуальный интерфейс? Или что?
Странный пример в статье. На мой взгляд SNAT превосходит по производительности MASQUERADE, метки тоже не очень оправданы в принципи. Любую маршрутизацию которую надо сделать можно загнать в соответсвующие таблицы и не напрягать ядро левой работой с разбором меток. год назад делал объединение 5 каналов из одной подсети. К стати если случайно забанится один ипшник, то часть конектов будет попадать в мертвое соединение.
хм! а если надо одну и туже сеть например 192.168.0.0/24 пускать в инет по разному например 80 8080 и т.д. порты через одного прова а фтп почту и т.д. через другого как быть? и как интересно резолвится днс в данном случае если дефолтный маршрут только один у него и днс свой соответственно а второго прова свой днс который уже не резолвится если есть основной маршрут
сразу после строки ip route add $NET_INET1 dev $IF_INET1 src $IP_INET1 table T1 пишет: RTNETLINK answers: Invalid argument и Error: an inet adress is expected rather than «table»
#все пакеты, которые попали в цепочку POSTROUTING таблицы nat обрабатываем по двум правилам: $IPT -t nat -A POTROUTING -m mark —mark 10 -j MASQUERADE # натим все пакеты которые имеют метку 10 $IPT -t nat -A POTROUTING -m mark —mark 11 -j MASQUERADE # натим все пакеты которые имеют метку 11
POTROUTING заменить на POsTROUTING
далее в файле роутинг GW1=»1.1.1.1″ # гейт первого провайдера. GW2=»2.2.2.1″ # гейт второго провайдера.
заменить GW на GW_INET
кажется по мелочевке всё, это глупые ошибки, остальные ошибки можно увидеть тут сравнив ваш оригинал с моей рабочей версией: http://www.opennet.ru/openforum/vsluhforumID6/19056.html#0
объясните дураку как сделать доступным сервер в локалке по 2 провайдерам? я уже с ума сошел данным способом описанном здесь, да и вариантом попроще, доступен только сервер для 2 провайдеров, но не сервер в локальной сети
ip route add $INET_GATE dev $INET_IF src $INET_IP table T1 ip route add default via $INET_GATE table T1 ip route add $INET_GATE dev $INET_IF src $INET_IP
ip route add 127.0.0.0/8 dev lo table T1
ip route add $INET_GATEE dev $INET_IFF src $INET_IPP table T2 ip route add default via $INET_GATEE table T2 ip route add $INET_GATEE dev $INET_IFF src $INET_IPP
ip route add 127.0.0.0/8 dev lo table T2
ip route add $INET_GATE dev $INET_IF src $INET_IP ip route add $INET_GATEE dev $INET_IFF src $INET_IPP
ip route add default via $INET_GATE
ip rule add fwmark 101 table T1 ip rule add fwmark 102 table T2
iptables -t nat -A PREROUTING -d $INET_IP -p tcp -m multiport —dports 80 -j MARK —set-mark 101 iptables -t nat -A PREROUTING -d $INET_IPP -p tcp -m multiport —dports 80 -j MARK —set-mark 102
ниже 2 правила судя по логам отрабатывают iptables -A PREROUTING -t nat -d $INET_IP -p tcp -m multiport —dports 80 -j DNAT —to-destination 192.168.0.2 iptables -A PREROUTING -t nat -d $INET_IPP -p tcp -m multiport —dports 80 -j DNAT —to-destination 192.168.0.10
робит: iptables -t filter -A FORWARD -i $INET_IF -o $LAN_IF -d 192.168.0.2 -j ACCEPT а это уже нет: iptables -t filter -A FORWARD -i $INET_IFF -o $LAN_IF -d 192.168.0.10 -j ACCEPT
хм.. навороченное решение, наверное есть какие то плюсы, я решил ту же проблему несколько иначе, возможно кому то пригодится. сначала все как в примере, добавляем таблицы в /etc/iproute2/rt_tables 100 vlan2 (или ваши имена) 200 vlan2 300 vlan2 #vlan2 — подсеть 1 #vlan3 — подсеть 2 #vlan4 — подсеть 3 ip rule add from 192.168.0.0/26 table vlan2 #добавляем подсети в таблицы ip rule add from 192.168.0.64/26 table vlan3 ip rule add from 192.168.0.128/26 table vlan4 ip route add from 192.168.0.0/26 default via 192.168.2.186 dev br0 table vlan2 #добавляем роутер по умолчанию для этих подсеток ip route add from 192.168.0.64/26 default via 192.168.2.6 dev br0 table vlan3 ip route add from 192.168.0.128/26 default via 192.168.2.6 dev br0 table vlan4
Тема «разжёвана» просто на все 100%, если бы наши преподаватели так материал могли доносить до студентов, то Билли работал бы на нас. 🙂 
Судя по всему, вместо 
всё очень круто описано, но нельзя ли выложить полный скрипт без размышлений вслух? 
пример бы реализации, когда одно соединение ppp 
Внесу поправку, автор немного не верно написал.. 
еще раз — 
а какой айпишник указать в качестве гейта во второй локальной подсети? 
Странный пример в статье. На мой взгляд SNAT превосходит по производительности MASQUERADE, метки тоже не очень оправданы в принципи. Любую маршрутизацию которую надо сделать можно загнать в соответсвующие таблицы и не напрягать ядро левой работой с разбором меток. год назад делал объединение 5 каналов из одной подсети. К стати если случайно забанится один ипшник, то часть конектов будет попадать в мертвое соединение. 
$IPT -t nat -A POTROUTING -s $NET_SUB1 -o NET_INET1 -j SNAT 1.1.1.0/24 
хм! а если надо одну и туже сеть например 192.168.0.0/24 пускать в инет по разному например 80 8080 и т.д. порты через одного прова а фтп почту и т.д. через другого как быть? и как интересно резолвится днс в данном случае если дефолтный маршрут только один у него и днс свой соответственно а второго прова свой днс который уже не резолвится если есть основной маршрут 
забыл уточнить, у меня 2 ипа от 1 провайдера и все одинаково кроме ip 
хм.. навороченное решение, наверное есть какие то плюсы, я решил ту же проблему несколько иначе, возможно кому то пригодится. 
