Проблема 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 клієнта. Тому я розумію, що клієнт, принаймні, може прийти на сервер, тому проблем з маршрутизацією та брандмауером немає.

Я дотримувався опису, наданого тут Простий посібник для Windows Будь-які ідеї?

Що цікаво, як змінюється номер порту середнього потоку:

Пн 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 працював.

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

Ref: помилка TLS: Не вдалося узгодити ключ TLS протягом 60 секунд (перевірте підключення до мережі)

Я отримував ключові тайм-аути на переговори TLS, як це. Але в моєму випадку я зрозумів, що віддалене посилання - це локальна IP-адреса.

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

Я думаю, що основні заходи від цього:

• Отримати ключовий тайм-аут на переговори не обов'язково означає, що вам навіть вдалося підключитися до чого-небудь.

  Тож на цьому етапі все ж варто перевірити, чи ви насправді підключаєтесь до потрібного місця, і немає правил брандмауера, що блокують з'єднання тощо. Особливо, якщо ваша конфігурація була створена автоматично.

  Зауважте, що отримання підказки для входу не означає, що ви підключені , оскільки OpenVPN запитує ваші облікові дані перед спробою підключення.

• Переконайтеся, що ваш VPN-сервер прослуховується в потрібному інтерфейсі.

  (Звичайно, це одна з ряду неправильних налаштувань на стороні сервера, які можуть статися, такі як правила брандмауера, встановлення неправильного номера порту, змішування TCP та UDP тощо).

У мене була така ж помилка, і жодна порада не допомогла, все здавалося нормально: IP-адреси, порти, брандмауер, все. Зникли з розуму протягом 2 годин.

Рішенням було змінити протокол з UDP на TCP в налаштуваннях клієнта (мабуть, я давно відключив UDP).

Сподіваюсь, це комусь допоможе :)

ЛЕ: це вирішило мою проблему, але це не найкращий підхід, як зазначено нижче в коментарях. Ви повинні використовувати UDP замість TCP. Це допомогло мені, оскільки у мене були різні налаштування між клієнтом та конфігурацією сервера.

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

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

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 [м'який, tls-помилка] отримано, процес перезавантаження
...

Помилка може привести вас до помилкового сенсу, що ви спілкуєтесь із сервером 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

Я зіткнувся з цією помилкою в 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 post, у мережевому зв’язку повинно бути щось не так. Однак ні брандмауер, ні 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 в локальній мережі починаються в неправильній послідовності.

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

Очевидно, що потрібно спробувати - оновити клієнт OpenVPN або змінити серверну сторону, щоб прийняти TLS 1.0.