2 провайдера

Добрый день.
Имеется роутер, подключенный к двум провайдерам, балансировка выполненна так :

ip route add default scope global nexthop via $P1 dev $IF1 weight 1 nexthop via $P2 dev $IF2 weight 1

В целом все работает, но с определенными сайтами проблемы с авторизацией, например vkontakte.ru выкидывает после двух-трех
кликов по ссылкам. Тоже самое с некоторыми платежными системами.

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

Имеется ли другое решение?

А в чём именно проблема? Пакеты отправленные приходят не на тот интерфейс?
У вас на счёт балансировки это весь скрипт?

Нет, пакеты ходят нормально, трафик делится, и с большинством сайтов все прекрасно
Проблема в том, что при подобной схеме (случайный выбор маршрута, из двух возможных) ряд сайтов сбрасывают авторизацию.
К примеру - P1 первый провайдер, Р2-второй

набираем vkontakte.ru - связь установилась через, Р1
авторизовываемся, можем работать
примерно на 2-4 клике по ссылкам ( как повезет) пакет уходит через Р2
авторизация слетела, начинаем сначала.

Проблема не в провайдерах через каждого из них по отдельности все отлично.

Насколько я понял дело в настройках безопасности этих самых сайтов, при авторизации запоминается ip пользователя, и если
этот ip в середине сесии меняется, что происходит в моем случаи , то сессия сбрасывается.

Скрипт:

/sbin/ip route flush all
/sbin/ip route flush table T1
/sbin/ip route flush table T2

/sbin/ip route add $P1_NET dev $IF1 src $IP1
/sbin/ip route add $P2_NET dev $IF2 src $IP2
/sbin/ip route add 127.0.0.0/8 dev lo

/sbin/ip route add $P1_NET dev $IF1 src $IP1 table T1
/sbin/ip route add default via $P1 dev $IF1 table T1
/sbin/ip route add $P2_NET dev $IF2 src $IP2 table T2
/sbin/ip route add default via $P2 dev $IF2 table T2

/sbin/ip rule add from $IP1 table T1
/sbin/ip rule add from $IP2 table T2

ip route add default scope global nexthop via $P1 dev $IF1 weight 1 nexthop via $P2 dev $IF2 weight 1

/sbin/ip route flush cache

лень писать самому и не люблю копирайт
вот тебе приблизительно а дальше сообразишь
http://forum.interzet.ru/index.php?s=0c6911883e8f18c4645a47614b1a96dc&showtopic=24998&pid=477252&mode=threaded&start=#entry477252
тут ещё по теме
http://habrahabr.ru/blogs/linux/108690/

Будут вопросы пишите

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

ip route add ip.адрес.хитрого.сайта via шлюз.первого.прова

Проблема в том, по какому принципу эти сайты вычислять ?
За этим роутером примерно 400 пользователей, на счет vkontakte.ru и webmoney.ru сразу вой поднялся, прописал маршруты.
Но вот как быть с остальными, пока что неизвестными?

У вас пакеты уходят через 2 прова! в выше сылкой используют CONNMARK для этих вещей.

-j CONNMARK --set-mark 1 маркируем 1 новые соединения

-j CONNMARK --restore-mark которая при была назначена для соединения в целом:

Благодаря -j CONNMARK --restore-mark он будет у вас ходить через тот шлюз которым открыл соединение например сайтом vkontakte.ru
А не через второй gw

Да, надо будет попробовать, но боюсь, что в пределах одного TCP соединения проблему не решить.
Интересует что будет на практике, при открытии, допустим 10 вкладок в браузере, с этим Вконтактом.

Что настроете то и будет smile

Я это к тому, что -j CONNMARK позволит пакетам не менять маршрут в пределах одного соединения.
10 вкладок = 10 tcp соединений, каждое из которых выберет маршрут случайно.
Или я че то не так понимаю ?

Я точно не могу протестировать но сами посудите. Ну открылась сессия через gw2 и чё (и будет токо через него бегать) и всё будет открываться.
А у вас например запрос gw1 ответ на gw1 а дальше (шлюз просто теряется и куда хочет туда посылает вас) поэтому страницы через раз открываются.

Хм.. ошибаетесь, если сессия открылась через gw1, маршрут кешируется, и весь последующий траффик на данный адрес пойдет через gw1.
так будет до прекращения сессии + время хранения маршрута в кэше (насколько помню 2 сек).
При клике на ссылке, равно как и при открытии копии страницы в новой вкладке браузера, создается новая сессия, и если она пойдет через gw2, происходит сброс авторизации.
Причем не на всех ресурсах, к примеру yandex-почта работает отлично, вот этот форум тоже.
Ох ,чувствую, придется городить велосипед с подсчетом поднятых пользовательских ppp каналов и раскидывать их поровну на шлюзы....
Но в любом случаи спасибо за помощь.

Да причём тут кешируеться? Тут работает на уроне mark и от него выбираеться маршрут

Kettler написал:

Да причём тут кешируеться? Тут работает на уроне mark и от него выбираеться маршрут

Работало бы , на уровне mark, если бы решение о выборе маршрута принималось в iptables установкой метки.
Но на сколько я могу судить

iptables -t mangle -A NEW_OUT_CONN -j CONNMARK --set-mark 1
iptables -t mangle -A NEW_OUT_CONN -m statistic --mode random --probability 0.50 -j RETURN
iptables -t mangle -A NEW_OUT_CONN -j CONNMARK --set-mark 2

iptables -t mangle -A PREROUTING -s xx.xx.xx.xx -m state --state new,related -j NEW_OUT_CONN
iptables -t mangle -A PREROUTING -s xx.xx.xx.xx -j CONNMARK --restore-mark

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

