Проблема OpenVPN - согласование ключа TLS не удалось в течение 60 секунд

14

Я настраиваю сервер OpenVPN (версия 2.3.10) на сервере Windows 2012, но не могу заставить его работать.

Сервер находится за маршрутизатором, и я открыл порт 1194 и создал правило для перенаправления трафика с этого порта на сервер.

Вот журнал, который я вижу на сервере, когда пытаюсь подключиться с клиента:

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS handshake failed
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 SIGUSR1[soft,tls-error] received, client-instance restarting

Где XX.XX.XX.XX - это ip клиента. Из этого я понимаю, что клиент, по крайней мере, может прибыть на сервер, поэтому нет проблем с маршрутизацией или брандмауэром.

Я следовал описанию, приведенному здесь. Easy Windows Guide Есть идеи?

openvpn

— vmasanas
источник

1

Предполагая, что две лоты XX.XX.XX.XXпредставляют один и тот же адрес (пожалуйста, не запутывайте такие вещи ), меня интересует изменение номеров портов источника (57804, 55938). Это наводит меня на мысль о ненадежном NAT на пути, который чаще всего имеет место для UDP. Используете ли вы транспорт UDP или TCP, и если первое, можете ли вы попробовать последнее и посмотреть, исчезнет ли проблема?

— MadHatter

если я увижу это сообщение на консоли сервера, я предполагаю, что, по крайней мере, клиент может туда добраться, поэтому я предположил, что проблема не в NAT. Я здесь не прав?

— vmasanas

1

Не все NAT созданы равными. У некоторых есть записи таблицы состояний с очень коротким сроком службы, особенно для UDP, и OpenVPN не будет хорошо воспринимать изменения в исходном порте. Пожалуйста, ответьте на вопрос, который я задал, и, если необходимо, попробуйте предложенное мной изменение.

— MadHatter

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

— vmasanas

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

— MadHatter

21

Что интересно, как номер порта меняется в середине потока:

Пн Мар 21 11:11:47 2016 XX.XX.XX.XX: 57804 TLS: исходный пакет из [AF_INET] XX.XX.XX.XX: 57804, sid = fdf7a7ac 0264c7f3

Пн Мар 21 11:12:38 2016 XX.XX.XX.XX: 55938 TLS: начальный пакет из [AF_INET] XX.XX.XX.XX: 55938, sid = 1f242a3f e454a525

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

Такие устройства обычно делают это только с UDP, поэтому я посоветовал вам подтвердить, что вы используете UDP, и вместо этого попробовать TCP. Это вы сделали, и обнаружили, что это решает проблему. Следующим шагом является выявление некорректно работающего устройства NAT, удар по нему молотком и замена его на тот, который не делает кардинальную ошибку, предполагая, что все UDP-коммуникации эфемерны; но вы указали, что вы довольны переходом на TCP в качестве обходного пути, и на этом вопрос окончен.

— Безумный Шляпник
источник

2

+1 за ваш орлиный глаз!

— Diamond

@ Bangal почему, спасибо! Большая часть дьявола кроется в деталях, в этом деле.

— MadHatter

Да, я знаю, но я пропустил это и увидел это только после того, как вы указали. Был уверен, что это проблема с брандмауэром.

— Diamond

Ну, это так, поэтому вы были правы. И не мучайся, в следующий раз ты будешь выглядеть еще тяжелее!

— MadHatter

Есть ли польза от использования UDP вместо TCP? TCP работает для меня сейчас, если нет никаких недостатков, я в порядке с этим.

— vmasanas

3

Это одна из наиболее распространенных ошибок при настройке Openvpn, и для этого есть запись FAQ. Я собираюсь процитировать это здесь:

Ошибка TLS: согласование ключа TLS не удалось в течение 60 секунд (проверьте подключение к сети)

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

Это почти результат:

