LINUX.ORG.RU
ФорумAdmin

2 интернет канала. Объединение каналов или скрипты?

 , ,


1

2

Всем здрасте.

У меня назревает определенная задача. Условия: ОС: Debian;
Роль: шлюз в интернет (есть сквид, но можно и снести и просто натить);
Каналы:
eth0 - быстрый, но не надежный. Настройки по DHCP;
eth1 - медленный, но надежный;Также настройки по DHCP, но можно прописать вручную;
eth2 - внутренняя сеть.

Первоочередная задача стоит в создании отказоустойчивого доступа к интернету внутренней сети. Почитав статьи, понял, что везде просто описывают скипты. Т.е. можно просто написать скрипт, который будет пинговать раз в 5 минут через eth0, к примеру 8.8.8.8, и в случае отказа, переключать iptables натить через eth1.

Однако захотелось объединить два канала для увеличение скорости, но также, чтоб осталась отказоустойчивость. Погуглив, увидел про bonding. Тут возникает вопросы, которые не понял из чтения статей:
1) У интерфейсов, которые будут в bonding должен быть один и тот же адрес, ip и mac?
2) Для определения, что канал упал, bonding пингует адреса из списка arp_ip_target. Должны ли они быть в одной и той же подсети, что и интерфейсы?

Или же предложите другие варианты - технологии.


Погуглив, увидел про bonding.

Забудь. Это для объединения Ethernet, а не IP. Между компьютером и коммутатором можешь каналы сложить, а к двум провайдерам - нет. Более того, это вообще невозможно. Максимум - это разный трафик разными каналами пустить. Если два канала к одному провайдеру, то тут ECMP использовать можно, но это - к одному.

AS ★★★★★
()

надежно будет через 2 роутера, интерфейсы которых объединены в vrrp

andrew667 ★★★★★
()
Последнее исправление: andrew667 (всего исправлений: 1)

и в случае отказа, переключать iptables натить через eth1.

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

Целесообразность одновременной загрузки двух каналов разной пропускной способности нужно определять отдельно. Если «быстрый» канала загружен не полностью, а «медленный» имеет пропускную полосу в несколько раз ниже «быстрого», то работать может стать некомфортно — ждать пока загрузится большой файл, потому что сервер решил качать его по «медленному» каналу, а не по «быстрому».

mky ★★★★★
()
Ответ на: комментарий от mky

Согласен, мои познания в маршрутизации поверхностные. В написании скрипта не вижу ничего сложного. Думаю пинга 8.8.8.8 раз в 5 минут с необходимого интерфейса хватит.

А вот насчет переключения есть вопросы. Тоже задумывался с уже установленными соединениями. Сейчас для одного соединения использую такой конфиг.

*nat
:PREROUTING ACCEPT [28483:2857309]
:POSTROUTING ACCEPT [1572:95336]
:OUTPUT ACCEPT [5444:330930]
#Весь проходящий трафик nat-тировать
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
#Блокируем входящий и проходящий трафик
:INPUT DROP [20452:2190050]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [70734:44174252]
#
#Разрешаем трафик по lo
-A INPUT -i lo -j ACCEPT
#
#Разрешаем принимать уже установленные соединения
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#
#Разрешаем инициализацию соединений не из интернета
-A INPUT ! -i eth0 -m state --state NEW -j ACCEPT
#
#Разрешаем доступ из внутреней сети наружу
-A FORWARD -i eth1 -o eth0 -j ACCEPT
#
#Запрещаем доступ из наружной сети внутрь
-A FORWARD -i eth0 -o eth1 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Sun Apr 11 11:43:26 2010
# Generated by iptables-save v1.4.2 on Sun Apr 11 11:43:26 2010
*mangle
:PREROUTING ACCEPT [160039:72084816]
:INPUT ACCEPT [83271:18029437]
:FORWARD ACCEPT [74051:53695587]
:OUTPUT ACCEPT [70734:44174252]
:POSTROUTING ACCEPT [144785:97869839]
COMMIT
По идее, если оборвался «быстрый» интернет, мне необходимо всего лишь заменить одну строку в нате на -A POSTROUTING -o eth2 -j MASQUERADE. Ну и соответственно уже должно заранее быть -A FORWARD -i eth1 -o eth2 -j ACCEPT.

Когда же интернет восстанавливается, опять меняем правило на -A POSTROUTING -o eth0 -j MASQUERADE. И насколько я понимаю правило -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT не даст уже установленным соединениям на «медленном» интернете оборваться. Новые же соединения будут идти через быстрый.

Поправьте, пожалуйста, если я где не прав.

massive
() автор топика
Ответ на: комментарий от massive

Поправьте, пожалуйста, если я где не прав.

Лучше прочитайте про PBR (policy based routing), там где есть команды «ip rule» и всё такое.

Правила iptables в цепочке POSTROUTING никак не могут повлиять на маршрутизацию (выбор интерфейса), через который пойдёт пакет. Поэтому и название POST-rounuting, что решение о маршрутизации уже принято. Поэтому, что у вас будет:

-A POSTROUTING -o eth2 -j MASQUERADE
что
-A POSTROUTING -o eth0 -j MASQUERADE
что оба этих правила, пакеты пойдут по маршруту по умолчанию.

Если у вас линк eth0 (быстрый интерент) падает физически (гаснет светодиод, в логах идёт link down), то это одно, но тогда и ping до гугля не нужен. А если линк остаётся, но исчезает связность с интернетом, то тогда нужно настраивать PRB...

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от mky

Чаше всего пропадает свзаность с интернетом, линк остается.

Насколько я понял из выше написанного, в случае пропажи интернета, необходимо менять default route?

massive
() автор топика
Ответ на: комментарий от massive

В общем то да, менять default route, но с возможностью отправлять ping'и и через eth0 для проверки, не поднялся ли быстрый канал. И когда вы с этим разберётесь, можете попробовать перейти на следующий уровень и сделать обратное переключение без обыва закачек через eth2.

mky ★★★★★
()
Ответ на: комментарий от mky

Ну с ping'ом все просто. У него есть опция -I interface. Будем ей пользоваться. А далее постараемся сделать все правильно.

Спасибо за подсказки.

massive
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.