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.



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

А вы меняете среду на способную потери компенсировать.

Она ведь тоже не волшебная. Если мои внутренние потоки начнут фигачить слишком быстро, быстрее, чем может передать внешний tcp, то у них начнутся таймауты. Да, будет тупак в том, что задержавшиеся пакеты всё равно потом придут, но их задержка позволит внутренним tcp-потокам подстроить скорость.

А вы точно не смешали проблему отвала conntrack и потребления по активности?

А тут нужно искать компромисс между одним и другим. Частые пинги — не отваливается туннель, но батарейка тает на глазах. Редкие пинги — батарейка держит долго, но туннель отваливается. Нужно какое-то среднее значение, и самое разумное, что я нашёл путём подбора, это keepalive 30 60.

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

Во-первых, так всё жопкой и вертим

Самокритично.

Именно в среде и запрещено, а при использовании — нет никаких проблем

Именно об этом и написано в посте, который тебе не понравился. Читать научись, умник.

Вместо каких либо технических доводов

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

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

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

Встречал забавный вариант реализации wifi с регистрацией, в которой udp был таки открыт. Так что лучше держать все варианты. :)

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

Встречал забавный вариант реализации wifi с регистрацией, в которой udp был таки открыт. Так что лучше держать все варианты. :)

Бывает. Мне попадались даже варианты, когда на udp шейпер не работал. Т.е. если просто так юзать или openvpn@tcp - режет на 2 мбит/с, а если на udp перейти, качает во всю толщину канала :)

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

Встречал забавный вариант реализации wifi с регистрацией, в которой udp был таки открыт.

Вы про то, что там даже dns работал? Ну надо же, как там лопухнулись, с ума сойти... Кстати, туннели over dns появились как раз по причине, что некоторые как сотовые так и проводные провайдеры ленились закрывать dns на резольвинг чего-то больше, чем страница оплаты/авторизации.

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

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

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

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

Как известно, практик всегда пристрелит теоретика.

Кому известно? Быдлу? Ну да. А практики делали туннели на IP (ipip) и GRE когда вы ещё и не родились. А там на минуточку, даже плюшек UDP то нет, всё ещё намного «хуже», хотя на самом деле ведь лучше, но вам с такими познаниями расписыать - только время терять. А если вспомнить, что *DSL-и, ppp, pppoe и пр. это в этом смысле ничем от туннелей не отличается...

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

А ещё когда-то жили без электричества... Прекращай вертеть жопой и сползать с темы. Хотя тебе ведь по теме нечего сказать, ты сам прекрасно знаешь, что не прав.

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

А ещё когда-то жили без электричества..

И этот поц что-то мямлит по поводу «сказать по теме».

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

ты сам прекрасно знаешь, что не прав.

Видите ли. Я могу рассказать как работал IP over X.25, откуда собственно пошло мои разбирательства, почему среда с восстановлениями пакетов плоха для инкапсуляции IP, могу рассказать, что современный радиолюбительский обмен IP по радио в этом смысле такой же велосипед один в один, а то и прямо натуральный IP over X.25, вон рассказываю в соседней дискуссии как получаются мусорные пакеты в такой среде. Но вы же раз за разом даже не пытались вникнуть, а как тупое быдло демонстрируете тупняк из подворотни, как и в том URL насчёт того виртуального собеседника с кем там автор спорит, обзывая его шаловливым кабельщиком, но на самом деле делающий глобальные выводы на крайне ограниченном эксперименте. Мелко, Хоботов. И не интересно. Можете записывать себе пиррову победу, отвечать вам дальше никакого смысла я не вижу.

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

Я могу рассказать как работал IP over X.25

Ты можешь пытаться дальше с темы спрыгивать, вместо того, чтобы говорить о том, о чем мы конкретно говорим. А именно о фактическом поведении openvpn на разных транспортах и разных средах.

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

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

Кстати, туннели over dns появились как раз по причине, что некоторые как сотовые так и проводные провайдеры ленились закрывать dns на резольвинг чего-то больше, чем страница оплаты/авторизации.

Ну если уж копать историю, то поначалу был просто открыт 53 порт и народ стал вешать тунели на него.

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

Ну если уж копать историю, то поначалу был просто открыт 53 порт и народ стал вешать тунели на него.

Мне всегда казалось, что именно исторически все делали локальный dns. Доходило до того, что локальные форумы и треккеры у нас в области резольвились если только указать форвард на dns своего провайдера, вхожего в местный IX. И трафик экономился, и локальный трафик быстрее летал и даже какой microsoft.com уже был в кеше провайдера и тоже быстрее. Наружу сверлить файрвол на любой адрес доступ UDP 53 мог делал только полный оболтуc. :)

Ну и таки, логически рассуждая, туннель over dns для открытого куда угодно UDP:53 не нужен, это просто открытый UDP. Он нужен именно получать, совершенно законно, часто обновляемую вашу зону c закодированными записями=пакетами.

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

Мне всегда казалось, что именно исторически все делали локальный dns. Доходило до того, что локальные форумы и треккеры у нас в области резольвились если только указать форвард на dns своего провайдера, вхожего в местный IX. И трафик экономился, и локальный трафик быстрее летал и даже какой microsoft.com уже был в кеше провайдера и тоже быстрее.

То что я описывал было чуть до описанного вами, т.е. когда еще массово не пошли локальные ресурсы. :) Тогда выделенный инет стоил вполне себе немало, и пользователей было не дофига, провода у юзверей за не уплату никто не рубил, ситуация что юзер заплатил за месяц а потом полгода не платит была достаточно распространенной, отрубить физически могли разве что по причине нехватки портов в свиче для подключения нового юзвера. Вот народ хто по умнее (ит-ки) и устраивал халявные тунели до работы ну а через нее в инет. Кстати в те времена и юзверам еще белые ip полных ходом раздавали, серыми не заморачивались.

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

То что я описывал было чуть до описанного вами, т.е. когда еще массово не пошли локальные ресурсы.

У нас это было во времена модемов, и отключались тогда юзверя очень просто и по другому и не могло быть: переставало логиниться. Мы быстренько купили Zelax и сидели на синхронном порте. Но и тогда нормальным считалось держать у провайдера свои сервера irc (бесплатный) и news/mail (платные), ну и dns само-собой. А как пошёл dsl, так появился халявный областной трафик, без ограничений скорости и объёмов. Серые адреса были у тех ОПГ (sic!), кто в IX не шёл. Ну а массовый эзернет примерно совпал с появлением безлимитов, пусть и с оговорками, и локалки постепенно свернулись за ненадобностью, осталось irc/Инет-радио-ретрансляция/форум.

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

Да. Страна большая. У кого как было. Я описывал ДС - ethernet - местечковые провы. Кстати внутренние ресурсы (файлопомойки, трекеры, игровые, etc) от прова появляться стали только в связи с конкуренцией, провы расширялись и стали пересекаться то территории. До этого внутренние ресурсы поднимали сами юзверы.

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