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

Я настраиваю сервер 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 Есть идеи?

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

Пн Мар 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 в качестве обходного пути, и на этом вопрос окончен.

Это одна из наиболее распространенных ошибок при настройке 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 секунд (проверьте подключение к сети)

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

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

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

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

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

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

• Убедитесь, что ваш VPN-сервер прослушивает правильный интерфейс.

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

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

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

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

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

Ни одно из упомянутых ранее решений не сработало. В моем случае, хотя журнал клиента показал ту же ошибку 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

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

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

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

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

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

Я тоже сталкивался с 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 в локальной сети запускаются в неправильной последовательности.

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

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