простой способ балансировки трафика между каналами для Linux
Способов реализовать балансировку трафика между каналами достаточно много, начиная от динамический маршрутизации и заканчивая многотабличным роутингом и манипуляциями с ip/tc, Christoph Simon написал на эту тему целый Nano-HOWTO. В нем особенно подробно рассматривается балансировка в условиях, когда один из каналов может пропадать. Однако все эти методы требуют патченья ядра и вдумчивого ознакомления с утилитой ip.
В этой статье пойдет речь о довольно стабильно работающих каналах и простейших способах балансировки с использованием iptables, не прибегая к маршрутизации вообще. Подразумевается, что iptables у вас уже работает ;-).
Исходная ситуация такая (тут обычно рисуют ASCII-art): есть роутер с внутренним интерфейсом к клиентам, наружным интерфейсом к провайдеру и входящим интерфейсом (спутниковый канал или любой другой). Интерфейс к провайдеру назовем "землей", а входящий спутниковый — "тарелкой". Каналов наружу может быть конечно много больше, и это не обязательно тарелки. Предположим, что мы хотим получать http по тарелке, так как там не критичны задержки в 300мс, а все остальное по земле. Но земной канал у нас не нагружен или много шире тарелочного. Нам нужно распределить http по всем каналам, так как этот трафик составляет 80%, и тарелочный канал перегружен, а земля свободна. Предположим также, что на роутере у нас работает squid, за которым сидят все клиенты, и от его имени мы можем использовать или землю, или тарелку. По умолчанию наш сквид работает от реального адреса интерфейса "земли". С помощью всего одного правила iptables мы сможем достичь нашей цели!
У iptables есть стандартный match “limit” и два нестандартных, входящих в отдельный проект patchomatic — nth и random. С помощью них мы сможем добиться балансировки каналов. Для начала рассмотрим limit, работа которого для многих неочевидна или их «видение» ошибочно. Описание этого критерия (match) не совсем понятно не только на официальном сайте, но и во множественных переводах. Предложу еще две альтернативы описания того, как он работает. Описания не совсем точные, зато дают представление.
Первый вариант: limit разбивает канал на несколько временнЫх диапазонов, и через каждый минимальный промежуток времени отбирает пакет в свое правило. Примеры:
-m limit --limit 3/hour— это правило сработает на один пакет один раз ровно через каждых двадцать минут;
-m limit --limit 10/hour— по этому правилу пакет будет совпадать каждые 6 минут;
-m limit --limit 2/second— секунду делим надвое, и в каждый из этих моментов времени будет совпадать один пакет.
Второй вариант объяснения: limit пропускает через правило весь трафик, независимо от его скорости, и отбирает для совпадения столько пакетов, сколько указано. Те же примеры:
-m limit --limit 3/hour— только три пакета за один час пойдут в target (-j) согласно этому правилу, остальные будут пропущены;
-m limit --limit 10/hour— десять пакетов(из всего потока!) за час сюда, остальные дальше;
-m limit --limit 2/second— два пакета в секунду попадут под селектор. Если скорость потока выше и корзина(limit-burst) уже полна, пакеты пропускаются дальше по правилам. Если скорость потока ровно два пакета в секунду, они все попадают в это правило (target). Если скорость пакетов ниже, они будут заполнять корзину, которая далее будет отдавать их со скоростью 2 пакета в секунду. Корзина работает как TBF в CBQ. Если она не указана параметром --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.
Недостатки этого метода:
— не все протоколы могут с ним работать /* и не все тарелко-операторы, если вести разговор о конкретно вышеприведенном примере: многие провайдеры требуют, чтобы запросы к ним шли через VPN-канал и т.п. — прим. ред. */
— нет параметра weight — нельзя четко определить что в какой канал;
— параметр для Limit подбирается на глазок, в зависимости от ваших каналов и активности сквида.
Преимущества этого метода:
— прост в настройке;
— поставляется со стандартным ядром и iptables (без patchomatic);
— проверен и стабилен;
— не зависит от версии ядра;
Работает без чтения ipcref. :-)
Оставшиеся два простых способа балансировки с помощью iptables подразумевают использование nth и random. Они лишены третьего недостатка, а, возможно, и первого. Но вносят дополнительный — необходимость патчить ядро и iptables. Если вас это не пугает, то вперед на 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.
Andy Gorev
В этой статье пойдет речь о довольно стабильно работающих каналах и простейших способах балансировки с использованием iptables, не прибегая к маршрутизации вообще. Подразумевается, что iptables у вас уже работает ;-).
Исходная ситуация такая (тут обычно рисуют ASCII-art): есть роутер с внутренним интерфейсом к клиентам, наружным интерфейсом к провайдеру и входящим интерфейсом (спутниковый канал или любой другой). Интерфейс к провайдеру назовем "землей", а входящий спутниковый — "тарелкой". Каналов наружу может быть конечно много больше, и это не обязательно тарелки. Предположим, что мы хотим получать http по тарелке, так как там не критичны задержки в 300мс, а все остальное по земле. Но земной канал у нас не нагружен или много шире тарелочного. Нам нужно распределить http по всем каналам, так как этот трафик составляет 80%, и тарелочный канал перегружен, а земля свободна. Предположим также, что на роутере у нас работает squid, за которым сидят все клиенты, и от его имени мы можем использовать или землю, или тарелку. По умолчанию наш сквид работает от реального адреса интерфейса "земли". С помощью всего одного правила iptables мы сможем достичь нашей цели!
У iptables есть стандартный match “limit” и два нестандартных, входящих в отдельный проект patchomatic — nth и random. С помощью них мы сможем добиться балансировки каналов. Для начала рассмотрим limit, работа которого для многих неочевидна или их «видение» ошибочно. Описание этого критерия (match) не совсем понятно не только на официальном сайте, но и во множественных переводах. Предложу еще две альтернативы описания того, как он работает. Описания не совсем точные, зато дают представление.
Первый вариант: limit разбивает канал на несколько временнЫх диапазонов, и через каждый минимальный промежуток времени отбирает пакет в свое правило. Примеры:
-m limit --limit 3/hour— это правило сработает на один пакет один раз ровно через каждых двадцать минут;
-m limit --limit 10/hour— по этому правилу пакет будет совпадать каждые 6 минут;
-m limit --limit 2/second— секунду делим надвое, и в каждый из этих моментов времени будет совпадать один пакет.
Второй вариант объяснения: limit пропускает через правило весь трафик, независимо от его скорости, и отбирает для совпадения столько пакетов, сколько указано. Те же примеры:
-m limit --limit 3/hour— только три пакета за один час пойдут в target (-j) согласно этому правилу, остальные будут пропущены;
-m limit --limit 10/hour— десять пакетов(из всего потока!) за час сюда, остальные дальше;
-m limit --limit 2/second— два пакета в секунду попадут под селектор. Если скорость потока выше и корзина(limit-burst) уже полна, пакеты пропускаются дальше по правилам. Если скорость потока ровно два пакета в секунду, они все попадают в это правило (target). Если скорость пакетов ниже, они будут заполнять корзину, которая далее будет отдавать их со скоростью 2 пакета в секунду. Корзина работает как TBF в CBQ. Если она не указана параметром --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.
Недостатки этого метода:
— не все протоколы могут с ним работать /* и не все тарелко-операторы, если вести разговор о конкретно вышеприведенном примере: многие провайдеры требуют, чтобы запросы к ним шли через VPN-канал и т.п. — прим. ред. */
— нет параметра weight — нельзя четко определить что в какой канал;
— параметр для Limit подбирается на глазок, в зависимости от ваших каналов и активности сквида.
Преимущества этого метода:
— прост в настройке;
— поставляется со стандартным ядром и iptables (без patchomatic);
— проверен и стабилен;
— не зависит от версии ядра;
Работает без чтения ipcref. :-)
Оставшиеся два простых способа балансировки с помощью iptables подразумевают использование nth и random. Они лишены третьего недостатка, а, возможно, и первого. Но вносят дополнительный — необходимость патчить ядро и iptables. Если вас это не пугает, то вперед на 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.
Andy Gorev
Сетевые решения. Статья была опубликована в номере 11 за 2003 год в рубрике sysadmin
