LINUX.ORG.RU
Форум — Admin  

OpenVPN поверх очень плохого линка

 ,


0

2

Соединение работает постоянно, но стабильно теряет около половины пакетов: 


$ ping 10.58.96.119
PING 10.58.96.119 (10.58.96.119) 56(84) bytes of data.
64 bytes from 10.58.96.119: icmp_req=1 ttl=60 time=5.26 ms
64 bytes from 10.58.96.119: icmp_req=2 ttl=60 time=5.75 ms
64 bytes from 10.58.96.119: icmp_req=5 ttl=60 time=7.56 ms
64 bytes from 10.58.96.119: icmp_req=7 ttl=60 time=3.34 ms
64 bytes from 10.58.96.119: icmp_req=11 ttl=60 time=1.54 ms
64 bytes from 10.58.96.119: icmp_req=13 ttl=60 time=2.52 ms
64 bytes from 10.58.96.119: icmp_req=14 ttl=60 time=11.8 ms
64 bytes from 10.58.96.119: icmp_req=17 ttl=60 time=2.16 ms
64 bytes from 10.58.96.119: icmp_req=19 ttl=60 time=5.41 ms
64 bytes from 10.58.96.119: icmp_req=20 ttl=60 time=11.0 ms
64 bytes from 10.58.96.119: icmp_req=21 ttl=60 time=1.58 ms
64 bytes from 10.58.96.119: icmp_req=22 ttl=60 time=2.37 ms
64 bytes from 10.58.96.119: icmp_req=23 ttl=60 time=7.76 ms
64 bytes from 10.58.96.119: icmp_req=25 ttl=60 time=2.99 ms
64 bytes from 10.58.96.119: icmp_req=26 ttl=60 time=1.61 ms
64 bytes from 10.58.96.119: icmp_req=27 ttl=60 time=5.23 ms
64 bytes from 10.58.96.119: icmp_req=28 ttl=60 time=8.73 ms
64 bytes from 10.58.96.119: icmp_req=29 ttl=60 time=8.50 ms
64 bytes from 10.58.96.119: icmp_req=31 ttl=60 time=5.80 ms
64 bytes from 10.58.96.119: icmp_req=32 ttl=60 time=11.0 ms
64 bytes from 10.58.96.119: icmp_req=37 ttl=60 time=7.17 ms
64 bytes from 10.58.96.119: icmp_req=38 ttl=60 time=1.62 ms
64 bytes from 10.58.96.119: icmp_req=41 ttl=60 time=1.76 ms
64 bytes from 10.58.96.119: icmp_req=43 ttl=60 time=4.02 ms
64 bytes from 10.58.96.119: icmp_req=44 ttl=60 time=8.04 ms
64 bytes from 10.58.96.119: icmp_req=47 ttl=60 time=26.5 ms
64 bytes from 10.58.96.119: icmp_req=49 ttl=60 time=7.31 ms
64 bytes from 10.58.96.119: icmp_req=50 ttl=60 time=6.13 ms
64 bytes from 10.58.96.119: icmp_req=53 ttl=60 time=3.53 ms
64 bytes from 10.58.96.119: icmp_req=55 ttl=60 time=8.37 ms
64 bytes from 10.58.96.119: icmp_req=56 ttl=60 time=6.42 ms
^C
--- 10.58.96.119 ping statistics ---
58 packets transmitted, 31 received, 46% packet loss, time 57048ms
rtt min/avg/max/mdev = 1.543/6.226/26.548/4.756 ms
Через это соединение должен работать OpenVPN-туннель. Причём очень желательно чтобы пакеты, проходящие через туннель не терялись (насколько это возможно). Я конечно понимаю, что чуда в любом случае не будет, но может можно как-то подкрутить настройки OpenVPN под это дело?

Deleted
← procmail не сортирует почту
Аналог | begin ios-а →

не терялись (насколько это возможно).

Дык опенвпн реализует тцп функционал. Так что не должны.

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

mtu? :)

Нет, дело не в MTU. OpenVPN нужно прокинуть через «городскую локалку» местного провайдера. Там обычный ethernet. Проблема в том, что эта локалка под завязку забита p2p-трафиком.

Deleted
()

Вот нашёл статейку: http://asiantuntijakaveri.wordpress.com/2011/12/30/ab_using-openvpn-to-make-two-unrealiable-internet-connections-act-as-one-reliable-connection-success/. Автор решил подобную проблему дублированием пакетов.

