Несколько каналов интернет ubuntu

Обновлено: 04.07.2024

Решено: Два интернет канала (Как бы их объеденить в один?)

Модератор: SLEDopit

Решено: Два интернет канала

Суть проблемы такова: есть подключение к интернет через локальную сеть (первый канал) и с недавних пор появилось второе подключение по выделенной линии (второй канал). дома две персоналки, два ноутбука и КПК. Роутер (Zyxel p-330w ee) подключен к первому каналу и раздает интернет на все это хозяйство.
Собственно чего я хочу: а хочу я использовать оба интернет соединения одновременно, дабы увеличить ширину канала и до кучи повысить надежность, чтобы в случае падения одного канала второй продолжал работать как ни в чем не бывало.

Собственно зачем обращаюсь на форум:
1) Возможно ли такое? В смысле не просто "подключение по двум интернетам", а именно чтобы они работали как один. Вариант с разделением трафика по двум каналам не интересен, хочется именно оба вместе. Возможно ли?
2) Если 1 возможно, то нужен будет девайс (по видимому интернет шлюз), порекомендуйте что-нибудь самое простенькое и недорогое. (Имеющийся роутер с этой задачей не справится).

Linux Advanced Routing & Traffic Control HOWTO
4.2.2. Распределение нагрузки.

Ну, какбы, то и значит (как я это представляю): стоит шлюз, в него приходят два шнурка из внешнего мира, к шлюзу подключен роутер, с настроенными LAN'ом и Wi-Fi, с которого интернет расходится по домашним компам. В случае каких-то неполадок на одном канале (упал сервер авторизации, обрыв кабеля иль еще какая зараза) второй канал работает и интернет соединение не обрывается, закачки с торрентов не обрываются, продолжаем работать в интернете как ни в чем не бывало, разве что скорость упадет. Ну и соотвественно если скорость одного канало 600кб/с, а скорость второго канала 1,5Мб/с - то на выходе хочется иметь общий канал 2.1Мб/с.

В общем случае для организации балансировки трафика между двумя WAN-интерфейсами на Ubuntu можно использовать способы описанные в документе Ubuntu-ru - IP-Балансировка: объединяем несколько интернет-каналов в один . В нашем случае требуется организовать немного более простую конфигурацию и поэтому способ её реализации будет несколько более прост. На уже работающих прокси-серверах Squid, собранных в конфигурацию повышенной доступности , имеется по одному WAN-интерфейсу направленному в сторону одного интернет-провайдера. Для повышения доступности Интернет для конечных пользователей мы добавим на прокси-серверы ещё по одному WAN-интерфейсу направленному в сторону другого интернет-провайдера и настроим скрипт перестроения правил маршрутизации в случае возникновения проблем с одним из провайдеров. Здесь мы рассмотрим обновлённый вариант такой настройки (без использования multipath-маршрутизации).

Тезисно общий смыл настройки и последующей работы реализуемой нами конфигурации Multi-WAN можно отразить так:

На двух прокси-серверах будет настроено по 2 WAN-интерфейса (2 публичных IP адреса от разных интернет-провайдеров)
На каждом из серверов на любой определённый момент времени только один из WAN-интерфейсов используется для определения маршрута по умолчанию, то есть весь трафик в интернет идёт через этот WAN-интерфейс. Второй WAN-интерфейс при этом системой не используется.
Для распределения интернет-трафика между двумя интернет-провайдерами, согласно предыдущего тезиса, на одном прокси-сервере активен (как маршрут по умолчанию) WAN-интерфейс относящийся к первому интернет-провайдеру, а на втором прокси-сервере активен WAN-интерфейс относящийся к другому провайдеру.
При старте системы на обоих серверах запускается скрипт проверяющий доступность каких-либо интернет-узлов (например Google и Yandex) через активный (как маршрут по умолчанию) WAN-интерфейс. Как только скрипт определит недоступность интернет-ресурсов, - выполняется перестроение маршрутизации: маршрут по умолчанию назначается на другой WAN-интерфейс.

Для большей наглядности приведу простейшую схему нашей конечной конфигурации с учётом ранее собранной конфигурации повышенной доступности с помощью UCARP:

Рассмотрим процесс настройки первого прокси-сервера (KOM-AD01-GW20).

Первым делом внесём изменения в файл описывающий таблицы маршрутизации используемые в системе:

В конец файла добавим две новые таблицы маршрутизации, которые будут использоваться для работы скрипта:

Затем внесём изменения в файл /etc/network/interfaces .

В параметрах описывающих первый WAN-интерфейс (в нашем примере eth1 ) убедимся в том, что присутствует запись о шлюзе провайдера и добавим две команды. Первая команда добавляет маршрут по умолчанию в созданную нами дополнительную таблицу маршрутизации относящуюся к конкретному провайдеру (например provider1 ). Вторая команда добавляет правило означающее то, что все пакеты промаркированные ( fwmark ) определённым тэгом (например 11 ) отправляются в таблицу маршрутизации относящуюся к конкретному провайдеру (например provider1 ). Соответственно этот WAN-интерфейс на данном сервере будет использоваться для определения маршрута по умолчанию.

Аналогичным образом добавим информацию о втором WAN-интерфейсе ( eth2 ), только адрес шлюза провайдера здесь уже указывать не будем.

В нашем примере адреса 62.99.99.241 (шлюз для eth1 ) и 99.99.99.20 (шлюз для eth2 ) – это адреса шлюзов интернет-провайдеров.

p align="left"> Для корректной работы скрипта нам понадобится отключить rp_filter (подробнее здесь ), так как он блокирует входящие пакеты на интерфейсе от сетей, которых нет в маршрутах через этот интерфейс. Сделать это можно, например, внеся изменения в файл sysctl.conf

Найдём, раскомментируем и установим значения rp_filter в 0 :

Сохраним файл и применим его изменения в системе:

После всех проделанных изменений перезагружаем сервер и проверяем результат сделанных изменений. Проверим основную таблицу маршрутизации (main)…

Как видим, шлюз провайдера с первого WAN-интерфейса ( eth1 ) определяет на текущем сервере маршрут по умолчанию ( default ).

Проверим две дополнительные созданные нами таблицы маршрутизации и наличие в них маршрута по умолчанию:

Далее создадим папку для хранения скрипта проверки состояния WAN-интерфейсов, в ней создадим файл скрипта и сделаем его исполняемыми для root.

Наполним скрипт содержимым:

В переменной GW укажем массив шлюзов интернет-провайдеров (в скобках через пробел). В массиве должно быть столько значений, сколько WAN-интерфейсов мы настроили в файле /etc/network/interfaces .

В переменной IF укажем массив имён интерфейсов относящихся к значениям в переменной GW .

В переменной MARK укажем массив тэгов, которые будут использоваться для маркировки ICMP-пакетов генерируемых скриптом проверки. В качестве значений массива могут быть указаны, например, любые двузначные числа (целые и больше 0). Самое главное, чтобы эти значения были идентичны значениям параметра fwmark , указанного нами ранее в файле /etc/network/interfaces .

В переменной DNS укажем массив каких-либо публичных IP адресов, которые будут проверяться с помощью ping на доступность (в нашем примере используются адреса хорошо известных DNS серверов Google и Yandex).

В переменной LOG укажем месторасположения лог-файла, в который будут записываться все события перестроения default-маршрута.

Логика скрипта следующая – через активный WAN-интерфейс посылается 3 пинга на каждый из внешних публичных IP адресов из пула значений переменной DNS . В случае если все попытки завершаются неудачей – происходит перестроение default-маршрута таким образом, чтобы задействовать другой работоспособный WAN-интерфейс.

Теперь нам нужно настроить периодическое выполнение скрипта. Создадим для этого файл задачи cron:

Наполним его содержимым таким образом, чтобы наш скрипт проверки Multi-WAN выполнялся раз в минуту:

p align="left"> Не забываем при необходимости изменить правила iptables. Например, если прокси-серверы должны ещё обеспечивать работу NAT, как было описано ранее , добавляем соответствующие правила iptables для обоих WAN-интерфейсов:

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

Сымитируем сбой доступности провайдера используемого для default-маршрута с помощью iptables, например так:

В логе при этом через минуту будет зафиксировано соответствующее событие о том, что интерфейс “опущен”:

