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

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

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

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

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

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

4G

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

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

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

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 и наверняка это решение было обоснованным.

Why TCP Over TCP Is A Bad Idea

«TCP поверх TCP – не такая уж плохая идея!»
http://samag.ru/archive/article/603

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

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

Видимо, «не во всех регионах» - ключевое :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так что да, на заведомо чистом канале лучше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в статье по тому 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 увидит, что сервер уже давно про него забыл, и переподключится.

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

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

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

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

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

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

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

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

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

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

# Send a UDP ping to remote once
# every 15 seconds to keep
# stateful firewall connection
# alive.  Uncomment thiis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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