Только мне -j TEE не очень подходит, так как адреса динамические. Вопрос: как ещё можно заставить систему дублировать пакеты? В man iptables больше ничего похожего не нашёл...

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

Странно, у меня как раз в режиме TCP по плохому каналу работало лучше, чем UDP, это в общем-то логично, т.к. ретрансмиты уже происходят вне туннеля.

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

Я придумал. Надо через LD_PRELOAD подгрузить самодельную тривиальную библиотеку которая будет дублировать нужные сисколлы типа sendto и send если сокет нужной фамили и подключен куда нужно. Еррно возвращать от первого вызова и не делать второй если был еррно. Для отслеживания таких сокетов можно сделать перехват connect, socket dup2 dup dup3 и close.

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

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

Странно, у меня как раз в режиме TCP по плохому каналу работало лучше, чем UDP, это в общем-то логично, т.к. ретрансмиты уже происходят вне туннеля.

У меня TCP часто рвался и лежал где-то по пол минуты. Возможно дело в настройках TCP-стека...

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

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

пакет нужно отправлять ровно посреди промежутка до следующего - или вместе со следующим

а на другом конце openvpn-а возможно ли чтото добавлять - иль там только стандартный openvpn ?

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

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

А может проще сделать? Наверняка в зоне прямой видимости есть другие сети. Попробуйте построить радиоканал на nanobridge m5 на пример, до какой-нибудь более вменяемой сети, а там уж проще будет. На 4-5 километров 90 мегабит в обе стороные высасывает в лет без потерь.

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

Бутылочное горлышко

дублирование пакетов тебе не поможет

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

пакет нужно отправлять ровно посреди промежутка до следующего - или вместе со следующим

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

Но идея интересная. У меня уже зарождается мысль сделать патч для openvpn =).

а на другом конце openvpn-а возможно ли чтото добавлять - иль там только стандартный openvpn ?

Сейчас на одном конце домашний сервер с убунтой, а на другой - DIR-320 с dd-wrt какой-то лохматой версии, просто потому что мне было лень собрать openwrt. В принципе и там и там можно наворотить что угодно.

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

Выше предложили ещё один вариант: перехватывать вызовы функций отправки пакетов своей библиотекой, подгруженной через LD_PRELOAD.

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

Уточню...

Я не указал в первом сообщении, что ping работал не через ovpn-туннель, а через соединение, поверх которого его нужно организовать.

Deleted
()
Ответ на: Бутылочное горлышко от Deleted

«В моём случае как раз скорее всего поможет, так как пакеты теряются не из-за какой-то абстрактной проблемы в сети, а из-за того, что некий свитч/роутер между пирами отбрасывает часть пакетов просто потому что они не пролазят в канал.»

именно именно - я про этот самый случай - когда не пролазят пакеты - догадайся что оно сделает с 2мя пакетами что пришли с разницей в микросекунду

поэтому между дубликатими должен быть приличный промежуток

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

именно именно - я про этот самый случай - когда не пролазят пакеты - догадайся что оно сделает с 2мя пакетами что пришли с разницей в микросекунду

Это сильно зависит от алгоритма работы роутера. Тут бы лучше не гадать, а провести эксперимент, но сейчас нет возможности...

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

а то что ты пинговал - как далеко находиться и что за линии связи ? минимум в 1.5 мс - это похоже на что то вроде езернета гдет 10мбит нагруженного + к тому - такое скакание пинга - имхо указывает на более шедяшее чем рандомный дроп пакетом - указывает что ограничитель хоть как то но пытается затормозить поток (скорее всего ошибаюсь все таки)

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

а то что ты пинговал - как далеко находиться и что за линии связи ? минимум в 1.5 мс - это похоже на что то вроде езернета гдет 10мбит нагруженного + к тому - такое скакание пинга - имхо указывает на более шедяшее чем рандомный дроп пакетом - указывает что ограничитель хоть как то но пытается затормозить поток (скорее всего ошибаюсь все таки)

Это сеть провайдера. Длину линий связи между точками не знаю, физическое расстояние - 10 минут пешком 8). Последняя миля - ethernet 100мбит/с, между узлами у самого провайдера - предположительно оптика.

Могу точно сказать, что сеть забита файлообменом (eD2k). Высокий приоритет отдаётся только пакетам до серверов провайдера (внутренние ресурсы, pptp в интернет).

Deleted
()
Ответ на: Бутылочное горлышко от Deleted

Патч, ИМХО, правильная мысль. Вроде, должно быть достаточно в файле socket.h в функции link_socket_write ещё раз вызвать link_socket_write_udp, дублировать запись в tcp-сокет смысла нет.

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