Проверим то, как при этом изменилась конфигурация маршрутов:

Как видим, заблокированный WAN-интерфейс eth1 теперь не используется для маршрута по умолчанию, и теперь весь трафик будет направляться через другой доступный WAN-интерфейс ( eth2 ).

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

Чтобы снова включить в работу WAN-интерфейс eth1 , выполняем команду удаления созданного ранее правила iptables:

В логе при этом будет зафиксировано соответствующее событие о том, что интерфейс вернулся к работе:

Снова проверим конфигурацию маршрутов в таблице маршрутизации main и убедимся в том, что они перестроились (вернулись к исходному состоянию):

Всю настройку второго прокси-сервера (KOM-AD01-GW21) выполняем по аналогии с первым с некоторыми изменениями. В частности, в файле /etc/network/interfaces меняем IP-адреса, а шлюз провайдера указываем уже не на первом, а на втором WAN-интерфейсе, то есть именно второй WAN-интерфейс будет определять маршрут по умолчанию для данного сервера.

Далее не забываем, при необходимости, в соответствии с изменением WAN-интерфейсов внести изменения в правила iptables.

Затем в полной аналогии с первым прокси-сервером выполняем на втором сервере настройки:
- добавляем две дополнительные таблицы маршрутизации в /etc/iproute2/rt_tables ;
- в файле /etc/sysctl.conf отключаем rp_filter ;

Создаём скрипт /etc/multi-wan/check-multi-wan.sh с тем же содержимым, что и на первом сервере за исключением того, что меняем местами значения массивов в переменных GW , IF , MARK

p align="left"> Скрипт сконструирован таким образом, что для определения маршрута по умолчанию приоритетным считает тот шлюз провайдера, который в массиве значений стоит первым. Поэтому мы и меняем на втором сервере значения соответствующих переменных.

В конечном итоге, скомбинировав ранее описанную настройку UCARP и описанную здесь настройку динамического перестроения default-маршрута, можно получить высоко-доступное решение по предоставлению Интернет-ресурсов конечным пользователям локальной корпоративной сети, которое по функционалу не будет уступать проприетарному Microsoft Forefront TMG (снятому кстати говоря с продаж и официальной поддержки) в массиве Enterprise Array с задействованным режимом ISP Redundancy.

p align="left"> Справедливости ради также стоит отметить , что описанное решение по своей сути не имеет прямого отношения к Squid и может быть использовано и в других сценариях, где нужно организовать балансировку нагрузки между двумя и более серверами с несколькими WAN-интерфейсами.

p align="center"> ***
Благодарю Владимира Леттиева (aka crux) за пошаговую инструкцию со скриптом и всестороннюю помощь в построении вышеописанной конфигурации.

Небольшой эксперимент создания интернет-шлюза для двух подсетей на базе на Ubuntu Server. У меня дома компьютер с установленной Windows 10 и VirtualBox. Давайте создадим семь виртуальных машин: router , pc-1 , pc-2 , pc-3 , nfs-server , ftp-server , web-server :

Виртуальные машины pc-1 , pc-2 , pc-3 объединены в сеть 192.168.176.0/24
Виртуальные машины nfs-server , ftp-server , web-server объединены в сеть 192.168.30.0/24

Виртуальная машина router будет обеспечивать выход в интернет для компьютеров подсетей 192.168.176.0/24 и 192.168.30.0/24 , у нее три сетевых интерфейса:

enp0s3 (сетевой мост) — смотрит в домашнюю сеть, получает ip-адрес 192.168.110.8 от роутера Keenetic Air
enp0s9 (внутреняя сеть) — смотрит в одну сеть с виртуальными машинами pc-1 , pc-2 , pc-3
enp0s8 (внутреняя сеть) — смотрит в одну сеть с виртуальными машинами nfs-server , ftp-server , web-server

Тут надо сказать несколько слов о настройке сети в VirtualBox. Существует несколько способов, рассмотрим два из них:

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

Настройка сети для router

Сначала нужно посмотреть, как называются сетевые интерфейсы в системе:

Теперь редактируем файл /etc/netplan/01-netcfg.yaml

Применяем настройки и смотрим сетевые интерфейсы:

Первый сетевой интерфейс enp0s3 получил ip-адрес 192.168.110.8 от роутера Keenetic Air, этот ip-адрес закреплен постоянно. Второму сетевому интерфейсу enp0s8 мы назначили ip-адрес 192.168.30.1 . Третьему сетевому интерфейсу enp0s8 мы назначили ip-адрес 192.168.176.1 .

Настройка сети для pc-1, pc-2 и pc-3

Сначала для виртуальной машины pc-1 . Смотрим, как называются сетевые интерфейсы в системе:

Открываем на редактирование файл /etc/netplan/01-netcfg.yaml :

Применяем настройки и смотрим сетевые интерфейсы:

Для виртуальных машин pc-2 и pc-3 все будет аналогично, назначаем им ip-адреса 192.168.176.3 и 192.168.176.4 .

Настройка сети для nfs-server, ftp-server, web-server

Сначала для виртуальной машины nfs-server . Смотрим, как называются сетевые интерфейсы в системе:

Открываем на редактирование файл /etc/netplan/01-netcfg.yaml :

Применяем настройки и смотрим сетевые интерфейсы:

Для виртуальных машин ftp-server и web-server все будет аналогично, назначаем им ip-адреса 192.168.30.3 и 192.168.30.4 .

Настройка интернет-шлюза

Виртуальная машина router должна обеспечивать выход в интернет для компьютеров из двух подсетей 192.168.176.0/24 и 192.168.30.0/24 . По умолчанию транзитный трафик отключен, так что редактируем файл /etc/sysctl.conf :

И перезагружаем виртуальную машину router . После этого настраиваем netfilter с помощью утилиты iptables :

И вот что у нас получилось в итоге:

Теперь настроим SNAT (подмена адреса источника), что позволит всем компьютерам двух подсетей выходить в интернет, используя единственный ip-адрес 192.168.110.8 :

И смотрим, что получилось:

Доступ к NFS-серверу за NAT

Наш NFS-сервер расположен во внутренней сети 192.168.30.0/24 и имеет ip-адрес 192.168.30.2 . Чтобы обеспечить доступ к нему из подсети 192.168.110.0/24 , выполняем на виртуальной машине router команды (подробнее можно прочитать здесь):

И смотрим, что получилось:

Доступ к FTP-серверу за NAT

Наш FTP-сервер расположен во внутренней сети 192.168.30.0/24 и имеет ip-адрес 192.168.30.3 . Чтобы обеспечить доступ к нему из подсети 192.168.110.0/24 , выполняем на виртуальной машине router команды (подробнее можно прочитать здесь):

И смотрим, что получилось:

Доступ к WEB-серверу за NAT

Наш WEB-сервер расположен во внутренней сети 192.168.30.0/24 и имеет ip-адрес 192.168.30.4 . Чтобы обеспечить доступ к нему из подсети 192.168.110.0/24 , выполняем на виртуальной машине router команду:

И смотрим, что получилось:

Связь между подсетями

Чтобы обеспечить связь между подсетями 192.168.176.0/24 и 192.168.30.0/24 , добавим на маршрутизаторе еще два правила:

Проверим, что с виртуальной машины pc-1 можно достучаться до nfs-server :

И наоборот, что с виртуальной машины nfs-server можно достучаться до pc-1 :

Доступ к серверам за NAT по SSH

Чтобы иметь возможность управлять серверами, на каждый из них установлен SSH-сервер. И нужно обеспечить доступ к ним из внешней подсети 192.168.110.0/24 . Для этого выполняем на маршрутизаторе три команды:

Первая комнанда — мы отбираем tcp-пакеты, которые приходят на интерфейс enp0s3 на порт 2222 и отправляем эти пакеты виртуальной машине nfs-server на порт 22 , заменяя в пакетах пункт назначения на 192.168.30.2 . Вторая и третья команды позволяют получить доступ к ftp-server и web-server .

Открываем на физическом компьютере окно PowerShell и выполняем команду:

Сохранение правил netfilter

Созданные с помощью утилиты iptables правила пропадут при перезагрузке виртуальной машины router . Так что их нужно сохранить и восстанавливать при перезагрузке. В этом нам поможет пакет iptables-persistent :