А вот при следующем соединении имеем шансы 50/50 что оно пойдет по старому маршруту, и все будет ок, либо будет выбран новый маршрут - привет сброс авторизации.

На счёт авторизации все вопросы к серверной части а вы ток настраиваете клиентскую.
Кстати говорят тут если сессия открылась то все новые вкладки будут бежать именно по открытой сессии.
Вам не кто не мешает проверить на виртуалке.

Выше указанный скрипт не весь возьмите ещё цепочку NEW_OUT_CONN

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

Будем делать распределение пользователей по двум маршрутам в равном количестве ( 1 пользователь = 1 ppp соединение)

Делаем таблицы

$IP1 - шлюз первого провайдера
$P1_NET - подсеть первого прова
$IF1 - сетевая карта, смотрящая на него
$IP2, $P2_NET, $IF2 - соответственно для второго

/sbin/ip route flush all
/sbin/ip route flush table T1
/sbin/ip route flush table T2
/sbin/ip route add $P1_NET dev $IF1 src $IP1
/sbin/ip route add $P2_NET dev $IF2 src $IP2
/sbin/ip route add $P1_NET dev $IF1 src $IP1 table T1
/sbin/ip route add default via $P1 dev $IF1 table T1
/sbin/ip route add $P2_NET dev $IF2 src $IP2 table T2
/sbin/ip route add default via $P2 dev $IF2 table T2
/sbin/ip rule add from $IP1 table T1
/sbin/ip rule add from $IP2 table T2

в /etc/ppp/ip-up.local добавляем скриптик, анализирующий последнюю цифру в номере создаваемого ppp соединения, и в зависимости от неё назначающий пользователю маршрут по умолчанию. То есть все четные pppX пойдут в таблицу T1, через провайдера P1, а нечетные через T2
$1 - имя интерфейса
$5 - ip адрес , присваеммый клиенту

I=${1:(-1)}
IP=$5
case $I in
[2,4,6,8,0])
    /sbin/ip rule del from $IP table T1
    /sbin/ip rule del from $IP table T2
    /sbin/ip rule add from $IP table T1
    exit
;;
esac
    /sbin/ip rule del from $IP table T1
    /sbin/ip rule del from $IP table T2
    /sbin/ip rule add from $IP table T2

Хотелось бы коментариев, на рабочем роутере пока не пробовал

Поставил на роутер, пришлось еще добавить маршруты до ДНС, в итоге получилось

#!/bin/sh
IF1=eth3
IF2=eth4
IP1=xxxxxx
IP2=xxxxxx
P1=xxxxxxx
P2=xxxxxxx
P1_NET=xxxxxxxx
P2_NET=xxxxxxxx
DNS1_P1=xxxxxxx
DNS2_P1=xxxxxxx
DNS1_P2=xxxxxxx
DNS2_P2=xxxxxxx
/sbin/ip route flush all
/sbin/ip route flush table T1
/sbin/ip route flush table T2
/sbin/ip route add $P1_NET dev $IF1 src $IP1
/sbin/ip route add $P2_NET dev $IF2 src $IP2
/sbin/ip route add 127.0.0.0/8 dev lo
/sbin/ip route add $P1_NET dev $IF1 src $IP1 table T1
/sbin/ip route add $DNS1_P1 dev $IF1 src $IP1 table T1
/sbin/ip route add $DNS2_P1 dev $IF1 src $IP1 table T1
/sbin/ip route add default via $P1 dev $IF1 table T1
/sbin/ip route add $P2_NET dev $IF2 src $IP2 table T2
/sbin/ip route add $DNS1_P2 dev $IF2 src $IP2 table T2
/sbin/ip route add $DNS2_P2 dev $IF2 src $IP2 table T2
/sbin/ip route add default via $P2 dev $IF2 table T2
/sbin/ip rule add from $IP1 table T1
/sbin/ip rule add from $IP2 table T2
/sbin/ip route flush cache

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

Ну у тя клиенты подключаются по vpn получается.
И в зависимости от ип загоняешь в нужную таблицу.
А теперь представим что IP2 отвалился что тогда делать?
Тут уже не балансировка а хз как назвать через ж.....

Kettler написал:

Ну у тя клиенты подключаются по vpn получается.
И в зависимости от ип загоняешь в нужную таблицу.
А теперь представим что IP2 отвалился что тогда делать?
Тут уже не балансировка а хз как назвать через ж.....

Что значит "Отвалится ?"
Если нет связи до пров1, допустим, то это = аварийная ситуация, требующая немедленного вмешательстьва.
За три года такое случалось всего 2 раза, оба раза все решалась в течении, 15-20 минут.
А если у прова какие то работы, предупреждение приходит минимум за сутки.

Но да, насчет скриптика, пингующего шлюзы, и в зависимость от доступности шлюзов переносящего данные из Т1 в Т2 или наоборот подумать можно.
Наверно еще пару дней потестирую, и займусь этим.

Нету смысла копать в эту сторону это не балансировка.
Из этих ип кто нибудь если будет качать торренты забьёт 1 канал и даже после этого юзеры будут попадать именно в это трубу в независимости что второй канал будет свободен.

Канал каждого пользователя имеет фиксированную ширину, согласно тарифу, которая намного меньше ширины канала до любого из провайдеров,так что никто ничего не забьет.
За прошедшее, после начала использования этого способа время, разница в загрузке каналов не превышала 40%, это ночью, когда мало подключеннвх клиентов, что собственно и логично. По мере увеличения их количества , разница в загрузке каналов сокращается до 15%-20% в вечернее время (это при общей загрузке провайдерских каналов на 75%-80%).
Жду выходных, там нагрузка будет максимальной.