Answer the question
In order to leave comments, you need to log in
How to make office Internet aggregation?
There is a linux-server with Debian OS, to which 2 independent Internet providers are connected, and the third link is an office network.
2 providers are needed for fault tolerance and reservation of Internet resources for the needs of the office.
When one fails, the routes are rebuilt in a short time, the openvpn tunnel is up ... but that's not the point.
There is a great desire to use both ISPs for office work when they are both working. After all, in fact, while the office is working and the linux server uses only one of them as an uplink, the second one is idle.
Office cabinets use both wired connections that use dhcp, nat of the office router, and wireless wi-fi access points that also use dhcp, nat of the office router and are configured in access point mode.
Interested in how you can realize the idea of efficient use of resources?
Maybe something in the formulation of the problem lacks some data, details. I will provide if needed.
Answer the question
In order to leave comments, you need to log in
I solved the problem in this way:
1. using some simple script, I perform a test of the availability of Internet resources, a simple ping of several highly accessible resources like 8.8.8.8 and a few more for greater reliability.
2. if there is no Internet, then automatic switching between providers is performed, the default route changes
3. at the moment when the Internet works from provider No. 1, I perform performance tests of provider No. 2, and add static route for all vk, youtube, fb and other resources , which he considered necessary to send through the "secondary" channel to unload the main one.
4. When changing the uplink, the routes are rebuilt as soon as the secondary provider becomes operational again.
Search by keyword "channel balancing" load balancing. There are quite a few articles.
In principle, nothing complicated, although the algorithms are different.
The simplest - round robin is trite to throw each next packet into a different channel. But only if the channels are of different widths, then the download will be uneven.
It can be made more difficult, taking into account the channel load.
Sometimes it is beneficial to balance by type of traffic - for example, send traffic that is critical to ping to one channel, and everything else to another.
Here you need to know what you want to get in the end and what problems to solve.
One important point - if you just stupidly scatter traffic across channels, you can have problems with authorization on some sites.
Т.е вы авторизировались с ip x.x.x.x а следующий ваш запрос пришел с ip y.y.y.y в результате вас выкинуло из сеанса. Т.е куча пользователей не сможет работать с кучей сервисов.
Поэтому надо маркировать трафик и следить чтобы если запрос к одному сервису ушел через один интерфейс, все повторные запросы шли через тот же. А это уже сложнее и требует вычислительных ресурсов на балансировщике.
Ну и в зависимости от выбранной логики надо будет думать как все это дело увязать с файловером, т.е с резервированием канала.
Из инструментария в основном iptables и mangle.
Вы можете настроить nat таким образом, чтобы он направлял пакеты от клиентов по разным соединениям, загружая таким образом оба канала. Идея изложена здесь, в частности.
Только примите к сведению, что из ядра >=3.5, при условии, что не делали бэкпортов, выпилили ipv4 routing cache.
А это значит, что бОльшая часть статей по балансировке каналов вам просто не поможет.
Как уже выше написали, в интернете достаточно много статей по балансировки трафика по нескольким провайдерам. Однако надо ответить для себя на несколько вопросов:
1. Алгоритм балансировки. Самый простой - round-robind, попеременно высылающий пакет, то через один канал, то через другой. Однако, он не учитывает скорости каналов и их загруженность.
2. Балансировать пакеты или соединения? Мы должны выбрать что мы будем балансировать - исходящие пакеты или соединения. ИМХО, балансировать пакеты уместнее когда у вас и у удаленной стороны настроен бондинг. Когда разные провайдеры, каждый из которых выдает вам свой IP-адрес, уместнее привязывать каждое исходящее соединение на конкретного провайдера и слать это соединение только через него. Кроме того необходимо, чтобы любой входящий запрос к вам через одного из провайдера, уходил обратно через него же.
3. Кроме балансировки нам необходим метод определения доступности канала, чтобы исключить нерабочий канал из балансировки, и, наоборот, добавить заработавший канал снова в балансировку. Самый простой способ, это просто смотреть находится ли сетевой интерфейс в рабочем состоянии - есть ли линк. Однако это плохой способ, так как линк может быть поднят, но проблемы у провайдера где-то дальше, а мы все равно будем отправлять через него данные. Разумнее отдельно для каждого провайдера проверять доступность провайдерского шлюза, например, пингом. Однако если мы получаем IP-адрес по DHCP, и сеть(шлюз) периодически меняются, нам необходимо это учитывать.
ну, выше всё написали, добавлю только свои 5коп. есть дистрибутив pfsence, проще всего поставить его на сервер, и в нём ковырять и лоад балансинг, и фаерволы, и прочие плюшки. великолепная штука, единственный минус - жрёт только одно ядро, поэтому в системе, где сетевых карт много, раз в неделю виснет. на машине с 3 сетевухами и вайфаем работает великолепно, на машине с 4 сетевухи и 2 вайфая уже раз в неделю прописан в кроне ребут.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question