LINUX.ORG.RU
ФорумAdmin

OpenVPN на OpenWRT - Нет подключения.

 , ,


0

1

Здравствуйте, форумчане, помогите советом. Есть роутер TL-WR1043ND, на нем установлен openWRT и openVPN. Раньше WAN был настроен pptp и имелся статический адрес, VPN поднимался и работал через интернет. Сейчас интернет подключен через 4G модем и DDNS. 4G в режиме HiStick (роутер с сетевым интерфейсом) Интернет есть, DDNS получает IP, к VPN серверу подключение не удается. Я не специалист, поэтому прошу помощи! Куда копать?

Конф клиента
client
#tls-client
dev tun
proto udp
remote 11111111.ddns.net 1194 # доступный из Интернет внешний IP-адрес роутера
#resolv-retry infinite # this is necessary for DynDNS
nobind
#user nobody #???
#group nogroup #???
ca ca.crt
cert client1.crt
key client1.key
dh dh2048.pem
persist-tun
persist-key
comp-lzo #???
#redirect-gateway
verb 3

Конф сервера

config openvpn 'lan'
option enabled '1'
option port '1194'
option proto 'udp'
option dev 'tun'
option ca '/etc/easy-rsa/keys/ca.crt'
option cert '/etc/easy-rsa/keys/server.crt'
option key '/etc/easy-rsa/keys/server.key'
option dh '/etc/easy-rsa/keys/dh2048.pem'
option ifconfig_pool_persist '/tmp/ipp.txt'
option keepalive '10 120'
option comp_lzo 'yes'
option user 'nobody'
option group 'nogroup'
option persist_key '1'
option persist_tun '1'
option status '/var/log/openvpn-status.log'
option verb '3'
option client_to_client '1'
option client_config_dir '/etc/openvpn/ccd'
option server '10.0.0.0 255.255.255.0'
list push 'route 192.168.200.0 255.255.255.0'
list push 'route 192.168.201.0 255.255.255.0'

Лог подключения

Fri Dec 01 16:40:06 2017 OpenVPN 2.3.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Mar 19 2015
Fri Dec 01 16:40:06 2017 library versions: OpenSSL 1.0.1m 19 Mar 2015, LZO 2.08
Fri Dec 01 16:40:07 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Dec 01 16:40:07 2017 Need hold release from management interface, waiting...
Fri Dec 01 16:40:07 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Dec 01 16:40:07 2017 MANAGEMENT: CMD 'state on'
Fri Dec 01 16:40:07 2017 MANAGEMENT: CMD 'log all on'
Fri Dec 01 16:40:07 2017 MANAGEMENT: CMD 'hold off'
Fri Dec 01 16:40:07 2017 MANAGEMENT: CMD 'hold release'
Fri Dec 01 16:40:07 2017 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Fri Dec 01 16:40:07 2017 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Dec 01 16:40:07 2017 MANAGEMENT: >STATE:1512128407,RESOLVE,,,
Fri Dec 01 16:40:08 2017 UDPv4 link local: [undef]
Fri Dec 01 16:40:08 2017 UDPv4 link remote: [AF_INET]176.59.197.2:1194
Fri Dec 01 16:40:08 2017 MANAGEMENT: >STATE:1512128408,WAIT,,,
Fri Dec 01 16:41:09 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Dec 01 16:41:09 2017 TLS Error: TLS handshake failed
Fri Dec 01 16:41:09 2017 SIGUSR1[soft,tls-error] received, process restarting
Fri Dec 01 16:41:09 2017 MANAGEMENT: >STATE:1512128469,RECONNECTING,tls-error,,

Сертификаты до 25 года. Смущает tls-error.

Ваша проблема вот здесь:

No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.

По ссылке ходили? Пробовали переделывать ключи в соответствии с приведенными рекомендациями?

И второй вопрос по конфигурации, не имеющий отношения к Вашей проблеме - почему выбрали протокол udp? Ладно, когда подключение по ethernet, но у Вас-то 4G, а значит, могут быть помехи, искажения пакетов и т. п. IMHO, выбор tcp в качестве несущего протокола для OpenVPN выглядит более логично...

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