Брандмауэр периметра в сети сервера фильтрует входящие пакеты OpenVPN (по умолчанию OpenVPN использует порт UDP или TCP номер 1194).

Программный брандмауэр, работающий на компьютере сервера OpenVPN, сам фильтрует входящие соединения через порт 1194. Имейте в виду, что многие операционные системы блокируют входящие соединения по умолчанию, если не указано иное.

Шлюз NAT в сети сервера не имеет правила переадресации порта для TCP / UDP 1194 на внутренний адрес компьютера сервера OpenVPN.

Конфигурация клиента OpenVPN не имеет правильного адреса сервера в своем файле конфигурации. Удаленная директива в файле конфигурации клиента должна указывать либо на сам сервер, либо на общедоступный IP-адрес шлюза сети сервера.

Другой возможной причиной является то, что брандмауэр Windows блокирует доступ для двоичного файла openvpn.exe. Возможно, вам потребуется добавить его в белый список (добавить его в список «Исключения»), чтобы OpenVPN работал.

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

Ссылка: Ошибка TLS: согласование ключа TLS не удалось в течение 60 секунд (проверьте подключение к сети)

— ромб
источник

Я прошел через эти пункты, но не уверен, что что-то упустил: 1. на данный момент брандмауэры отключены как на клиенте, так и на сервере, 2. то же самое, 3. на маршрутизаторе есть правило пересылки на сервер, и я вижу трафик, появляющийся на консоли сервера, 4.client имеет правильный IP-адрес, 5. нет брандмауэра, который я могу сказать.

— vmasanas

Ну, честно говоря, я не могу думать ни о чем другом в данный момент. Чтобы быть уверенным, как конфигурация сети в Windows Server? Есть ли у него несколько шлюзов случайно? Это шлюз по умолчанию, указывающий на маршрутизатор? Если да, то остальное, что вы можете протестировать, это, как предложил MadHatter, протестировать с tcp.

— Diamond

Если кому-то захочется протянуть

— Ola

Еще одна вещь, на которую стоит обратить внимание, это высокая задержка между двумя хостами . Я просто тщательно обдумывал это, и по какой-то богом забытой причине я получал 6000 мс + пинг в одном направлении (клиент-сервер), а не наоборот. Это привело к тому, что ключевые переговоры заняли более 60-х годов. Перезагрузка маршрутизатора, предоставленного моим провайдером, решила проблему. Вероятно, редкий крайний случай, но, надеюсь, это поможет кому-то.

— s.co.tt

3

Я получал тайм-ауты согласования ключей TLS, как это. Но в моем случае я понял, что удаленная ссылка - это локальный IP-адрес.

VPN на нашем брандмауэре pfSense по ошибке была подключена к интерфейсу LAN вместо интерфейса WAN, и поэтому экспортированная конфигурация была настроена на попытку подключения к IP-адресу локальной сети брандмауэра, который никогда не будет работать с клиентом, который включен другая локальная сеть.

Я думаю, что основные выводы из этого:

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

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

Обратите внимание, что получение приглашения на вход в систему не означает, что вы подключены , поскольку OpenVPN запрашивает ваши учетные данные перед попыткой подключения.
Убедитесь, что ваш VPN-сервер прослушивает правильный интерфейс.

(Конечно, это может произойти из-за неправильной конфигурации на стороне сервера, такой как правила брандмауэра, неверный номер порта, смешивание TCP и UDP и т. Д.)

— mwfearnley
источник

1

У меня была та же ошибка, и никакой совет не помог, все было хорошо: IP-адреса, порты, брандмауэр, все. Сошел с ума в течение 2 часов.

Решением было изменить протокол с UDP на TCP в конфигурации клиента (очевидно, я давно отключил UDP специально).

Надеюсь, это поможет кому-то :)

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

— Бош
источник

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

— EEAA

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

— Bosch

2

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

— EEAA

