Ключевые слова:iptables, balance, traffic, link, linux, nat, (найти похожие документы)
From: Andy Gorev <gorev@mail333.com>
Newsgroups: http://atmsk.ru
Date: Mon, 10 Dec 2003 14:31:37 +0000 (UTC)
Subject: Балансировка каналами в Linux
Оригинал: http://www.atmsk.ru/index.php?option=articles&task=viewarticle&artid=85
Балансировка каналами по простому
Andy Gorev
В статье по Advanced Routing и QoS
(http://www.atmsk.ru/index.php?option=articles&task=viewarticle&artid=27)
я уже приводил некоторые способы для балансирования трафиком между
несколькими каналами.
Их достаточно много, начиная от динамический маршрутизации и
заканчивая многотабличным роутингом и манипуляциями с ip/tc.
Christoph Simon написал на эту тему целый Nano-HOWTO
(http://www.ssi.bg/~ja/nano.txt), на который я ранее неоднократно
ссылался. В нем особенно подробно рассматривается балансирование в
условиях, когда один из каналов может пропадать. Однако все эти методы
требуют патченья ядра и вдумчивого ознакомления с утилитой ip.
В этой статье пойдет речь о довольно стабильно работающих каналах и
простейших способах балансирования с использованием iptables, не
прибегая к маршрутизации вообще. Подразумевается, что она у вас уже
работает ;-).
Исходная ситуация такая (тут обычно рисуют ascii-art): есть роутер с
внутренним интерфейсом к клиентам, наружним интерфейсом к провайдеру и
входящим интерфейсом (спутниковый канал или любой другой). Интерфейс к
провайдеру назовем "землей", а входящий спутниковый - "тарелкой".
Каналов наружу может быть конечно много больше, и это не обязательно
тарелки. Предположим, что мы хотим получать http по тарелке, так как
там не критичны задержки в 300мс, а все остальное по земле. Но земной
канал у нас не нагружен или много шире тарелочного. Нам нужно
распределить http по всем каналам, так как этот трафик составляет 80%,
и тарелочный канал перегружен, а земля свободна. Предположим также,
что на роутере у нас работает сквид, за которым сидят все клиенты, и
от его имени мы можем использовать или землю или тарелку. По умолчанию
наш сквид работает от реального адреса интерфейса "земли". С помощью
всего одного правила iptables мы сможем достичь нашей цели!
У iptables есть стандартный match limit и два не стандартных, входящих
в отдельный проект patchomatic - nth и random. С помощью них мы сможем
добиться балансировки каналов. Для начала рассмотрим limit, работа
которого для многих не очевидна или ошибочна. Описание этого
критерия(match) не совсем понятно не только на официальном сайте, но и
во множественных переводах. Предложу еще две альтернативы описания
того, как он работает. Описания не совсем точные, зато дают
представление.
Первый. limit разбивает канал на несколько временнЫх диапазонов, и
через каждый минимальный промежуток времени отбирает пакет в свое
правило. Примеры:
1. -m limit --limit 3/hour - это правило сработает на один пакет
один раз ровно через каждых двадцать минут;
2. -m limit --limit 10/hour - по этому правилу пакет будет совпадать
каждых 6 минут;
3. -m limit --limit 2/second - секунду делим надвое, и в каждый из
этих моментов времени будет совпадать один пакет.
Второй. limit пропускает через правило весь трафик, независимо от его
скорости, и отбирает для совпадения столько пакетов, сколько указано.
Те-же примеры:
1. -m limit --limit 3/hour - только три пакета за один час пойдут в
target (-j) согласно этому правилу, остальные будут пропущены;
2. -m limit --limit 10/hour - десять пакетов(из всего потока!) за
час сюда, остальные дальше;
3. -m limit --limit 2/second - два пакета в секунду попадут под
селектор.
Если скорость потока выше и корзина(limit-burst) уже полна,
пакеты пропускаются дальше по правилам. Если скорость потока
ровно два пакета в секунду, они все попадают в это правило
(target). Если скорость пакетов ниже, они будут заполнять корзину,
которая далее будет отдавать их со скоростью 2 пакета в секунду.
Корзина работает как TBF в CBQ (см. статью Advanced
(http://www.atmsk.ru/index.php?option=articles&task=viewarticle&artid=27)
Routing и QoS). Если она не указана параметром --limit-burst, то
по умолчанию равна пяти пакетам.
Если внимательно обдумать оба подхода, то станет ясно, что это одно и
тоже, только с разного боку. ;-)
В сети полно примеров, как можно с помощью limit защищаться от DoS
атак особенно на примерах ICMP-флуда. А мы вернемся к нашей теме.
Теперь то самое одно правило, которое решит нашу задачу:
iptables -t nat -A POSTROUTING -p tcp -s $ground --dport www -m limit --limit 10/second -j SNAT --to $sat
Здесь:
"$ground" - интерфейс к провайдеру - "земля", от которого работает сквид;
"-p tcp --dport www" - кроме сквида на интерфейсе может быть еще что-то, выделим http;
"-m limit --limit 10/second" - это уже понятно, 10 пакетов в секунду.
И все, что попало под это правило, маскарадится тарелочным адресом.
Остальное идет по земле, так как повторяюсь - свид у нас работает от
реального земного адреса. Маскарадясь тарелкой, исходящие пакеты
уходят по земле, а приходят по тарелке на ее src адрес. Вопрос: а
если пакеты фрагментируются? Правильно, они будут собираться по
ip-sequence, прилетая так-же разбалансированно по каналам. Звучит
фантастически, но это работает. Если разные адреса назначения
находятся физически на одной машине, пусть и на разных интерфейсах,
ядро по секвенсам будет правильно собирать пакеты. И ему будет до
фонаря, по какому интерфейсу пришли его части.
Теперь обращу внимание, что этот пример касался http, как не
требующего трассирования протокола. Если делать это со сложными
протоколами, то надо загружать в ядро connection tracking модули и их
части для НАТ. Например пару ip_conntrack_ftp и ip_nat_ftp. Кроме
этого нужно будет отслеживать state флагов (ESTABLISHED, etc.)
пакетов. Как это делать -
http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html
или тоже Nano-HOWTO.
Недостатки этого метода:
1. Не все протоколы могут с ним работать;
2. Нет параметра weight - нельзя четко определить что в какой канал;
3. Limit зависит от загрузки канала, нельзя четко разделить сколько в
какой канал - параметр подбирается "на глазок" в зависимости от
ваших каналов и активности сквида.
Преимущества этого метода:
1. Прост в настройке;
2. Поставляется со стандартным ядром и iptables;
3. Проверен и стабилен, без patchomatic не зависит от версии ядра;
4. Работает без чтения ipcref. :-)
Оставшиеся два простых способа балансировки с помощью iptables,
подразумевают использование nth и random. Они лишены третьего
недостатка, а возможно и первого. Но вносят дополнительный -
необходимость патчить ядро и iptables. Если вас это не пугает, то
вперед на http://www.iptables.org. Их описание, достаточно вразумительное
можно найти там-же:
http://www.iptables.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.9
http://www.iptables.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.14
Ну с udp траффиком всё понятно, а как это будет работать на tcp? Там же соединение открывается между host_A:port_A -> host_B:port_B, а в нашем случае получается что host_A:port_A бкдет меняться. И как на это "посмотрит" tcp-stack? Или я чего-то непонимаю?
с tcp скорее всего будут проблемы, есть вариант балансировать только tcp соединения, т.е. только первые пакеты, попадающие в таблицу nat, например с помощью модуля statistic