Так ведь работали ключи. На tcp завтра попробую переключить, спасибо, но не думаю что принесет пользу....

sogrin ()

4G

Вам выдает реальный адрес? Вы точно в этом уверены? Обычно у опсосов это от - стоит доп. денег, до - услуга не предоставляется (хрена вам даже за деньги).

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

Ладно, когда подключение по ethernet, но у Вас-то 4G, а значит, могут быть помехи, искажения пакетов и т. п.

И как это по вашему мнению tcp спасет в данном случае от «искажения пакетов» ?

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

IMHO, выбор tcp в качестве несущего протокола для OpenVPN выглядит более логично...

Насколько я знаю, это плохая идея, потому что при потерях пакетов начинают перепосылки и тот tcp, по которому работает vpn, и тот tcp, который внутри туннеля, и пока мы ждём успешной перепосылки через внешний tcp, внутренний может наплодить кучу своих пакетов с перепосылками, потому что он не видит, чтобы пакеты доходили (мы ведь ждём один тот несчастный пакет, потерянный внешним tcp), и шлёт новые, потому что у него адаптивный таймаут пока что меньше, создавая ещё больше проблем, потому что на нестабильном соединении и новые пакеты могут потеряться, эффект будет лавинообразным.

Когда же у нас IP -> UDP -> OpenVPN -> IP -> TCP, то такой проблемы нет, все слои ниже TCP спокойно дропают пропавшие пакеты, а TCP занимается перепосылками.

Когда у нас IP -> TCP -> OpenVPN -> IP -> UDP, то это не имеет смысла, так как тогда у нас по UDP получится гарантированная доставка всего (из-за TCP под низом) в ущерб быстрого времени доставки, которое ожидается от UDP. А гарантированная доставка от UDP как раз не ожидается.

Тут есть инфа на этот счёт подробнее: http://sites.inka.de/bigred/devel/tcp-tcp.html

Note that the upper and the lower layer TCP have different timers. When an upper layer connection starts fast, its timers are fast too. Now it can happen that the lower connection has slower timers, perhaps as a leftover from a period with a slow or unreliable base connection.

Imagine what happens when, in this situation, the base connection starts losing packets. The lower layer TCP queues up a retransmission and increases its timeouts. Since the connection is blocked for this amount of time, the upper layer (i.e. payload) TCP won't get a timely ACK, and will also queue a retransmission. Because the timeout is still less than the lower layer timeout, the upper layer will queue up more retransmissions faster than the lower layer can process them. This makes the upper layer connection stall very quickly and every retransmission just adds to the problem - an internal meltdown effect.

TCPs reliability provisions backfire here. The upper layer retransmissions are completely unnecessary, since the carrier guarantees delivery - but the upper layer TCP can't know this, because TCP always assumes an unreliable carrier.

Мне также интересно услышать комментарий ValdikSS на этот счёт. Насколько я знаю, у них на https://zaborona.help/ используется TCP и наверняка это решение было обоснованным.

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

МТС - корп клиентам выдает статику (возможно не во всех регионах). Динамику вроде даже частникам выдавала.
Мегафон - вроде тоже что-то предлагает.

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

Мне также интересно услышать комментарий ValdikSS на этот счёт. Насколько я знаю, у них на https://zaborona.help/ используется TCP и наверняка это решение было обоснованным.

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

sogrin, вам нужно либо купить маршрутизируемый IP-адрес (чаще всего услуга называется «статический IP»), либо использовать промежуточный VPN-сервер с маршрутизируемым IP-адресом.

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

У UDP таймауты, особенно в мобильных сетях, гораздо ниже

Чегой-то не вкурил за какие таймауты речь? Поясните плиз.

чаще всего услуга называется «статический IP»

У опсосов разделяются услуги cтатический и динамический, могут предоставлять только динамический. На примере мегофона у них динамика называется «Выделенный IP-адрес». Во втором случае ТС ddns поможет.

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

