LINUX.ORG.RU
ФорумAdmin

Два канала в один гарнтированный.


0

1

Уже больше года периодами поднимал для себя вопрос как организовать по двум каналам гарантированную доставку трафика.

Все варианты с перебрасыванием маршрутов, переконнектом ОпенВПН при попадании одного и т.д. отбрасывались по причине - это время реакции.

К примеру есть сервер дома, у него два независимых провайдера в инет. И есть сервер, к примеру в германии. Необходимо, что бы пакет пришедший на сервер в Германии попал на домашнюю машину. 100% гарантии никто и никогда конечно не получит, но бывает ситуация, что на основном (используемом в данный момент) канале (админ свич перетыкал) пропадет инет на пару секунд, а для софта это критичное время.

Поэтому решил сам для себя сваять небольшую софтину которую и представляю на ваше рассмотрение.

Исходные данные два сервера, один дома (два канала интернета), второй в Германии два ИП адреса. На одном и на втором сервере запускается dtun (dounle tunnel, так мне захотелось назвать)

dtun [-b][-h]

-b|--bg : start in background, default - none

--s1=ADDRESS : remote server 1 IP, default - 127.0.0.1

--s2=ADDRESS : remote server 2 IP, default - 127.0.0.1

--p1=PORT : remote server 1 Port, default 4444

--p2=PORT : remote server 2 Port, default 4444

--tapN=NUMBER : local tap interface number, default - 0

--tapA=ADDRESS : local tap interface address, default - 192.168.0.1

-h|--help : this help

-b|--bg - заставляет работать в фоне

--s1=ADDRESS первый адрес удаленной машины

--s2=ADDRESS второй адрес удаленной машины

--p1=PORT - порт первого адреса

--p2=PORT - порт второго адреса

--tapN=NUMBER номер локального tap интерфейса

--tapA=ADDRESS адрес локального tap иртерфейса

-h|--help хелп он и в африке хелп.

При запуске поднимается tap интерфейс и все приходящие на него пакеты будут отсылаться по udp протоколу на два адреса удаленного сервера. На удаленной стороне точно так же. Все приходяшие на локальный порт пакеты транслируются в локальный tap интерфейс. Дублирующий пакет (пришедший по второму каналу) просто игнорируются.

Исходники и скомилированный под х64 бинарик тут Здесь

Пример запуска

/dtun/dtun --lport 5001 --s1 21.22.23.24 --s2 21.22.23.25 --p1 5001 --p2 5001 --tapN 1 --tapA 192.168.2.1 -b

Пока конечно все сыро - поэтому сильно не пинайте, но работает и приносит пользу.

Для тех кто будет ковырять исходники. Пока нет проверки порядка прихода пакета, они конечно же нумеруются. Но все пакеты попадают в буфер. В дальнейших планах сделать проверку очередности и контроль. (Хотя особого смысла наверное не будет).

Отсылаемые пакеты пакуются lzo - поэтому перед компиляцией установите lzo-devel - есть ли смысл, пока не знаю, немного грузит проц. За основу взяты исходники простого туннеля, найденные не помню даже где, самому писать тяжеловато. Сам в сях я не очень, но как говорится если надо то надо. Поэтому сильно не пинайте. Может, наоборот, кто то доделает по уму, думаю многим пригодится. Обмен построен на udp по принципу отправил и забыл. То есть нет понятия нормального соединения, когда один сервер с реальным ИП а второй за натом, просто так работать не будут, для второго надо пробрасывать порт с файрвола. Это с одной стороны минус, а с другой нет понятия никаких таймаутов. Т.е. если сервер за натом то соответственно он должен инициировать соединение и необходимо его контролировать. Здесь же пакеты просто уходят по назначению и все. Контроль уже ложится например на ТСП соединение которое строится по этому туннелю. Наверное так.

Надеюсь попал по адресу и кому то будет интересно.

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

blind_oracle ★★★★★ ()

О, звучит прикольно. Интересно, чего тут наговорят местные аналитики.

post-factum ★★★★★ ()

Вот же ж неуспел =(

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

Но таки спасибо, поковыряю.

Goury ★★★★★ ()
Ответ на: комментарий от blind_oracle

избыточность - это к сожалению единственный способ повысить надежность. ТС, штука гениальная черт возьми, под фрю еще напиши =)

Komintern ★★★★★ ()
Последнее исправление: Komintern (всего исправлений: 1)
Ответ на: комментарий от Komintern

Зачем? Сделай себе OSPF+GRE под соусом IPSEC c хэллоу-интервалом в полсекунды, или даже меньше, и будет у тебя надёжный канал.

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

Komintern ★★★★★ ()

О, пока все здесь, спрошу. Кто знает, есть ли какое-то программное решение для избыточности на канале с потерями? Допустим, есть канал с 5% потерей пакетов, нужно нивелировать потери за счёт скорости/лага.

thesame ★★★★ ()
Ответ на: комментарий от thesame

есть ли какое-то программное решение для избыточности на канале с потерями

Да, называется ТСР

zolden ★★★★★ ()
Ответ на: комментарий от thesame

Можно сделать OpenVPN поверх этого канала, он будет гарантировать доставку пакетов. По TCP точно, по UDP вроде как тоже, но не уверен.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

По ОSPF согласен, но гораздо геморойнее настраивается, Вы не находите? Любое ТСП соединение подразумевает таймаут, который в любом случае будет влиять на результат. Даже если просто пинговать 10 раз в сек. и моментально перенастраивать маршрутизацию - все равно будет обрываться соединение, если это ТСП.

Почитал по ОSPF - да но по моему в моем случае все гораздо проще получилось.

Опять же - каждая реализация под конкретную задачу, кому то это нужно, кому то нет.

sat_art ()
Ответ на: комментарий от sat_art

Я думаю ты просто изобретаешь велосипед.

Ничего при смене маршрута в случае с OSPF не обрывается, с чего ты это взял? TCP просто перепосылает то, что не дошло в момент обрыва и схождения сети, вот и всё.

У меня корпоративная сеть построена на EIGRP+OSPF, на критичных участках в районе ядра сети таймауты EIGRP стоят в 1 секунду, всё сходится мгновенно, проверялось выдергиваением дублирующих железок.

Настраивается OSPF/GRE, если разбираешься в вопросе, за 5 минут и, в итоге, гораздо универсальнее (работает практически в любой более или менее распространённой ОС: Cisco IOS/JunOS/Linux/FreeBSD/OpenBSD/...) чем самописный демон :) Не удваивает траффик и позволяет балансировать нагрузку по обоим каналам.

blind_oracle ★★★★★ ()

RAID1 из каналов =)

af5 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.