Назад | Перейти на главную страницу

Проблема 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 не имеет правильного адреса сервера в файле конфигурации. Директива remote в файле конфигурации клиента должна указывать либо на сам сервер, либо на общедоступный IP-адрес сетевого шлюза сервера.
  • Другая возможная причина заключается в том, что брандмауэр Windows блокирует доступ для двоичного файла openvpn.exe. Возможно, вам потребуется внести его в белый список (добавить в список «Исключения»), чтобы OpenVPN работал.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Windows version 6.2 (Windows 8 or greater) 64bit
library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:12345
UDP link local (bound): [AF_INET][undef]:0
Удаленный канал UDP: [AF_INET] 127.0.0.1:12345
Ошибка TLS: согласование ключа TLS не удалось выполнить в течение 60 секунд (проверьте подключение к сети)
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, process restarting
...

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

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

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

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

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

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

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

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

Очевидно, что стоит попробовать обновить клиент OpenVPN или изменить серверную часть, чтобы она принимала TLS 1.0.

Вы должны создать сертификат SSL / TLS на OMV, а затем включить безопасное соединение SSL / TLS и добавить созданный сертификат. Так просто!

На вашем OVPN-сервере больше двух сетевых карт?

В UDP исходный IP-адрес не проверяется при ответе. OVPN-Server будет использовать конфигурацию по умолчанию для отправки данных UDP, поэтому нам нужно указать NetCard в server.conf.

local the-IP-in-client.ovpn