Чегой-то не вкурил за какие таймауты речь? Поясните плиз.

Я так понял, это об поддержании conntract NAT для UDP.

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

И как это по вашему мнению tcp спасет в данном случае от «искажения пакетов» ?

Затребует повторную пересылку битого пакета.

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

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

Хм, интересная мысль. А почему Вы уверены, что внутренний tcp будет генерировать запросы на повторную передачу, а не просто замрет, дожидаясь нужных пакетов? Я как-то отслеживал снифером трафик на моб. интерфейсе с очень низким уровнем сигнала - у меня просто приостанавливался поток данных (пинг до 10-20 с доходил). Никакого лавинообразного эффекта не было.

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

Хрен купишь адрес что у МТС, что у Мегафона.

Не знаю, как у Мегафона, но Yota (вроде сейчас тот же Мегафон?) статические адреса на халяву раздавала владельцам своих модемов. Может, сейчас уже и не так, не знаю, подключался еще во времена WiMax...

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

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

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

А почему Вы уверены

А я не писал, что я уверен, я сказал: «Насколько я знаю» :D

Соответственно, сослался на источник, где я это когда-то прочитал. Тов. pekmop1024 привёл ответную ссылку, где аргументированно высказывается противоположное мнение и проводятся измерения.

Я как-то отслеживал снифером трафик на моб. интерфейсе с очень низким уровнем сигнала - у меня просто приостанавливался поток данных (пинг до 10-20 с доходил). Никакого лавинообразного эффекта не было.

В ответной статье как раз об этом пишут:

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

Так что, похоже, в TCP для туннеля действительно нет ничего плохого. Как я понял, TCP через TCP только внесёт незначительный оверхед в виде передачи чуть большего количества данных, а UDP поверх TCP хорош тем, что TCP подстроится под реальную скорость канала, и не будет отправок UDP-пакетов впустую.

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

придется чаще отправлять пакеты keep-alive, чтобы поддерживать сессию. Это заметно уменьшает время работы телефона от батареи.

Действительно, была такая проблема. При частых keep-alive батарейку жрало как не в себя, а при редких отваливалось при неиспользовании, но показывало, как будто подключено, приходилось переподключаться руками. Сейчас стоит keepalive 30 60, вроде, работает нормально, но теперь попробую попользоваться туннелем через TCP, если так не придётся находить компромисс между стабильностью и энергопотреблением.

У UDP таймауты, особенно в мобильных сетях, гораздо ниже

Я правильно понял, что речь идёт о таймаутах, в течение которых stateful NAT держит у себя в таблице информацию о «соединении»? О которых говорится по ссылке.

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

А я не писал, что я уверен, я сказал: «Насколько я знаю»

В любом случае спасибо за инициацию интересной дискуссии :).

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

Ну вот мы и переходим к следующему вопросу а что будет в случае использования udp ?

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

Так что, похоже, в TCP для туннеля действительно нет ничего плохого.

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

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

Взяли одну статью непонятно кого, непонятно что мерящую

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

  • Как минимум у нас есть (искусственный, да) пример, когда TCP не хуже.
  • На мобильнике TCP должен работать стабильнее (из опыта ValdikSS).
  • В этой статье есть важный факт, что внутренний TCP не будет пытаться многократно перепосылать пакеты, пока тупит внешний TCP, поэтому лавинообразного эффекта не будет.
gentoo_root ★★★★★ ()
Ответ на: комментарий от gentoo_root

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

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

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

А про один поток TCP вы специально скипнули. Да, на одном не будет, так как внешний при одинаковых настройках действительно по определению будет срабатывать быстрее. Но это, во-первых, будет полечено только при отсутствии дальнейших потерь и при одном потоке.

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

А какая разница, ну будет у нас два потока. Вот потерялся один пакет, например. Это означает, что внешний TCP должен будет обнаружить потерю и перепослать. Один из внутренних TCP тоже обнаружит потерю (у другого ничего не терялось), но он не будет срабатывать быстрее внешнего. Пока раздупляется внешний TCP, второй внутренний TCP может обнаружить, что данные не ездят, и тоже захочет перепослать, но так как он сбросится на самую медленную скорость, он максимум перепошлёт один пакет, если во внешнем TCP выпал только один пакет, а если внешний TCP раздупляется долго (выпало много пакетов подряд), то второй внутренний всё равно будет это делать не быстрее внешнего, лавины не будет.