При установке пакета будет предложено сохранить текущие правила iptables :

в файл /etc/iptables/rules.v4 для протокола IPv4
в файл /etc/iptables/rules.v6 для протокола IPv6

После установки пакета будет добавлена новая служба netfilter-persistent.service , которая при загрузке системы будет восстанавливать созданные нами правила:

При добавлении новых правил, надо сохранить конфигурацию с помощью команды

Объединение сетевых интерфейсов(Bonding) – это механизм, используемый Linux-серверами и предполагающий связь нескольких физических интерфейсов в один виртуальный, что позволяет обеспечить большую пропускную способность или отказоустойчивость в случае повреждения кабеля. В данном руководстве мы разберем реализацию объединения интерфейсов в Linux для Ubuntu/Debian и CentOS/RHEL/Fedora.

Агрегация сетевых интерфейсов в Ubuntu и Debian

Важно! Если у вас используется Ubuntu версии 17.10 и выше, то необходимо установить пакет ifupdown или настраивать агрегацию каналов нужно через netplan

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

В более старых версиях Debian или Ubuntu может потребоваться установка пакета ifenslave:

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

Для создания постоянного связанного интерфейса типа mode 0 (ниже мы разберем эти типы более подробно), нужно отредактировать файлы конфигурации сетевых интерфейсов. Откройте с помощью любого текстового редактора, например nano, файл /etc/network/interfaces , как показано в следующем фрагменте (замените IP-адрес, маску подсети, шлюз и DNS-серверы на используемые в вашей сети).

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

Настройки связанного интерфейса можно проверить при помощи следующих команд:

Подробную информацию об объединенном интерфейсе можно получить, просмотрев содержимое следующего файла ядра командой cat:

Для отладки ошибок можно использовать команду tail

Проверку параметров сетевой карты можно выполнить при помощи инструмента mii-tool:

Режимы работы

mode=1 (active-backup)
Когда используется этот метод, активен только один физический интерфейс, а остальные работают как резервные на случай отказа основного.

mode=3 (broadcast) Широковещательный режим, все пакеты отправляются через каждый интерфейс. Имеет ограниченное применение, но обеспечивает значительную отказоустойчивость.

mode=4 (802.3ad)
Особый режим объединения. Для него требуется специально настраивать коммутатор, к которому подключен объединенный интерфейс. Реализует стандарты объединения каналов IEEE и обеспечивает как увеличение пропускной способности, так и отказоустойчивость.

mode=6 (balance-alb)
Адаптивное распределение нагрузки. Аналогично предыдущему режиму, но с возможностью балансировать также входящую нагрузку.

Объединение сетевых интерфейсов в CentOS, RHEL и Fedora

Создайте новый файл bonding.conf в директории /etc/modprobe.d/ . Имя может быть любым, но расширение должно быть .conf. Вставьте в этот файл следующую строку:

Такая строка в файле /etc/modprobe.d/bonding.conf требуется для каждого bond интерфейса.
Для агрегации интерфейсов создайте в директории /etc/sysconfig/network-scripts/ файл конфигурации с именем ifcfg-bond0. Вот пример содержимого файла конфигурации (IP-адреса в вашей системе могут отличаться):

После создания объединённого интерфейса нужно настроить его и связанные с ним сетевые карты, добавив в файлы конфигурации директивы MASTER и SLAVE. Для всех связанных интерфейсов эти файлы могут быть почти одинаковыми. Например, у двух интерфейсов eth0 и eth1, связанных в один, они могут иметь следующий вид. Отредактируйте их, как показано ниже.
Для eth0

Значение этих директив следующее:
DEVICE: определяет имя устройства
USERCTL: определяет, может ли пользователь управлять интерфейсом (в данном случае нет)
ONBOOT: определяет, включать ли интерфейс при загрузке
MASTER: есть ли у этого устройства ведущий интерфейс (здесь это bond0)
SLAVE: работает ли это устройство каки ведомое
BOOTPROTO: Определяет получение IP-адреса по DHCP. При статическом IP-адресе устанавливается значение none

Перезагрузите сетевую службу и проверьте конфигурацию командой ifconfig.

Заключение

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте также: