Снова про балансировку между шлюзами.

По какой причине вам нужно два шлюза? почему на один нельзя повесить 2 wanif-а от двух провайдеров и заниматься балансировкой на одной машине?

один роутер у которого 2 канала в инет
стандартная ситуация - главная проблема что нужно выходящие маскарадить - а маскарадит на тот ip с которого вышли - и нельзя получиться для одной и той же сессии данные с двух интерфейсов

поэтому идеально не получиться - но работать будет

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

По причине, что нужно физическое резервирование, потому как на каждом шлюзе и так по три канала связи и куча правил маршрутизации. На схему этого переносить не стал, потому как не вижу в этом смысла. P.S. машина и так одна - шлюзы в гипервизоре.

В принципе, еще можно повесить дополнительно на первом шлюзе один из IP адресов второго провайдера, но это придётся сделать на виртуальном интерфейсе. Правда не уверен, что это облегчит задачу.

По причине, что нужно физическое резервирование

Я похожую задачу решил немного другим путем, более дубовым (чтобы не перекидывать виртуальный ip): 2 гипервизора, на каждом вирт. машина с настроенными интернет-каналами. По факту на втором гипервизоре точная копия в выключенном состоянии. Мониторится состояние машины на первом гипервизоре и если что не так - запускается вторая. Простой инета - 20 сек., для нас это допустимо.

Но тут слегка другая ситуация - тут это нужно сделать между физическим интерфейсом и вланом.

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

Есть вероятность, что я не до конца понял, чего вы хотите добиться и поэтому не въезжаю :)

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

GLBP, CARP. Больше в голову ничего не приходит.

Насколько мне известно первый протокол работает только на цисковских роутерах, а карп полноценно работает только на фре. У меня же шлюзы на дебиане. Возможно вы владеете, какой-то мало известной инфой?

Если речь шла о полноценном LB - то только эти варианты есть. Может что-то ещё в linux ipvs... А если мастер-слейв и чтобы мастер гнал часть трафика через слейв, то тут всё просто. Слейв станет для мастера вторым линком, а на слейве маскарадинг по SRC делать и маркировать соединения: кто, с какого интерфейса пришел.

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

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

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

если не маркировать на слейве - будет асимметричная маршрутизация