Где в моих рассуждениях ошибка? Как появление двух TCP-потоков может всё испортить?

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

А какая разница, ну будет у нас два потока. Где в моих рассуждениях ошибка?

Оба потока будут стоять. А при UDP будет стоять только тот поток, у которого пропал пакет.

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

Оба потока будут стоять.

Согласен, спасибо.

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

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

TCP довольно быстро сообразит

Увы, это как раз не быстро. Собственно все вот эти проблемы с «огромным пингом» это не всегда время восстановления канала, а время ретрансмиссии TCP (в статье по тому URL почему-то это назвали slow-стартом, хотя это совсем другое). А вот с UDP вы увидите по ping-у когда на самом деле канал восстановился.

Честно говоря, я так до сих пор и не понял, в чём неприятие UDP? Его вскольз проходят в отличии от TCP? То, что может быть только одна дырка просверлена в файрволе с одним портом TCP то это дело понятное, но нельзя же это экстраполировать на общую картину мира.

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

Собственно, исключая корпоративное использование, остальные юзкейсы так или иначе подразумевают или ограниченное, или серьезно ограниченное подключение (когда, например, вообще наружу пускают только на tcp 80 и 443, причем ssl connect пролазит только на tcp 443). Так что да, на заведомо чистом канале лучше UDP, на неизвестном или заведомо ограниченном - TCP.

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

27 сообщений в теме, из них два моих, одно немного мне по теме, остальные можно вынести в отдельную тему..

Обычное дело для ЛОРа :) Дерева же комментарий нет, вот и даже не видно, были ли выше ответы на конкретный вопрос, или с первых же ответов ушло не туда.

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

Ну вот опять. Ниоткуда не следует это ваше «так».

Твои попытки игнорировать фактическую ситуацию, то есть опыт людей, выглядит смешно. Я тебе приведу бытовой пример. Есть куча общественных точек с каптив порталами авторизации. Так вот на них, как правило, вообще ничего не работает, кроме 80 и 443. А это, между прочим, самый массовый из «законных» юзкейсов для vpn, ибо все эти точки работают без шифрования.

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

Так вот на них, как правило, вообще ничего не работает, кроме 80 и 443.

И потому UDP не нужен? Л - логика. Высший пилотаж.

Я даже подозреваю откуда вот такие появляются, открывающие только 80/443, забывая про dns и прочий icmp, потому ничего не резольвится и пакеты не ходят через этот туннель толком, так как без icmp вы с урезанным mtu по определению в большистве мест получите дулю. Имеено вот такие как вы с такой вот логикой, что кроме tcp ничего не надо.

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

Снова срач начался по поводу tcp или udp. Не так давно было c тем же персоонажем.

Ну дык. Носятся с одним URL-ом, написанным с такой же логикой как все тут персонажи, и думают, что они что-то этим доказали. Рассматривают один поток, делают потери путём шейпинга и распространяют эти дичайше специфичные результаты на всё мироздание. Но вот вякнуть из-за угла удержаться не могут.

Причём самое смешное, что даже там написано «tcp почти не хуже», но это же ЛОР, это в тутошних мозгах поциэнтов сразу же преобразуется в UDP не нужен.

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

И потому UDP не нужен?

Я где-то писал, что он не нужен? Цитату или ты балаболка дешевая.
Я писал о том, что openvpn@tcp имеет больше шансов пролезть через любые ограничения, по сути, если он будет жить на tcp 443, то пролезет всегда.

Имеено вот такие как вы с такой вот логикой, что кроме tcp ничего не надо

Ты откуда знаешь, какой и в чем моя логика? Экстрасенс? А справка есть? А если найду?

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

Я где-то писал, что он не нужен? Цитату или ты балаболка дешевая.

