Комментарии 19
Отличная подробная статья, это здорово.
Эх, спрошу уже не помню в какой раз, но кто-нибудь знает приложение/демон/скрипт для управления хотя бы Policy Based Routing, а лучше, конечно, MultiWAN, для Linux? Есть mwan3 для OpenWRT, но его в Debian не поставишь, слишком завязан на архитектуру OpenWRT. Есть Bird, но это демон маршрутизации, хотя им, в принципе, можно настроить, но, насколько я помню, только статическую конфигурацию.
В общем, есть ли хоть какое-то готовое решение по настройке MultiWAN через 2 или 3 провайдера, каждый из которых использует DHCP?
Эх, спрошу уже не помню в какой раз, но кто-нибудь знает приложение/демон/скрипт для управления хотя бы Policy Based Routing, а лучше, конечно, MultiWAN, для Linux? Есть mwan3 для OpenWRT, но его в Debian не поставишь, слишком завязан на архитектуру OpenWRT. Есть Bird, но это демон маршрутизации, хотя им, в принципе, можно настроить, но, насколько я помню, только статическую конфигурацию.
В общем, есть ли хоть какое-то готовое решение по настройке MultiWAN через 2 или 3 провайдера, каждый из которых использует DHCP?
Спасибо за труд, буду применять для балансировки извне. Вот только один вопрос: почему бы не использовать готовое решение, например VyOS? Там это реализовано интуитивнее и проще (сужу по себе, могу ошибаться).
Про VyOS первый раз слышу, постараюсь ознакомиться с ним. Я стараюсь придерживаться распространённых дистрибутивов, чтобы они были хорошо обновляемыми и были составлены из ходового софта, чтобы не решать общие проблемы, которые уже решены повсеместно. Когда я занимался этим вопросом, то у меня было уже примерное видение, чего нужно добиться и я не подыскивал долго инструмент.
Результат, достигаемый в этом руководстве, отличается от результата подобных руководств: для каждого клиента >используется один и тот же внешний IP-адрес, что избавляет от проблем с интернет-сервисами, которые не готовы к >смене IP-адреса клиента в рамках одной сессии.
ваш подход не отличается от статьи на opennet
там так же предложена маршрутизация с выбором шлюза(провайдера) на основе источника
Маршрутизация на основе источника такая же, как и там, от этого никуда не деться. Различие в способе балансировки.
балансировка у вас происходит на основе чего?
так и в статье которую вы привели есть такое же
Итак, мы рассмотрели очень простой пример. Он будет работать для всех процессов, выполняющихся на маршрутизаторе и для локальной сети, если настроено преобразование адресов (NAT/masquerading). В противном случае, вам будет необходим диапазон IP адресов обоих провайдеров, или выполнять маскирование для одного из провайдеров. В любом случае, вы можете задать правила выбора провайдера для каждого конкретного адреса вашей локальной сети.
вы просто раскрасили трафик(промаркировали) относительно src
фокус то где?
Добавим в файрвол правило, маркирующее пакет числами от 10000 до 10013 в зависимости от исходящего IP-адреса:
так и в статье которую вы привели есть такое же
Итак, мы рассмотрели очень простой пример. Он будет работать для всех процессов, выполняющихся на маршрутизаторе и для локальной сети, если настроено преобразование адресов (NAT/masquerading). В противном случае, вам будет необходим диапазон IP адресов обоих провайдеров, или выполнять маскирование для одного из провайдеров. В любом случае, вы можете задать правила выбора провайдера для каждого конкретного адреса вашей локальной сети.
вы просто раскрасили трафик(промаркировали) относительно src
фокус то где?
Не совсем понимаю вашего вопроса. Фокус, вероятно, в цирке показывают.
Действительно, в том руководстве упоминается о такой возможности. Однако упоминание возможности прибить адрес в локальной сети к провайдеру гвоздями и рабочая схема распределения — вещи разные, не так ли?
Действительно, в том руководстве упоминается о такой возможности. Однако упоминание возможности прибить адрес в локальной сети к провайдеру гвоздями и рабочая схема распределения — вещи разные, не так ли?
а вы что делаете с помощью команды -j HMARK --hmark-tuple src?
вы точно так же делаете но с помощью маленьких декоративных гвоздей на основе мак-адреса
у вас более элегантный способ, но не более чем в статье на opennet
[offtop]
фокус
[/offtop]
вы точно так же делаете но с помощью маленьких декоративных гвоздей на основе мак-адреса
у вас более элегантный способ, но не более чем в статье на opennet
[offtop]
фокус
[/offtop]
Почему так сложно сделана балансировка? У iptables есть модуль statistic, который срабатывает с заданной вероятностью. Например:
Тогда пакет с вероятностью 0,286 (4,004/14) пойдет по второму каналу, 0,357 (4,998/14) по третьему и (1-0,286-0,357)=0,357 ни одно из вероятностных правил не отработает и он пойдет по первому.
Такой подход сразу резко урежет количество правил маршрутизации. Во-первых, читаться будет проще, во-вторых выигрыш в производительности какой-никакой, а все-таки.
iptables ... -j MARK –set-mark 1
iptables ... -m statistic –mode random –probability 0,357 -j MARK –set-mark 3
iptables ... -m statistic –mode random –probability 0,286 -j MARK –set-mark 2Тогда пакет с вероятностью 0,286 (4,004/14) пойдет по второму каналу, 0,357 (4,998/14) по третьему и (1-0,286-0,357)=0,357 ни одно из вероятностных правил не отработает и он пойдет по первому.
Такой подход сразу резко урежет количество правил маршрутизации. Во-первых, читаться будет проще, во-вторых выигрыш в производительности какой-никакой, а все-таки.
Выяснилось, что в статье не достаёт важного момента: нужно выключить фильтрацию по обратному пути на интерфейсах, которые обращены к провайдерам. Например, прописав соответствующее значение переменных в /etc/sysctl.conf:
или сразу для всех интерфейсов:
Проблема состоит в том, что маршруты через интерфейсы интернет-провайдеров есть, но они не все одновременно присутствуют в основной таблице маршрутизации и поэтому пакеты приходящие в обратном направлении отбрасываются. А дополнительные таблицы маршрутизации, судя по всему, не учитываются в rp_filter.
net.ipv4.conf.INTERFFACE_NAME_HERE.rp_filter=0
или сразу для всех интерфейсов:
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0
Проблема состоит в том, что маршруты через интерфейсы интернет-провайдеров есть, но они не все одновременно присутствуют в основной таблице маршрутизации и поэтому пакеты приходящие в обратном направлении отбрасываются. А дополнительные таблицы маршрутизации, судя по всему, не учитываются в rp_filter.
Разверните, пожалуйста, подробнее, что имеется ввиду?
Имеется в виду, что нужно добавить
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0
в файл /etc/sysctl.confДа я не про это, а
Проблема состоит в том, что маршруты через интерфейсы интернет-провайдеров есть, но они не все одновременно присутствуют в основной таблице маршрутизации и поэтому пакеты приходящие в обратном направлении отбрасываются.
В статье рассказывается о том, как пустить трафик через нескольких провайдеров, пользуясь некоторым принципом распределения. Для этого используется несколько таблиц маршрутизации, выбор таблицы осуществляется на основании исходящего адреса.
Когда из внешней сети через одного из провайдеров приходит пакет, адресованный хосту во внутренней сети, применяется основная таблица маршрутизации, в которой может не быть маршрута из дополнительной таблицы маршрутизации, где находятся маршруты этого провайдера. В таком случае при включённом reverse path filtering (по умолчанию), пакет будет отброшен, т. к. интерфейс, через который он пришёл, не соответствует тому, через который происходила бы отправка в обратную сторону.
Когда из внешней сети через одного из провайдеров приходит пакет, адресованный хосту во внутренней сети, применяется основная таблица маршрутизации, в которой может не быть маршрута из дополнительной таблицы маршрутизации, где находятся маршруты этого провайдера. В таком случае при включённом reverse path filtering (по умолчанию), пакет будет отброшен, т. к. интерфейс, через который он пришёл, не соответствует тому, через который происходила бы отправка в обратную сторону.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Щадящая» балансировка между несколькими провайдерами на офисном шлюзе