а - локалка домового прова
тут даж и незнаю
таки да - попробуй пропатчить на отсылка по 2 иль по 3 даж пакета
то и покажет результат

ae1234 ★★
()

Ну, допустим ты даже построишь этот канал - а будет ли смысл его юзать с такими дропами?

В любом случае, ИМХО проще попробовать затюнить тисипи стек, чем патчить опенвпн. Поставить побольше tcp reorder, уменьшить таймауты ретрансмита, увеличить прочие таймауты, чтобы коннект не падал, сменить tcp congestion алгоритм, их там десяток в ядре вроде, уменьшить окно tcp до минимума, чтобы ретрансмитилось поменьше пакетов при потере одного. Ну и т.п.

Почитать гугль на тему TCP on lossy links.

blind_oracle ★★★★★
()

Рекомендуют вроде congestion алгоритм Westwood.

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

А почему -j TEE не очень подходит? Адрес шлюза то ведь не меняется и должно хватить просто

-o eth0 -j TEE −−gate-way Шлюз_для_eth0

Наверное, можно попробовать добавить это правило на сервере с убунтой и попинговать D-link, пинг будет ругаться на дубли, но будет видно, изменилась ли статистика прохождения пакетов.

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

А почему -j TEE не очень подходит? Адрес шлюза то ведь не меняется и должно хватить просто

-o eth0 -j TEE −−gate-way Шлюз_для_eth0

Меняются оба адреса. У провайдера в локалке работает DDNS, и openvpn соединяется по имени сервера. Но для TEE пришлось бы городить костыли на скриптах.

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

Ну, допустим ты даже построишь этот канал - а будет ли смысл его юзать с такими дропами?

В любом случае, ИМХО проще попробовать затюнить тисипи стек, чем патчить опенвпн. Поставить побольше tcp reorder, уменьшить таймауты ретрансмита, увеличить прочие таймауты, чтобы коннект не падал, сменить tcp congestion алгоритм, их там десяток в ядре вроде, уменьшить окно tcp до минимума, чтобы ретрансмитилось поменьше пакетов при потере одного. Ну и т.п.

Почитать гугль на тему TCP on lossy links.

Тоже вариант. Как будет время - погуглю.

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

Всё время меняется default gateway в настройках сетевой?

В любом случае можно просто попробовать TEE для icmp-пакетов, чтобы было видно, поможет ли отправка двух пакетов подряд. Может там действительно длительные временные интервалы когда дропаются все пакеты подряд.

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

затюнить tcp не получиться
просто потому что tcp реагирует постфактум на проблему - он реагирует если происходит потеря - иль задержка пересылки
он лиш пытается предсказать будущее

а мы УЖЕ знаем что будут потери - и дублированием пакетов возможно это очень сильно исправить

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

во первых выяснить зависимость процента потерь от размера пакета и tos. Размер пакета при котором потери минимальны будет новым mtu для туннеля, а соотв.tos будете ставить на исх.пакеты.

далее попробовать другие туннели (на ovpn свет клином не сошёлся), или сажать ovpn на порт который пров.может считать приоритетным.

на крайний случай сделать свой велосипедный туннель :) точка-точка с групповым квитированием и переповторами. Если поток небольшой - это не шибко сложное дело

MKuznetsov ★★★★★
()
Ответ на: Бутылочное горлышко от Deleted

Но идея интересная. У меня уже зарождается мысль сделать патч для openvpn =).

Было бы круто если еще и выложишь. У меня такая же проблема, но у меня правда не свитч режет,а просто кривой 3g + большое растояние до вышки. К сожалению не уменьшение пакета udp, ни изменение алгоритма шифрации(без него аса не коннектит (: ) не помогло. Правда сейчас по историческим прицинам используется vpnc на стороне клиента и с той стороны ASA(уже мной немного ненавистная в виду обнаружения некоторых багов (: ) . Проблема еще в том,что в офисе все решения отлично пашут(правда там сигнал не очень),а вот в некоторых особенно глухих местах Баку начинается ад, причем он имеет свойство Гейзенбага .

P.S Просто наболело , что пару точек не могу никак добить.

pinachet ★★★★★
()
29 января 2013 г.
Ответ на: комментарий от x905

какое в итоге получилось решение ?

Никакого. Отпала необходимость.

Deleted
()

Соединение работает постоянно, но стабильно теряет около половины пакетов:

Как включение организовано? TCP+TCP?

Macil ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← procmail не сортирует почту
Admin
Аналог | begin ios-а →