Да наздоровье, лечитесь: OpenVPN на OpenWRT - Нет подключения. (комментарий)

Да и вообще, вы раз за разом тут прогандируете дурацкую идею, приводя один и тот же URL, где в общем-то только желтый заголовок, а на самом деле доказывается, что TCP не сильно хуже, что при прочих равных TCP лучше. Все попытки прощупать что вы и ваши соратники по этой адептности понимания этих эффектов (ну мало ли, может я что-то тоже упустил) натыкаются на отсылки «люди меряли».

больше шансов пролезть через любые ограничения,

На самом деле это тоже фигня полная. Если у вас не proxy, а именно открытый 80/443 порт, то скорее всего как раз более пролезаемый туннель как раз делается по UDP на основе dns-туннеля, правда медленно и печально, но факт. Есть и icmp-туннель. Есть вообще прикольный в своей сути туннель, основанный на обычной ситуации в настройке брадмауэров, которые открывают прохождение без проверок устоявшихся TCP соединений, а это по своей сути мало похоже на системный TCP, так как все пакеты приходится формировать руками.

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

Да наздоровье, лечитесь: OpenVPN на OpenWRT - Нет подключения. (комментарий)

Да ты не просто балаболка, ты дешевый демагог, вырывающий цитаты из контекста. Читать до просветления сообщение, где написаны полностью все условия: OpenVPN на OpenWRT - Нет подключения. (комментарий)

На самом деле это тоже фигня полная

Хорош жопой вертеть. Мы говорим о openvpn, а он не умеет ни в dns-туннели, ни в icmp-туннели.

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

в статье по тому URL почему-то это назвали slow-стартом, хотя это совсем другое

Хотелось бы услышать комментарий, почему это другое. Насколько я понял из википедии, при потере пакета происходит slow start:

On timeout:

  • Congestion window is reset to 1 MSS.
  • «ssthresh» is set to half the congestion window size before segment loss started.
  • «slow start» is initiated.

Или если потеряется один пакет, это не таймаут? Может, получатель как-то просигнализирует отправителю, что одного пакета в середине потока не хватает? По идее, тогда это будет быстрее slow start'а?

Честно говоря, я так до сих пор и не понял, в чём неприятие UDP?

У меня не неприятие udp, у меня vpn, к которому подключается дома роутер, а не дома мобильный телефон через мобильный интернет. Он у меня работает через udp, дома всё стабильно, а с телефонов есть проблемы, о которых говорил ValdikSS. Проблемы с фаерволом, пропускающим только TCP 80 и 443, у меня нет. Но я хочу попробовать попользоваться тут TCP, если это решает проблему с отпаданием туннеля.

Задумался тут по поводу UDP-туннеля. Если даже NAT удалил у себя запись о «соединении», то интересно, что мешает openvpn'у после перерыва начать передавать данные, conntrack пересоздастся, openvpn увидит, что сервер уже давно про него забыл, и переподключится.

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

Читать до просветления сообщение

Дядя, всё просветление и было вычлененно, ибо до этого была дичайшая чушь. Именно в корпоративном инете самое обычное как раз дело по закрытию всего кроме 80/443, в остальных случаях как раз сейчас вполне нормальный конекшн с сетевым нейтралитетом, где если что и закрыто, то максимум 25 и прочий smb. Это во-первых. Во-вторых, всё как обычно началось с повторения вот этого: http://samag.ru/archive/article/603 Тут, если вы читали, про 80/443 ничего и нет, и понятно, почему. Зато есть сплошные «проказы шаловливого кабельщика». Ну оно и понятно, по вашему быдячему уровню в самый раз.

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

Хотелось бы услышать комментарий, почему это другое. Насколько я понял из википедии, при потере пакета происходит slow start:

Нет. Подстройка скорости и потеря пакета — разные вещи. Почитайте дальше вашу же ссылку про ретрансмиссии. Кстати да, при том эскперименте от Барабанова с шейпером как раз были потери по перегрузке канала. Но это же опять проблема одного tcp конекшена. Когда их уже два, то они подстраивают свою скорость уже внутри туннеля и получается бардак. Так что - спасибо за вопрос! Он в самом деле кое-что прояснил и застаил подумать. :)

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