Спасибо за подсказку и за объяснения. Я переключился на UDP и следил за соединениями. Кроме того, мне нужно прочитать больше о стеках ...

— bosch

Полезная страница, объясняющая, почему TCP через TCP - плохая идея: sites.inka.de/bigred/devel/tcp-tcp.html

— mwfearnley

1

Ни одно из упомянутых ранее решений не сработало. В моем случае, хотя журнал клиента показал ту же ошибку TLS Error: TLS key negotiation failed to occur within 60 seconds, журналы сервера показали VERIFY ERROR: depth=0, error=CRL has expired.

На сервере следующие шаги решили проблему с соединением:

# cd <easyrsa folder>
# ./easyrsa gen-crl
above command generates new crl.pem file (in my case in pki folder)
using chown/chmod make sure 'pki/crl.pem' is readable by openvpn server (for example: chmod 640 pki/crl.pem)
# systemctl restart openvpn

— mpprdev
источник

0

Обратите внимание, что вы можете получить ошибку согласования ключа TLS, без успешного подключения к серверу OpenVPN - или даже с успешным подключением к чему-либо вообще!

Я изменил конфигурацию VPN для подключения к локальному узлу на порте, который ничего не слушал:

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] построено 26 апреля 2018 г.
Windows версии 6.2 (Windows 8 или выше) 64 бит
версии библиотеки: OpenSSL 1.1.0h 27 марта 2018 года, LZO 2.10
TCP / UDP: сохранение недавно использованного удаленного адреса: [AF_INET] 127.0.0.1:12345
Локальная ссылка UDP (связанная): [AF_INET] [undef]: 0
Удаленный канал UDP: [AF_INET] 127.0.0.1:12345 
Ошибка TLS: согласование ключа TLS не удалось в течение 60 секунд (проверьте подключение к сети)
Ошибка TLS: сбой квитирования TLS
SIGUSR1 [soft, tls-error] получен, перезапуск процесса
...

Ошибка может ввести вас в заблуждение, что вы разговариваете с сервером VPN.

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

— mwfearnley
источник

0

Я столкнулся с этой ошибкой в AWS, где OpenVPN был установлен на сервере с публичным IP-адресом, но в экземпляре, который находился в частной подсети, то есть в подсети, у которой не было маршрута к интернет-шлюзу.

После того, как я развернул OpenVPN на сервере в публичной подсети, все заработало хорошо :)

Об общих / частных подсетях в AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html.

— Золтан
источник

0

Я тоже сталкивался с TLS key negotiation failed to occur within 60 secondsпроблемой.

Из официального предложения, как и в сообщении Diamant, должно быть что-то не так в сетевом соединении. Однако ни брандмауэр, ни NAT не вызывают проблемы.

В моем случае я сначала проверил соединение с помощью nc -uvz xxx.xxx.xxx.xxx 1194. Ссылка в порядке.

Кроме того, несколько других клиентов VPN в той же локальной сети работают нормально.

Откуда-то я заметил, что у соединения udp есть некоторые проблемы в ответе или переадресации порта.

Поэтому я прекращаю запуск клиентов vpn с самого большого ip до зависшего клиента, например, с «10.8.0.100» до «10.8.0.50».

Затем запустите остановленные клиенты vpn в обратном порядке.

Взрыв! Все клиенты vpn работают propoerly.

В заключение, существует вероятность того, TLS key negotiation failed to occur within 60 secondsчто несколько клиентов vpn в локальной сети запускаются в неправильной последовательности.

— samson.wang
источник

Непонятно, как это связано с проблемой в первоначальном вопросе.

— Опека - Восстановите Монику

0

Одна из возможных причин - если серверу требуется версия TLS новее, чем TLS, поддерживаемый клиентом. т.е. 1,2 против 1,0.

Очевидная вещь, которую стоит попробовать - обновить клиент OpenVPN или модифицировать серверную часть для принятия TLS 1.0.

— ОЗК
источник