Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 18 Jan 24 18:16:22, всего сообщений: 10753
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 9709 из 10753 ===================================== RU.UNIX.BSD =
От   : Eugene Grosbein                  2:5006/1           14 May 20 01:36:29
Кому : Dmitry Dolzenko                                     14 May 20 01:36:29
Тема : Re: VPN с агрегацией 2-3 каналов
FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+2d2b2a8b
На   : area://RU.UNIX.BSD?msgid=ddt.demos.su+46c805b1
= Кодировка сообщения определена как: IBM866 =================================
Ответ: area://RU.UNIX.BSD?msgid=<1187513780@ddt.demos.su>+9e25ef3b
Ответ: area://RU.UNIX.BSD?msgid=2:5005/49+5ebd614f
==============================================================================
13 мая 2020, среда, в 14:30 NOVT, Dmitry Dolzenko написал(а):

DD> Есть эфирный LTE интернет с 2-3 каналами, с разной скоростью, падениями
DD> канала итп.
DD> Посоветуйте, есть ли софт, который позволяет сделать VPN с агрегацией
DD> 2-3 каналов и отказоустойчивостью?

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

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

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

Таким образом, балансировка нагрузки в какой-то мере
может быть достигнута (L3 per-flow load sharing),
но на практике и тут полно проблем. Во-первых, есть ли у тебя
достаточное множество TCP-коннектов и при этом достаточная
ширина отдельных линков LTE, чтобы каждый конкретный линк
не забивался одной-двумя прокачками по TCP?
Если нет, то овчинка не стоит выделки.

И даже если есть - многие современные интернет-сервисы очень не любят,
когда запросы от одного и того же пользователя вдруг приходят
с разных IP-адресов в течение одной и той же "сессии"
и их работа тупо ломается в таком случае.

Это значит, что если у тебя нет возможности назначить каждому
юзеру локальной сети отдельный IP, тебе придется транслировать
исходящий трафик каждого юзера в один конкретный внешний IP-адрес
одного конкретного линка, то есть делить трафик не per-flow,
а per-user, что ещё больше усугубляет проблему распределения
нагрузки пропорционально ширинам каналов. Я тебе больше скажу:
даже когда у тебя есть по IP-адресу на пользователя,
всё равно задача распределения нагрузки по каналам неравной
ширины в современном интернете нетривиальна и требует
регулярного ручного вмешательства.

Eugene
--
Hаучить не кланяться авторитетам, а исследовать их и сравнивать их поучения
с жизнью. Hаучить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.072009 секунды