NAT на 2 внешних интерфейса

http://www.linuxquestions.org/linux/answers/Networking/Linux_Router_Configura...

http://www.opennet.ru/docs/RUS/LARTC/index.html

iptables -t nat -A POSTROUTING -o $FCE_1 -j SNAT --to-source $ISP_1

iptables -t nat -A POSTROUTING -o $FCE_2 -j SNAT --to-source $ISP_2

собственно всё.. если метрики разные а маршрут одинаков, то при обрыве связи конечно порвуться tcp соединения и вообще всякие сессии, но новые будут ставиться уже через резервный канал.

кстати imho подобное переключение каналов лучше делать руками :) то есть ловить падение основного канала, менять default gw, ожидать поднятия основного канала, решать пора-ли уже на него переключаться и прочая орда вопросов должна решаться в скрипте.

Интересует вопрос... если прописывается 2 правила маскарадинга (или SNAT'a, что думаю не играет роли), то пакеты будут идти на оба интерфейса? И уже в зависимости от того, какой маршур прописан - пакеты либо будут уходить с интерфейса, на которые прописан роут дефолтный. Но в случае с метриками - поидее пакеты будут ходить на оба ISP'a? Или я в чем то ошибаюсь ?

Спасибо за ссылку. LARTC был первым, что я прочитал, когда стала данная задача, но в мануале описано как направлять конкретных пользователей на конкретный канал. Или же как сделать балансировку каналов. В моем же случае балансировка не нужна, скорее даже нежелательна. Поэтому вопрос остается открытым...

А анализировать в скрипте падение основного канала путем получения ответов от пинга ? И скрипт тогда как, в крон что ли добавлять? Имхо тоже не лучший выбор... Хотя если нету других способов - то скорее всего придется реализовывать его. Но все же интересует что будет с пакетами при прописывании 2-х правил маскарадинга на разные интерфейсы? А именно не будут ли случайно одни и те же пакеты бегать по двум разным каналам? Ведь для каждого интерфейса будет прописан свой маршрут...

при маршрутизации пакета выбирается рабочий маршрут с наименьшей метрикой.

Now you need to configure failover routing, wherein if the first route dies, then it will look for an alternative route path. For this, you’ll need to add default gateway routes (provided by your ISP) for both network cards. This is done as follows.
Code:

# route add default gw 202.61.19.1 dev eth1
# route add default gw 202.63.89.1 dev eth2

(202.61.19.1 is a gateway IP given by first ISP and 202.63.89.1 is a gateway IP given by second ISP)
Add these commands in /etc/rc.d/rc.local file, otherwise the routes will vanish every time you reboot the system.
Finally, open /proc/sys/net/ipv4/ route/gc_timeout file from a terminal window and set the value from 300 to 10 and save this file. The gc_timeout file contains some timeout value, after which the kernel declares a route to be dead and automatically switches to other route. Your system will now automatically switch to the second route every time the primary route fails.

2SlavikSS : спорное решение..к примеру по eth1 трафик у нас быстрый и дешёвый, по eth2 канал похуже и цены повыше..первый канал падает скажем на час с 10 до 11. Всё блестяще переключилось на eth2. Через час поднялся канал eth1 и (уупс) остался ни у дел. Весь трафик с сетями которые засветились в обмене за тот аварийный час так и будет переть через eth2.

ну тогда выход один, писать скрипт.

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

Вот если бы вы с этими провайдерами соединялись бы по bgp и иже с ними протоколам, то quagga решила бы ваши проблемы.

А вот по этому поводу можно по-подробнее... Конечно, они врядли пойдут на это... но чисто ради своего интереса - мне было бы познавательно услышать о возможностях...

Сщудинение по bgp предполагает постоянную проверку пиров с которыми соединено. И если пир отвалился то трафик идет через оставшихся в соответствии с некими правилами и соглашениями о предпочитаемых маршрутах. А как только пир поднимется, то траф потечет по нему опять. При условии конечно, что этот пир имеет приоретет. Гораздо сложнее при помощи bgp балансировать нагрузку на несколько каналов, но в данном случае речь об этом не идет.
Также, как правило, при соединении по bgp предполагается, что провайдер выделяет вам некий диапазон адресов из своего адресного пространства. Хотя это и не обязательно.