балансировка через двух провов

Маркировать пакеты и вперед. Проблемы только если один клиент начинает на 2-х провов распыляться.

Можно подробнее? Как маркировка поможет отправлять новые исходящие пакеты по заданному маршруту?

Если коротко, то маркировку, которую выполняют iptables понимает iproute.
Поэтому iptables маркирует пакеты, а ip потом эти по этим маркерам распихивает пакеты в разные таблицы маршрутизации.
Щас подробный линк нарою, там есть нюансы.

http://www.linux.org.ru/view-message.jsp?msgid=3186294

Тут речь об астериске, но суть та же - часть пакетов маркируется, а потом по этим маркерам по-особенному маршрутизируется.

http://routeskeeper.sourceforge.net/Routeskeeper/MultihomingWithLinux.html

P.S. Что есть "сессионность" ?

>Поэтому iptables маркирует пакеты, а ip потом эти по этим маркерам распихивает пакеты в разные таблицы маршрутизации.

Так это можно сделать и просто средствами iproute2, типа такого:
>ip route show
>[...bla-bla-bla...]
>default
> nexthop via ip_prov1 dev eth0 weight 1
> nexthop via ip_prov2 dev eth1 weight 1

Интересует именно поддержка сессионности.
Тупой пример: кто-то логинится на jabber(aol по-вкусу), и надо чтоб дальше от него пакеты туда ходили по тому же маршруту, иначе сессия навернется и будет релогин с нового ip. Эта проблема касается многих соединений с авторизацией и тп.

Или я чего-то не понимаю?

stateful для этого есть

> иначе сессия навернется и будет релогин с нового ip
Во-первых, пока она отслеживается трасировщиком соединений - не навернётся, т.к., например, SNAT явно выполняется для соединения 1 раз - для первого пакета, далее ядро уже знает какой IP подставлять в пакет. Соответственно, какой бы маршрут не был выбран, src IP всегда будет тот же самый. А вот можно ли по какому-то из каналов ходить с чужим IP или нет - это да, это может создать проблему.
Во-вторых, если надо жёстко закрепить соединения за каналом - см. мою ссылку, там дан пример такой настройки.

В-третьих, ещё бывает такое, что после подключения куда-то (например то же ICQ), клиенту приходит redirect на подключение к другому серверу. А т.к. у другого сервера вполне может быть другой IP, трафик клиента может пойти по другому каналу и получить другой src IP, отличный от src IP начального подключения. Сервер же может ожидать приход запроса от первоначального IP, и новый IP может отвергнуть. В этом случае даже сохраняя привязку IP к каналу, можно очень долго пытаться подключиться.

В PF:
pass in on $int_if route-to { ($ext_if_a $ext_gw_a), ($ext_if_b $ext_gw_b) } round-robin from $int_if:network to any keep state

черт, только хотел написать... ;)

Вот, третье - это первое, с чем я столкнулся(точнее заметил). Аська действительно любит прыгать по разным сервакам как при логине, так и при дальнейшей работе. Как решать подобные проблемы понятно, можно добавлять прямые маршруты по назначению или маркировке определенных пакетов. Но вот где я еще могу столкнуться с подводными камнями, не превратиться ли балансировка по провам в постоянную анальную боль с добавлением новых исключений? Мне тут втирают, что якобы кискожелезяки это все делают молча каким-то волшебным образом.
Сейчас балансировка через nexthop, на вид распределение достаточно ровное в соответствии с "весом" каналов. Я так понимаю, маршруты при этом кэшируются и проблем с типичными вебами быть не должно? Веб у нас кстати через прокси.. Что еще я упустил из виду?

Да написал бы еще раз, чего уж.
Конкретно эта строчка в линуксе занимает ничуть не больше.
Лучше покажи строчку, которая в PF натит на внутрисеточный pptp-сервак или там манипулирует торрент-трафиком :)

Я не сразу понял, что именно ты имел ввиду под сессионостью.

> не превратиться ли балансировка по провам в постоянную анальную боль с добавлением новых исключений?

превратится обязательно. из того что работает живем я встречал только балансировку сессий VPN, все остальное сталкивается с набором трудностей, устранение которых не стоит свеч.

да и чего там аська? начни со скайп (http://www.xakep.ru/post/38543/default.asp) - сразу прочувствуешь что к чему.

>Лучше покажи строчку, которая в PF натит на внутрисеточный pptp-сервак или там манипулирует торрент-трафиком :)

http://www.openbsd.org/faq/pf/nat.html

Все делается стандартными средствани и не надо никаких левых патчей, ни тем более pf
Вот рабочий пример:

Правила iptables:

IP_TTL=300

iptables -t mangle -A PREROUTE -m recent --name isp1 --seconds $IP_TTL --update -g to_isp1
iptables -t mangle -A PREROUTE -m recent --name isp2 --seconds $IP_TTL --update -g to_isp2
iptables -t mangle -A PREROUTE -m state --state NEW -m statistic --mode nth --every 2 --packet 0 -j new_to_isp1
iptables -t mangle -A PREROUTE -m state --state NEW -m statistic --mode nth --every 2 --packet 1 -j new_to_isp2

iptables -t mangle -A new_to_isp1 -m recent --name isp1 --set -j to_isp1

iptables -t mangle -A new_to_isp2 -m recent --name isp2 --set -j to_isp2

iptables -t mangle -A to_isp1 -j MARK --set-mark 0xa
iptables -t mangle -A to_isp1 -j RETURN

iptables -t mangle -A to_isp2 -j MARK --set-mark 0x14
iptables -t mangle -A to_isp2 -j RETURN

Правила iproute:

ip ro del default table main
ip ro add default via 1.2.3.4 dev eth0 table isp1
ip ro add default via 4.5.6.7 dev eth1 table isp2

ip ru add all fwmark 0xa lookup isp1
ip ru add all fwmark 0x14 lookup isp2

Кстати , "-m state --state NEW" из правил можно убрать. Там это было для наглядности :)

Вот упрощенная и оптимизированная версия:

iptables -t mangle -A PREROUTING -m recent --name isp1 --seconds $IP_TTL --update -g to_isp1
iptables -t mangle -A PREROUTING -m recent --name isp2 --seconds $IP_TTL --update -g to_isp2
iptables -t mangle -A PREROUTING -m statistic --mode nth --every 2 --packet 0 -m recent --name isp1 --set -j to_isp1
iptables -t mangle -A PREROUTING -m statistic --mode nth --every 2 --packet 1 -m recent --name isp2 --set -j to_isp2
iptables -t mangle -A to_isp1 -j MARK --set-mark 10
iptables -t mangle -A to_isp2 -j MARK --set-mark 20