Всем привет!
У меня есть VPN провайдер, премиум аккаунт. В настройках аккаунта я скачиваю файл настроек ***.ovpn. Кидаю его по пути C:\Program Files\OpenVPN\config и подключаюсь через openvpn.
А теперь не подключается. Зависает вот на этой строчке:
Fri Nov 21 09:17:38 2014 UDPv4 link local: [undef]
Fri Nov 21 09:16:36 2014 UDPv4 link remote: [AF_INET]***IP***:443
Fri Nov 21 09:16:36 2014 MANAGEMENT: >STATE:1416550596,WAIT
А затем ошибка:
Thu Nov 20 16:40:37 2014 us=227044 MANAGEMENT: >STATE:1416490837,WAIT,,,
Thu Nov 20 16:41:37 2014 us=403575 [UNDEF] Inactivity timeout (--ping-exit), exiting
Thu Nov 20 16:41:37 2014 us=403575 SIGTERM received, sending exit notification to peer
Thu Nov 20 16:41:37 2014 us=403575 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Nov 20 16:41:37 2014 us=403575 TLS Error: TLS handshake failed
Thu Nov 20 16:41:37 2014 us=403575 TCP/UDP: Closing socket
Thu Nov 20 16:41:37 2014 us=403575 SIGUSR1[soft,tls-error] received, process restarting
Thu Nov 20 16:41:37 2014 us=403575 MANAGEMENT: >STATE:1416490897,RECONNECTING,tls-error,,
И это не со всеми ip ошибка. С некоторыми нормально подключается.
Но проблема не на стороне моего VPN поставщика, как мне кажется.
Даже если полностю вырубить интернет на пк и попытаться через openvpn подключиться, то с работающим ip будет такая запись:
Fri Nov 21 09:22:18 2014 us=418789 MANAGEMENT: >STATE:1416550938,RESOLVE,,,
Fri Nov 21 09:22:18 2014 us=418789 RESOLVE: Cannot resolve host address: ***ip***: Запрошенное имя верно, но данные запрошенного типа не найдены.
А с неработающим ip такая же ошибка:
Fri Nov 21 09:23:48 2014 us=552944 MANAGEMENT: >STATE:1416551028,WAIT,,
так же думает на этом месте. И ошибка:
Fri Nov 21 09:24:49 2014 us=225415 [UNDEF] Inactivity timeout (--ping-exit), exiting
Fri Nov 21 09:24:49 2014 us=225415 SIGTERM received, sending exit notification to peer
Fri Nov 21 09:24:49 2014 us=225415 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Nov 21 09:24:49 2014 us=225415 TLS Error: TLS handshake failed
Fri Nov 21 09:24:49 2014 us=225415 TCP/UDP: Closing socket
Fri Nov 21 09:24:49 2014 us=226415 SIGUSR1[soft,tls-error] received, process restarting
Fri Nov 21 09:24:49 2014 us=226415 MANAGEMENT: >STATE:1416551089,RECONNECTING,tls-error,,
Нет, связь отличная.
Так же по UDP подключаtтся к другим серверам. С тем же конфигом, только IP сменить.
И как я уже писал, даже при полностью отключенном интернете на пк та же самая ошибка у некоторых ip.
У рабочих ip - RESOLVE: Cannot resolve host address: ***ip***: Запрошенное имя верно, но данные запрошенного типа не найдены
У не рабочих ip - us=552944 MANAGEMENT: >STATE:1416551028,WAIT,,
Toy66: Так проблема может быть не у вас, а у провайдера (у того где стоит сервер OpenVPN)
Может быть плохая связь, или файрвол блокирует или еще что...
Попробуйте TCP, если будет работать стабильно - значит что-то у него со связью. Сам не так давно с этой бедой воевал. Причем долго... И выяснилось что проблема даже не у поставщика интернет, а у того кто поставщику интернет поставляет. Они там что-то мудрили с марщрутами а у меня постоянно связь рвалась.
Решилось долгими скандалами и кучей писем
Toy66: Значит на сервере не настроен TCP простокол. Тогда как вариант только проверять весь маршрут до сервера.
Есть такая утилита - mtr. Она идиально подходит для подобных проверок. Вы сразу увидите где потери или задержки.
Toy66: На сервере OpenVPN - точно настроен TCP?? Обычно по умолчанию идет только UDP, а для TCP нужно поднимать дополнительно еще один сервер. По крайней мере так под *NIX
Toy66: Хм... такое вижу впервые...
Но, если думать что там обычный OpenVPN спрятан, то... Обычно после смены протокола - службу надо перезапускать. Иначе ничего не произойдет
Далее, нужно смотреть что на файрволе, возможно заблокирован TCP 1194, а открыт только UDP
Сергей: У меня UDP на 443, а TCP предлагают в настройка 80 порт.
В настройках еще можно выбрать L2TP и PPTP.
А что касается служб - у меня их две: моего поставщика впн (утилита с гуем(через нее все подключается)) и "OpenVPN service". Без разницы, запущены они или нет. OpenVPN все равно подключается (к работающим серверам).
Toy66: Так у вас не OpenVPN!! OpenVPN - работает на порту 1194 UDP или TCP
А вы сами только что сказали что подключаетесь по L2TP или PPTP - а это уже другие службы и отношения к OpenVPN не имеют никакого.
Toy66: Когда не сервер ставили TCP, вы меняли у клиента настройки тоже на TCP?
Это в конфиге клиента, потом, если не ошибаюсь нужно его перезапустить, чтоб он прочитал новые настройки
Toy66: Как я уже писал, TCP - может быть блокируется файрволом. Или служба не рестартует после смены протокола.
Так как вы все делаете через какую-т вебформу, то нужно или в ней искать настройки файрвола, или кнопку перезапуска службы. Тут вы сам себе режиссер. Я просто даю рекомендации
Для чего меняют на TCP
OpenVPN по умолчанию использует протокол UDP. работа на нем идет быстрее, так как нет проверок пакетов на контрольные суммы. Как результат, при нестабильной связи могут быть проблемы.
Если менять на TCP, то каждый пакет начинает проверяться и если проблемы со связью, то пакеты могут быть доставлены по нескольку раз. ТО есть если пакет поврежден, то конечная станция не принимает его и ждет повтора и так до бесконечности, пока пакет придет неповрежденным.
Как результат скорость передачи падает... иногда очень сильно, но зато соединение стабильно работает.
Собственно что делать вам.
Если перейти на TCP - не получается, то возвращайте все назад, ставьте утилиту MTR, и начинайте проверять весь маршрут.
Или.. Раз у вас сервером владеет кто-то, не вы, то я бы напряг их. Вы же клиент - можете требовать.
Скорее всего у них проблемы с сервером, в логах ясная ошибка:
Fri Nov 21 09:23:48 2014 us=552944 MANAGEMENT: >STATE:1416551028,WAIT,,
Fri Nov 21 09:24:49 2014 us=225415 [UNDEF] Inactivity timeout (--ping-exit), exiting
Т.е. клиент отправляет пакеты для подключения и не дожидается ответа в течение минуты.
А при смене на tcp - также выдало ошибку, что не смог подключиться.
Как уже правильно подметили - напишите в техподдержку:)
Я уже написал :)
Но вот к серверу по PPTP подключается. А с OpenVPN перестал...
Все равно мне не понятен вот этот момент:
если вырубить инет и подключаться к нерабочему серверу, то зависает на MANAGEMENT: >STATE:1416551028,WAIT,,
А если так же вырубить и нет и подключаться к рабочему серверу, то ошибка Cannot resolve host address: ***ip***: Запрошенное имя верно, но данные запрошенного типа не найдены.
Если инет выключен, то откуда он может знать проблемы на сервере или нет?
Так выдает же ошибку разрешения имени Cannot resolve host address
Видимо клиент при подключении пытается зарезолвить имя, но т.к. интернеты отключены - до днс-сервера достучаться он не может.
Сложно сказать, пока не видно конфига:)
Может быть имя неработающего успело закэшироваться нормально.
Может быть в конфиге неработающего стоит конкретный ойпи.
Toy66: "Но вот к серверу по PPTP подключается. А с OpenVPN перестал..." - можно я встряну?
PPTP отличается от OpenVPN. Причем сильно. Для поддержки туннеля он поднимает отдельную TCP сессию. Как результат связь работает стабильнее, но секъюрность хуже. Да и скорость передачи похуже будет.
Сергей: Вы имеете ввиду, что OpenVPN хуже PPTP?
Я где то читал, что PPTP настолько ненадежный, что от него сами майкрософт отказались.
Но у меня выбора нет, пока проблема не решена, остается только PPTP.
Сергей: Нет.
PPTP работает поверх GRE.
Отдельная tcp-сессия - это только control connection, который отвечает за управление сессиями. На стабильность туннеля оно влияет достаточно опосредовано.
Секьюрность от этого не хуже. Хуже она от херовой реализации аутентификации в ms-**ap и слабого шифрования.
brutal_lobster: проблема все же на моей стороне была, как я понял.
Сменил порт на 8080 и подключилось. Через 1194 так же не подключается. По большому счету не имеет значения какой порт использовать?
Средний