Именно в корпоративном инете самое обычное как раз дело по закрытию всего кроме 80/443

Ты еще и не отличаешь понятия «корпоративное применение» и «корпоративная среда». Трайпл фейспалм, с пробитием до затылка...

вашему быдячему уровню в самый раз

ad hominem во всей красе :)
других аргументов-то нет, а признать, что ты в очередной раз обосрался, ты не способен.

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

Он у меня работает через udp, дома всё стабильно, а с телефонов есть проблемы, о которых говорил ValdikSS.

Но про эту проблему авторы openvpn знают и включили в конфиг

# Send a UDP ping to remote once
# every 15 seconds to keep
# stateful firewall connection
# alive.  Uncomment thiis
Вы пробовали? Сейчас открою великую тайну — у меня работает с этой опцией.

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

Ты еще и не отличаешь понятия «корпоративное применение» и «корпоративная среда».

Во-первых, так всё жопкой и вертим. И ладно бы получалось, но ведь именно так и продолжаете лажать. Именно в среде и запрещено, а при использовании — нет никаких проблем. Отсюда, кстати вывод, если у вас запрещено, то и желание вылезти за — как минимум неэтично.

других аргументов-то нет,

Во во. Детсад в самой красе. Вместо каких либо технических доводов проявили свою бюдлячую натуру, а как получили ответку, так сразу за штампы и перевод стрелок.

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

Вы пробовали? Сейчас открою великую тайну — у меня работает с этой опцией.

Да. Каждые 15 секунд — это неимоверный жор батареи на андроиде, выше по треду упоминалось всё в том же сообщении от ValdikSS, и мной лично это тоже испытано. С 30 секундами работает сносно, но тоже не могу 100% сказать, что не было зависшего туннеля. А так да, действительно не виснет, если поставить пинги почаще.

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

Каждые 15 секунд — это неимоверный жор батареи на андроиде

А, вон вы про что... Ну про постоянный конекшн там тоже есть, всякие persist-*, но я не пробовал. Но если 30 секунд это жор, то наверное что-то в консерватории что-то надо править. :)

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

Почитайте дальше вашу же ссылку про ретрансмиссии.

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

Подстройка скорости и потеря пакета — разные вещи.

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

А если пакет потеряется просто так, это окажет влияние и на алгоритм подстройки скорости, заставив его снизить скорость.

Когда их уже два, то они подстраивают свою скорость уже внутри туннеля и получается бардак.

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

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

Но если 30 секунд это жор

30 секунд ещё более-менее. Это то значение, на котором я пока что остановился (tcp ещё не успел попробовать). Но даже с ним OpenVPN Connect занимает первую строчку по энергопотреблению со своими 8% жора (на данный момент; я сегодня не очень активно пользовался телефоном).

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

Это не должно быть долгим процессом.

Но поток полностью замирает, последующие пакеты отдаваться ядром приложению (openvpn) не будут. При UDP может даже и не понадобиться потерянный пакет, например, если мы смотрим видео по UDP, то замирание и перезапрос пакетов только всё ухудшит и будет более заметен, чем потеря одного кадра.

Но ведь подстройка скорости основана на потерях пакетов.

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

Не вижу причины бардака.

Плохо. Отсутствие проблемы нескольких соединений в обычной сети решается именно подстройкой в среде с потерями. А вы меняете среду на способную потери компенсировать. И получается каша.

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

на данный момент; я сегодня не очень активно пользовался телефоном

А вы точно не смешали проблему отвала conntrack и потребления по активности? Ну 8% за сутки хоть и обидно, но жить наверное можно, вайфай бы больше сожрал. Дома у меня вообще vtun с собственным патчем, сжимающий IP, юзаю я его без шифрации кроме самого пароля на соединение. Смысл шифровать, если б без vpn я бы вообще ходил через провайдера в «открытую». Там где надо поадминить, там уже ssh.

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