Как объединить несколько интернет-соединений в один?

Вы можете сделать это, используя пакет ifenslave, который прикрепляет и отделяет подчиненные сетевые интерфейсы к устройству связи.

sudo apt-get install ifenslave

sudo modprobe bondingle

sudo vi /etc/network/interfaces

#eth0 is manually configured, and slave to the "bond0" bonded NIC
auto eth0
iface eth0 inet manual
bond-master bond0

#eth1 ditto, thus creating a 2-link bond.
auto eth1
iface eth1 inet manual
bond-master bond0

# bond0 is the bonded NIC and can be used like any other normal NIC.
# bond0 is configured using static network information.
auto bond0
iface bond0 inet static
address 192.168.1.10
gateway 192.168.1.1
netmask 255.255.255.0
# bond0 uses standard IEEE 802.3ad LACP bonding protocol 
bond-mode 802.3ad
bond-miimon 100
bond-lacp-rate 1
bond-slaves none

sudo restart networking

ifup bond0
ifdown bond0

bond-mode active-backup

Это немного старый вопрос, но если вы все еще хотите знать ..

Есть два типичных сценария, какие gertvdijk и pl1nk спорили в одном из ответов:

Это частный случай объединения соединений / объединения / линга, где несколько интерфейсов уровня 2 (один и тот же сеть) соединены вместе. Его можно архивировать, установив соединения vpn layer 2 (tap) на каждом интерфейсе ISP с компьютера на хост и связав их вместе (режим с круговым движением), чтобы иметь один интерфейс. Ограничивающим фактором в этом сценарии является то, насколько отличаются задержки (ping) на каждом соединении ISP с хостом. Чем они более похожи и стабильны, тем лучше. Мы используем его в одной из наших установок, он работает хорошо. Если вы хотите узнать подробности о том, как реализовать это, просто дайте мне знать.

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

Вы не сможете получить здесь как использование высокой совокупной пропускной способности для одного компьютера, как в первом сценарии, но для небольшого офиса это может быть хорошим решением. Что вы можете сделать, чтобы немного расширить его, это реализовать пользовательские решения для определенных протоколов. Например, у вас может быть какой-то прокси-сервер на шлюзе (который может быть одним и тем же компьютером) для загрузки HTTP и попросить разные части огромного файла, устанавливающего разные сеансы TCP через разные интерфейсы ISP. В этом случае скорость загрузки будет составлять около 100% от общей пропускной способности. Это как разгрузка шлюза, что делают ReGet, GetRight и подобные загрузчики. Частичное содержание Google для HTTP 206. Я не знаю никаких готовых решений с открытым исходным кодом для этого сценария, но есть аппаратные устройства, которые выполняют именно это: google для грибных сетей.