Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Системное администрирование и сети

openVPN TLS Ошибка: Сбой рукопожатия TLS, но ранее работало успешно

На чтение 8 мин Опубликовано

Вопрос или проблема

Я настроил openvpn на моем raspberrypi, следуя этому руководству: https://juncotic.com/openvpn-easyrsa-3-montando-la-vpn/, и все работало прекрасно в течение нескольких недель. Вдруг пару дней назад vpn перестал работать и выдает ошибку TLS. Я проверил, что переадресация портов все еще активна — так и было, я также убедился, что все обновлено как на сервере, так и на моем устройстве — так и было, также проверил, что openvpn работает корректно, ничего в логах не указывает на то, что он не должен работать, также попытался изменить порт vpn на более высокий, но это не сработало. Я не знаю, на что еще обратить внимание. Я приложу некоторую информацию, если кому-то нужно что-то еще, дайте знать.

Это мои конфигурационные файлы:

server.conf:

port 1194
proto udp
server 192.168.10.0 255.255.255.0 
client-to-client
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cloudAtlas.crt
dh /etc/openvpn/keys/dh.pem
key /etc/openvpn/keys/cloudAtlas.key
tls-auth /etc/openvpn/keys/ta.key 0
crl-verify /etc/openvpn/keys/crl.pem
comp-lzo adaptive
dev tun
ifconfig-pool-persist server-ipp.txt 0
keepalive 10 120
cipher AES-256-CBC
auth SHA512
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
log /var/log/openvpn/server.log
verb 3

client2.conf:

client
dev tun
proto udp
port 1194
remote 21e800.duckdns.org 1194
remote-cert-tls server
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 3
cipher AES-256-CBC
auth SHA512
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
ca /etc/openvpn/keys/ca.crt
key /etc/openvpn/keys/cliente1.key
cert /etc/openvpn/keys/cliente1.crt
key-direction 1
tls-auth /etc/openvpn/keys/ta.key 1

Вывод логов openvpn при запуске:

Thu Aug 19 22:10:30 2021 OpenVPN 2.4.7 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 28 2021
Thu Aug 19 22:10:30 2021 library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10
Thu Aug 19 22:10:30 2021 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Thu Aug 19 22:10:30 2021 Note: cannot open server-ipp.txt for READ
Thu Aug 19 22:10:30 2021 Diffie-Hellman initialized with 2048 bit key
Thu Aug 19 22:10:30 2021 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Aug 19 22:10:30 2021 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Aug 19 22:10:30 2021 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=eth0 HWADDR=e4:5f:01:38:49:2b
Thu Aug 19 22:10:30 2021 TUN/TAP device tun0 opened
Thu Aug 19 22:10:30 2021 TUN/TAP TX queue length set to 100
Thu Aug 19 22:10:30 2021 /sbin/ip link set dev tun0 up mtu 1500
Thu Aug 19 22:10:30 2021 /sbin/ip addr add dev tun0 local 192.168.10.1 peer 192.168.10.2
Thu Aug 19 22:10:30 2021 /sbin/ip route add 192.168.10.0/24 via 192.168.10.2
Thu Aug 19 22:10:30 2021 Could not determine IPv4/IPv6 protocol. Using AF_INET
Thu Aug 19 22:10:30 2021 Socket Buffers: R=[180224->180224] S=[180224->180224]
Thu Aug 19 22:10:30 2021 UDPv4 link local (bound): [AF_INET][undef]:1194
Thu Aug 19 22:10:30 2021 UDPv4 link remote: [AF_UNSPEC]
Thu Aug 19 22:10:30 2021 MULTI: multi_init called, r=256 v=256
Thu Aug 19 22:10:30 2021 IFCONFIG POOL: base=192.168.10.4 size=62, ipv6=0
Thu Aug 19 22:10:30 2021 IFCONFIG POOL LIST
Thu Aug 19 22:10:30 2021 Initialization Sequence Completed

Сообщение клиента при попытке подключения:

Thu Aug 19 22:12:03 2021 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021
Thu Aug 19 22:12:03 2021 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Thu Aug 19 22:12:03 2021 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Aug 19 22:12:03 2021 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Aug 19 22:12:03 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:12:03 2021 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Aug 19 22:12:03 2021 UDP link local: (not bound)
Thu Aug 19 22:12:03 2021 UDP link remote: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:13:03 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug 19 22:13:03 2021 TLS Error: TLS handshake failed
Thu Aug 19 22:13:03 2021 SIGUSR1[soft,tls-error] received, process restarting
Thu Aug 19 22:13:03 2021 Restart pause, 5 second(s)
Thu Aug 19 22:13:08 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:13:08 2021 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Aug 19 22:13:08 2021 UDP link local: (not bound)
Thu Aug 19 22:13:08 2021 UDP link remote: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:14:08 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug 19 22:14:08 2021 TLS Error: TLS handshake failed
Thu Aug 19 22:14:08 2021 SIGUSR1[soft,tls-error] received, process restarting
Thu Aug 19 22:14:08 2021 Restart pause, 5 second(s)
Thu Aug 19 22:14:13 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:14:13 2021 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Aug 19 22:14:13 2021 UDP link local: (not bound)
Thu Aug 19 22:14:13 2021 UDP link remote: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:15:13 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug 19 22:15:13 2021 TLS Error: TLS handshake failed
Thu Aug 19 22:15:13 2021 SIGUSR1[soft,tls-error] received, process restarting
Thu Aug 19 22:15:13 2021 Restart pause, 5 second(s)
Thu Aug 19 22:15:18 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]83.51.211.151:1194

Моя конфигурация переадресации портов (роутер):

enter image description here

Ответы:

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

pah@xiaomi:~$ nmap -Pn -p 1194 21e800.duckdns.org
Starting Nmap 7.80 ( https://nmap.org ) at 2021-08-19 22:58 CEST
Nmap scan report for 21e800.duckdns.org (83.51.211.151)
Host is up.
rDNS record for 83.51.211.151: 151.red-83-51-211.dynamicip.rima-tde.net

PORT     STATE    SERVICE
1194/tcp filtered openvpn

Nmap done: 1 IP address (1 host up) scanned in 2.34 seconds

А сертификаты действительны до 2024 года. На случай, если я что-то упустил, я переделал все сертификаты, и все равно не работает.

Также я попытался проверить, получаю ли я пакеты с помощью:

sudo tcpdump -i any -c5 -nn port 1194

Ничего не появилось, поэтому я подозреваю, что проблема связана с сетью, но мои знания в этом области … скудные, так что я не знаю, как дальше продебажить это или где еще может быть проблема, кроме как в переадресации портов, которая, как я думаю, работает из-за ответа на пинг (?).

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

Ответ:
Я НАШЕЛ ПРОБЛЕМУ! Это был DNS-сервис, не знаю почему, но он корректно не обновлял мой IP, и так как он динамический, все просто перестало работать. Мне следовало проверить это одной из первых вещей, позор мне.

Проверьте, можете ли вы действительно установить соединение с интернета на этот IP и порт:

  1. возможно, у вас сервер получает внутренний IP через DHCP, и его внутренний IP изменился.

  2. возможно, ваш внешний IP изменился, проверьте еще раз.

Убедитесь, что сертификаты вашего сервера и клиента не истекли, это могло бы быть случаем, как вы сказали, что он работал хорошо для некоторое время.

Ответ или решение

Когда дело доходит до решения проблемы с ошибкой OpenVPN TLS: TLS handshake failed, особенно после того, как VPN работал исправно в течение некоторого времени, важно внимательно проверить несколько ключевых аспектов настройки и среды. Рассмотрим эту ситуацию в деталях.

Настройка OpenVPN и проверка SSL:

  1. DNS и Интернет-адресация:

    • Как вы сами отметили, проблема могла заключаться в сервисе DNS. Поскольку ваш публичный IP-адрес динамический, смена адреса могла привести к потере соединения. Убедитесь, что ваш DNS-сервис (например, DuckDNS) правильно обновляет ваш текущий IP-адрес.

  2. Проверка сетевых подключений:

    • Используйте команды для диагностики, например, nmap, чтобы проверить, что порт 1194 открыт и доступен извне. Результат "filtered" обычно указывает на то, что порт не доступен для внешних соединений, что может быть связано с настройками маршрутизатора или фаервола.

  3. Настройки серверных и клиентских конфигураций:

    • Проверьте, чтобы все пути к файлам сертификатов и ключей в конфигурационных файлах были корректными и файлы существовали в указанных директориях.
    • Убедитесь, что конфигурация server.conf и client2.conf соответствует требованиям безопасности и актуальности версий SSL/TLS. Возможно, стоит обновить OpenVPN и OpenSSL до последних версий для исправления известных уязвимостей, хотя в вашем случае они и так достаточно свежие.

  4. Истечения сертификатов и управление ключами:

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

Последующие шаги:

  • Физическая сеть и портовая адресация:

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

  • Журналы OpenVPN:

    • Осмотр журналов помогает в диагностике: если серверные и клиентские журналы содержат больше детальной информации при увеличении уровня verb (например, до 4 или выше), это может помочь понять, на каком этапе происходит сбой в процессе рукопожатия.

  • Дополнительные инструменты диагностики:

    • Используйте tcpdump для проверки, приходят ли пакеты на порт 1194. Это поможет подтвердить, действительно ли проблема связана с сетью.
    • Проверьте работу маршрутизатора и используемых сетевых интерфейсов.

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

openvpn raspbian
Оцените материал
Добавить комментарий

Капча загружается...

© 2025 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности