Как сделать агрегацию офисного Интернета?

Question

[pashaxp]

Имеется linux-сервер с ОС Debian, к которому подключены 2 независимых друг от друга Интернет- провайдера, и третьим линком - офисная сеть.

2 провайдера нужны для отказоустойчивости и резервирования Интернет-ресурсов для нужд офиса.
Когда один выходит из строя, за некое непродолжительное время перестраиваются роуты, поднимается openvpn туннель... но не в этом суть.

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

В кабинетах по офису используются как проводные подключения, которые используют dhcp, nat офисного роутера, так и беспроводные точки доступа wi-fi, также, использующие dhcp, nat офисного роутера и настроены в режиме access point.

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

Answer 1

[pashaxp]

Задачу решил таким способом:

1. по некоторому нехитрому скрипту выполняю тест доступности Интернет-ресурсов, простой ping нескольких высокодоступных ресурсов типа 8.8.8.8 и ещё нескольких для пущей достоверности.
2. если Инет отсутствует, тогда выполняется автоматическое переключение между провайдерами, меняется default route
3. в момент, когда Инет работает от провайдера №1, выполняю тесты работоспособности провайдера №2, и добавляю static route для всяких vk, youtube, fb и других ресурсов, которые посчитал нужным направить через "вторичный" канал для разгрузки основного.
4. при смене аплинка роуты перестраиваются, как только вторичный провайдер становится снова в строй.

Answer 2

[АртемЪ]

Ищите по ключевым словам "балансировка каналов" load balancing. Статей достаточно много.
В принципе ничего сложного, хотя алгоритмы бывают разные.
Самый простой - round robin банально кидать каждый следующий пакет в другой канал. Но только вот если каналы разной ширины, то загрузка будет неравномерной.
Можно сделать посложнее с учетом загрузки канала.
Иногда выгодно балансировать по типу трафика - например отправлять критичный к пингу трафик в один канал, а все остальное в другой.
Тут надо знать что хотите получить в итоге и какие проблемы решить.

Один важный момент - если просто тупо раскидывать трафик по каналам можно поиметь проблемы с авторизацией на некоторых сайтах.
Т.е вы авторизировались с ip x.x.x.x а следующий ваш запрос пришел с ip y.y.y.y в результате вас выкинуло из сеанса. Т.е куча пользователей не сможет работать с кучей сервисов.
Поэтому надо маркировать трафик и следить чтобы если запрос к одному сервису ушел через один интерфейс, все повторные запросы шли через тот же. А это уже сложнее и требует вычислительных ресурсов на балансировщике.

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

Из инструментария в основном iptables и mangle.

Comments

[throughtheether]

Самый простой - round robin банально кидать каждый следующий пакет в другой канал.

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

[АртемЪ]

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

Лично я стараюсь избегать по возможности сложных схем, и в большинстве случаев ограничиваюсь раскидыванием трафика разного типа по разным каналам. Да и каналы в большинстве случаев разные по ширине и по качеству.

Answer 3

[Армянское Радио]

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

Answer 4

[Даниил]

Только примите к сведению, что из ядра >=3.5, при условии, что не делали бэкпортов, выпилили ipv4 routing cache.
А это значит, что бОльшая часть статей по балансировке каналов вам просто не поможет.

Comments

[Владимир]

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

Answer 5

[gilgameshfreedom]

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

1. Алгоритм балансировки. Самый простой - round-robind, попеременно высылающий пакет, то через один канал, то через другой. Однако, он не учитывает скорости каналов и их загруженность.
2. Балансировать пакеты или соединения? Мы должны выбрать что мы будем балансировать - исходящие пакеты или соединения. ИМХО, балансировать пакеты уместнее когда у вас и у удаленной стороны настроен бондинг. Когда разные провайдеры, каждый из которых выдает вам свой IP-адрес, уместнее привязывать каждое исходящее соединение на конкретного провайдера и слать это соединение только через него. Кроме того необходимо, чтобы любой входящий запрос к вам через одного из провайдера, уходил обратно через него же.
3. Кроме балансировки нам необходим метод определения доступности канала, чтобы исключить нерабочий канал из балансировки, и, наоборот, добавить заработавший канал снова в балансировку. Самый простой способ, это просто смотреть находится ли сетевой интерфейс в рабочем состоянии - есть ли линк. Однако это плохой способ, так как линк может быть поднят, но проблемы у провайдера где-то дальше, а мы все равно будем отправлять через него данные. Разумнее отдельно для каждого провайдера проверять доступность провайдерского шлюза, например, пингом. Однако если мы получаем IP-адрес по DHCP, и сеть(шлюз) периодически меняются, нам необходимо это учитывать.

Answer 6

[WArYagTwar]

ну, выше всё написали, добавлю только свои 5коп. есть дистрибутив pfsence, проще всего поставить его на сервер, и в нём ковырять и лоад балансинг, и фаерволы, и прочие плюшки. великолепная штука, единственный минус - жрёт только одно ядро, поэтому в системе, где сетевых карт много, раз в неделю виснет. на машине с 3 сетевухами и вайфаем работает великолепно, на машине с 4 сетевухи и 2 вайфая уже раз в неделю прописан в кроне ребут.