Здравствуйте.
Помогите, пожалуйста, разобраться. Есть два аплинка к одному провайдеру. Необходимо пропорционально поделить между ними трафик. Т.е. балансировку нагрузки. При этом соединения по определенным портам всегда должно идти через тот интерфейс, с которого были установлены. Теряюсь в догадках как такое можно провернуть...Раньше, при одном аплинке, я пользовал связку iptables+bind+squid+netams. Вот рабочие правила для старой конфигурации:
#!/bin/bash/sbin/modprobe ip_queue
/sbin/modprobe ip_nat_ftp
/sbin/modprobe nf_conntrack_ftpIPT="/sbin/iptables"
INET="eth0"
LAN="eth1"
NETWORK="192.168.0.0/24"
SQUID="3128"
WWW="80,81,8080"
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT DROP$IPT -N INPUT_LAN
$IPT -N INPUT_INET#================SQUID==================
$IPT -t nat -A PREROUTING -s $NETWORK ! -d $NETWORK -p tcp -m multiport --dport $WWW -j REDIRECT --to-ports $SQUID
$IPT -A OUTPUT -o $LAN -p tcp -m tcp --sport $SQUID -m state --state NEW,RELATED,ESTABLISHED -j QUEUE#==============NETAMS===================
$IPT -A FORWARD -i $LAN -o $INET -p ALL -j QUEUE
$IPT -A FORWARD -i $INET -o $LAN -p ALL -j QUEUE
#=============SERVER====================
$IPT -A INPUT -i $INET -p icmp -j ACCEPT
$IPT -A INPUT -i $INET -j INPUT_INET
$IPT -A INPUT -i $LAN -j INPUT_LAN
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A INPUT -j INPUT_INET$IPT -A OUTPUT -p icmp -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
$IPT -A OUTPUT -o $LAN -j ACCEPT
$IPT -A OUTPUT -o $INET -p udp --dport 53 -j ACCEPT
$IPT -A OUTPUT -o $INET -p udp --sport 53 -j ACCEPT
$IPT -A OUTPUT -o $INET -p tcp --sport 22 -j ACCEPT
$IPT -A OUTPUT -o $INET -p tcp --sport 80 -j ACCEPT
$IPT -A OUTPUT -o $INET -p tcp -m multiport --dport $WWW -j ACCEPT#++++=============LAN==================
$IPT -A INPUT_LAN ! -s $NETWORK -j DROP
$IPT -A INPUT_LAN -m state --state INVALID -j DROP
$IPT -A INPUT_LAN -s $NETWORK -p icmp -j ACCEPT
$IPT -A INPUT_LAN -p tcp -m tcp --dport $SQUID -m state --state NEW,RELATED,ESTABLISHED -j QUEUE
$IPT -A INPUT_LAN -j ACCEPT#=================INET=================
$IPT -A INPUT_INET -p tcp --dport 22 -j ACCEPT
$IPT -A INPUT_INET -p tcp --dport 80 -j ACCEPT
$IPT -A INPUT_INET -p tcp --sport 8245 -j ACCEPT
$IPT -A INPUT_INET -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPT -A INPUT_INET -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT_INET -p tcp --dport 22 -j ACCEPT
$IPT -A INPUT_INET -p udp --dport 53 -j ACCEPT
$IPT -A INPUT_INET -p udp --sport 53 -j ACCEPT
$IPT -A INPUT_INET -p tcp --syn -j DROP#================NAT==================
$IPT -t nat -A POSTROUTING -s $NETWORK -o $INET -j MASQUERADE
Трафик на 80-й порт заворачивается на "прозрачный" сквид, со сквида на биллинг.
Весь FORWARD идет на биллинг, там считается и фильтруется куда можно, куда нельзя.
Сейчас от биллинга можно избавиться... Дайте пинка в нужном направлении =)
Ну вот давай рассмотрим такую ситуацию:http запросы одного и того же пользователя на один и тот же сайт.
JFYI, они могут идти в разных TCP-соединениях.
Поскольку ты пишешь"соединения по определенным портам всегда должно идти через тот интерфейс, с которого были установлены"
и
"Необходимо пропорционально поделить между ними трафик. Т.е. балансировку нагрузки. "
то возможно, что эти "http запросы одного и того же пользователя на один и тот же сайт" пойдут по разным каналам.
Я так предполагаю, что это значит - разный NAT.
А это значит - что на сайт пользователь придет с двух разных IP.
А там бац - и авторизация.
И тут бац - и ты становишься (кем) ?
Ну и так далее, очень много непредсказуемых вещей может быть.
Рекомендую побалансировать "половину пользователей туда, половину сюда".
Почитать http://ru.wikipedia.org/w/index.php?title=Iptables&oldid=364...
>А это значит - что на сайт пользователь придет с двух разных IP.Вот потому и спрашиваю. Я так понял что iptables что iproute2 работают с пакетами. А нет ли какой плюшки, которая позволяет работать именно с соединениями? Или может есть уже какое готовое решение для балансировки нагрузки, которое вменяемо настраивается?
"-Виски так виски, я не сектант!" (с) Инспектор Берюрье>Рекомендую побалансировать "половину пользователей туда, половину сюда".
Сойдет в том смысле, что не руками балансировать "этих сюда, а вот этих сюда", а в зависимости от загрузки канала. Что опять же возвращает к вопросу о работе с соединениями а не с пакетами...
>>А это значит - что на сайт пользователь придет с двух разных IP.
> Вот потому и спрашиваю. Я так понял что iptables что iproute2 работают
> с пакетами.iptables умеет взаимодействовать с CONNTRACK, соответственно работать с соединениями.
посредством привязки маркера (MARK) к соединению, а впоследствии с помощью копирования маркера соединения в маркер пакета - можно добиться "работы iproute" с соединениями.> А нет ли какой плюшки, которая позволяет работать именно
> с соединениями? Или может есть уже какое готовое решение для балансировки
> нагрузки, которое вменяемо настраивается?Но, я про соединения и говорю, что одно пойдет туда, другое сюда, и пользователь обломается.
Т.е. уровни: (1) пакеты -> (2) соединения -> (3) сессии - есть еще более высокий уровень.
Перечитай заново ответ выше.
>>Рекомендую побалансировать "половину пользователей туда, половину сюда".
> Сойдет в том смысле, что не руками балансировать "этих сюда, а вот
> этих сюда", а в зависимости от загрузки канала. Что опять же
> возвращает к вопросу о работе с соединениями а не с пакетами...идеально не сбалансируешь.
системы, управляющиеся мышкой - это к майкрософту вроде...
> Перечитай заново ответ выше.Спасибо за ссылку. Многое стало понятнее. Многое, но не все.
Вот берем реальную ситуацию:
eth0 - 192.168.0.0/24 внутренняя сеть
пров дает постоянные серые адреса, т.е. к примеру
eth1 - 192.168.1.101
eth2 - 192.168.1.102
адрес шлюза на обоих 192.168.1.100. При таком раскладе разве я не смогу поделить трафик?
- указываю маршрут по умолчанию на любой внешний интерфейс,
- создаю две таблицы с маркировками типа ip rule add fwmark 1 table 101 /-/-/ 102
- при new маркирую пакет, при established копирую маркер на всю цепочку...по идее установленное соединение должно будет пойти через тот интерфейс, через который было установлено. Если не использовать маскарадинг а делать -j SNAT на серый адрес... или нет?
>[оверквотинг удален]
> eth1 - 192.168.1.101
> eth2 - 192.168.1.102
> адрес шлюза на обоих 192.168.1.100. При таком раскладе разве я не смогу
> поделить трафик?
> - указываю маршрут по умолчанию на любой внешний интерфейс,
> - создаю две таблицы с маркировками типа ip rule add fwmark 1
> table 101 /-/-/ 102
> - при new маркирую пакет, при established копирую маркер на всю цепочку...
> по идее установленное соединение должно будет пойти через тот интерфейс, через который
> было установлено.отдельное соединение - да. Сессия соединений - нет.
Могу скопировать оба предыдущих ответа в это сообщение, чтобы они были _еще раз_ перечитаны.
> Если не использовать маскарадинг а делать -j SNAT на
> серый адрес... или нет?почитайте ман iptables на тему MASQUERADE, потом расскажите, чем отличаются SNAT и MASQUERADE. Я лично не вижу технической разницы в действиях SNAT и MASQUERADE на фиксированных адресах.
> отдельное соединение - да. Сессия соединений - нет.
> Могу скопировать оба предыдущих ответа в это сообщение, чтобы они были _еще
> раз_ перечитаны.Как же в таких условиях живут бедные провайдеры? Неужели жестко прописывают маршруты для каждого абонента?
> почитайте ман iptables на тему MASQUERADE, потом расскажите, чем отличаются SNAT и
> MASQUERADE. Я лично не вижу технической разницы в действиях SNAT и
> MASQUERADE на фиксированных адресах.скорость обработки, если я правильно помню. snat быстрее. А так - ничем.
>> отдельное соединение - да. Сессия соединений - нет.
>> Могу скопировать оба предыдущих ответа в это сообщение, чтобы они были _еще
>> раз_ перечитаны.
> Как же в таких условиях живут бедные провайдеры? Неужели жестко прописывают маршруты
> для каждого абонента?как живут бедные - я достоверно не знаю. В прописывании маршрутов для абонентов ничего крамольного не вижу.
Богатые - берут каналы нормально, не в виде серых адресов, а в виде белых сеток, подымают BGP и развлекаются уже с ним. Т.е. сетка маршрутизируется по обеим каналам, конечно же не идеально ровно 50/50. Ну там начинаются и другие приколы, типа асимметрий и т п.
> отдельное соединение - да. Сессия соединений - нет.Т.е. сессию никак не отследить? Плин, "половину сюда, половину туда" тоже не прикольно. Высокая вероятность что второй канал будет просто простаивать, когда первый будет забит под завязку. А нет ли какого-нибудь решения для маркировки пакетов по адресу назначения например?
>> отдельное соединение - да. Сессия соединений - нет.
> Т.е. сессию никак не отследить? Плин, "половину сюда, половину туда" тоже не
> прикольно. Высокая вероятность что второй канал будет просто простаивать, когда первый
> будет забит под завязку. А нет ли какого-нибудь решения для маркировки
> пакетов по адресу назначения например?ну вот смотри. Допустим, ты извратишься и сделаешь наоборот, по адресу назначения определяя канал, через который пойдет пакет от пользователя.
допустим, для этого мы возьмем третий октет айпи адреса и проверим его на четность.
т.е.x.y.1.z пойдет по нечетному каналу, а k.l.2.m пойдет по четному каналу.
Твой несчастный пользователь пойдет на сервис а-ля рапидшара, где ему для скачивания сформируют персональную ссылку, содержащую его айпи адрес (ну, чтобы ссылки не тиражировали и не публиковали в интернете). Сформировали ссылку, сделали редирект _на другой сервер_. А он бац - и в другой сети - CDN, панимаешь. А ты его раз - и по другому каналу отправил...
>> отдельное соединение - да. Сессия соединений - нет.
> Т.е. сессию никак не отследить? Плин, "половину сюда, половину туда" тоже не
> прикольно. Высокая вероятность что второй канал будет просто простаивать, когда первый
> будет забит под завязку. А нет ли какого-нибудь решения для маркировки
> пакетов по адресу назначения например?есть вообще суровая штука, называется "статистика". Я пока не понял, на основании чего делается вывод, что "Высокая вероятность что второй канал будет просто простаивать, когда первый будет забит под завязку", и что помешает на основании этих же оснований сделать так, чтобы так не было (т.е. по другому перегруппировать пользователей).
>>> отдельное соединение - да. Сессия соединений - нет.
>> Т.е. сессию никак не отследить? Плин, "половину сюда, половину туда" тоже не
>> прикольно. Высокая вероятность что второй канал будет просто простаивать, когда первый
>> будет забит под завязку. А нет ли какого-нибудь решения для маркировки
>> пакетов по адресу назначения например?
> есть вообще суровая штука, называется "статистика". Я пока не понял, на основании
> чего делается вывод, что "Высокая вероятность что второй канал будет просто
> простаивать, когда первый будет забит под завязку", и что помешает на
> основании этих же оснований сделать так, чтобы так не было (т.е.
> по другому перегруппировать пользователей).Статистика тут не пройдет. Я могу поделить пропорционально пользователей по каналам, они сожрут оба. Сегодня. А завтра полконторы умотает в командировку - поехали перераспределять. Вернулись эти, уехали другие - снова перераспределять. Хотелось бы как-то не зависеть от того, сколько народу и из каких сетей у меня в инет ходят. Нет, если конечно это невозможно, то придется делать именно руками и следить за нагрузкой... Но, плин, правда не могу поверить что нет решения для динамической балансировки.