Вопрос или проблема
У меня проблемы с подключением к моему домашнему VPN через ноутбук, который подключен к мобильной точке доступа.
Журнал клиента OpenVPN выглядит следующим образом:
trevor@xps:~$ sudo openvpn --config ~/dev/net/vpn/vpn.sears.network.ovpn
[sudo] пароль для trevor:
Ср Авг 22 11:53:55 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] собран 18 июля 2017
Ср Авг 22 11:53:55 2018 версии библиотеки: OpenSSL 1.0.2l 25 мая 2017, LZO 2.08
Ср Авг 22 11:53:55 2018 ПРЕДУПРЕЖДЕНИЕ: вы используете user/group/chroot/setcon без persist-tun -- это может привести к сбоям при перезапуске
Ср Авг 22 11:53:55 2018 ПРЕДУПРЕЖДЕНИЕ: вы используете user/group/chroot/setcon без persist-key -- это может привести к сбоям при перезапуске
Ср Авг 22 11:53:55 2018 TCP/UDP: Сохраняю недавно использованный удаленный адрес: [AF_INET]97.83.39.84:1194
Ср Авг 22 11:53:55 2018 UDP ссылка локальная (привязана): [AF_INET][undef]:1194
Ср Авг 22 11:53:55 2018 UDP ссылка удаленная: [AF_INET]97.83.39.84:1194
Ср Авг 22 11:53:55 2018 ЗАБАЙТ: Снижение UID/GID будет задержано из-за --client, --pull или --up-delay
Ср Авг 22 11:54:55 2018 Ошибка TLS: установка ключа TLS не произошла в течение 60 секунд (проверьте ваше сетевое подключение)
Ср Авг 22 11:54:55 2018 Ошибка TLS: рукопожатие TLS не удалось
Ср Авг 22 11:54:55 2018 SIGUSR1[soft,tls-error] получен, процесс перезапускается
^CСр Авг 22 11:54:59 2018 SIGINT[hard,init_instance] получен, процесс завершается
Информация о сервере и клиенте:
Информация о сервере:
ОС: CentOS 7
версия OpenVPN: 2.4.6
Информация о клиенте:
ОС: Debian 9
версия OpenVPN: 2.4.0
Из локальной сети сервера:
trevor@xps:~$ sudo nmap -sU -p 1194 192.168.2.104
[sudo] пароль для trevor:
Запуск Nmap 7.40 ( https://nmap.org ) 2018-08-22 16:23 EDT
Отчет сканирования Nmap для 192.168.2.104
Хост доступен (0.0049с задержка).
ПОРТ СОСТОЯНИЕ СЕРВИС
1194/udp отфильтрован openvpn
MAC-адрес: 1E:FB:74:5F:D6:C5 (Неизвестный)
Сканирование завершено: 1 IP-адрес (1 хост доступен) отсканировано за 0.66 секунды
По интернету/через точку доступа:
trevor@xps:~$ sudo nmap -sU -p 1194 vpn.sears.network
[sudo] пароль для trevor:
Запуск Nmap 7.40 ( https://nmap.org ) 2018-08-22 16:27 EDT
Отчет сканирования Nmap для vpn.sears.network (97.83.39.84)
Хост доступен (0.088с задержка).
rDNS запись для 97.83.39.84: 97-83-39-84.dhcp.trcy.mi.charter.com
ПОРТ СОСТОЯНИЕ СЕРВИС
1194/udp отфильтрован openvpn
Сканирование завершено: 1 IP-адрес (1 хост доступен) отсканировано за 0.83 секунды
На сервере:
[root@vpn ~]# netstat -uapn | grep openvpn
udp 0 0 192.168.2.104:1194 0.0.0.0:* 14096/openvpn
И у меня настроено правило переадресации на роутере:
Внешний 97.83.39.84:1194 --> Внутренний 192.168.2.104:1194
Мой файл конфигурации сервера можно найти здесь.
Мой файл конфигурации клиента можно найти здесь.
На данный момент я не смог подключиться к VPN, как вы видите в журнале выше. Кто-нибудь знает, что может происходить?
Вам не хватает строки в файле клиента:
cipher AES-256-CBC
Я думаю, что это единственная ваша проблема, остальная конфигурация сервера и клиента выглядит нормально, согласно документации. Мои конфигурации несколько отличаются, поэтому я не могу напрямую сравнить…
Что касается вашего теста порта, к сожалению, nmap не даст вам полезной информации. Он отправит пустой UDP-пакет на этот порт в надежде, что работающий сервис ответит; в случае OpenVPN этого не произойдет. Что касается nmap, порт может быть открыт или бесшумно сбрасывать пакеты. Все, что мы знаем, это то, что вы не отклоняете (т.е. с помощью iptables) подключения, поскольку нет ICMP-сообщения о недоступности. Так как UDP не имеет состояния, нет открытия TCP-соединения независимо от работающего сервиса, поэтому он просто использует пакет “попробуй и жди”. Nmap осведомлен о протоколах, так что, например, если вы сканируете порт 53, он фактически отправляет запрос статуса DNS-сервера (0x1000), на который он должен получить ответ, но нет эквивалентного запроса OpenVPN “вы на связи”, по очевидным причинам.
Перед тем, как тестировать через интернет, измените конфигурацию клиента на
remote 192.168.2.104 1194 udp
чтобы проверить, сможете ли вы подключиться локально, просто на всякий случай.
Если у вас все еще есть проблемы, то стоит также проверить, что вы разумно подошли к генерации сертификатов.
Надеюсь, это поможет!
Ответ или решение
Ошибка "TLS key negotiation failed to occur within 60 seconds" в OpenVPN обычно указывает на проблемы с сетью или конфигурацией, которые мешают успешному обмену ключами шифрования между клиентом и сервером. Рассмотрим основные причины и способы их устранения, принимая во внимание предоставленную информацию.
1. Проверка подключения к сети
Первым шагом является проверка сетевого соединения между клиентом и сервером. Для этого вы можете использовать команды ping или traceroute, чтобы убедиться, что пакет данных достигает сервера OpenVPN. Проверьте, может ли клиент (в данном случае ваш ноутбук) достучаться до публичного IP-адреса сервера (97.83.39.84).
ping 97.83.39.84Если пакеты не проходят, возможно, существуют проблемы с маршрутизацией или блокировкой на стороне интернет-провайдера.
2. Проверка конфигурации сервера и клиента
Обратите внимание на правильность настроек конфигурации. Из ваших логов видно, что вы используете разные версии OpenVPN: на сервере 2.4.6, на клиенте 2.4.0. Хотя это может не вызывать проблемы, по возможности лучше использовать одинаковые версии.
Если вы не указали шифрование в конфигурации клиента, добавьте следующую строку в ваш клиентский конфигурационный файл:
cipher AES-256-CBCЭто поможет гарантировать, что клиент и сервер используют одинаковый метод шифрования.
3. Сетевые ограничения и порт 1194
Согласно выводу nmap, порт 1194 на сервере отмечен как "filtered", что говорит о том, что возможно существует брандмауэр, который блокирует доступ к этому порту. Убедитесь, что:
- На сервере открыт порт 1194 для входящих UDP-пакетов. Используйте следующий набор команд для настройки iptables (если вы его используете):
iptables -A INPUT -p udp --dport 1194 -j ACCEPT- Также проверьте настройки вашего роутера, чтобы убедиться, что NAT (перенаправление портов) правильно настроен, и не возникает дополнительных блокировок.
4. Локальные проверки
Попробуйте подключиться к серверу, используя его локальный IP-адрес (192.168.2.104), чтобы проверить, работает ли соединение внутри сети:
remote 192.168.2.104 1194 udpЕсли подключение успешно, это укажет на проблемы с маршрутизацией через интернет, а не с конфигурацией OpenVPN.
5. Пересмотр сертификатов и аутентификации
Процесс аутентификации и обмена сертификатами также влияет на успешность подключения. Убедитесь, что на клиенте и сервере используются корректные сертификаты и ключи. Если необходимо, пересоздайте их, удостоверившись, что генерация сертификатов выполнена правильно.
Выводы
Ошибка связи в OpenVPN чаще всего возникает из-за проблем сетевого уровня или неправильной конфигурации. Убедившись в корректности настройки сети и конфигурационных файлов, вы сможете устранить большинство распространенных проблем. Если по окончании вышеописанных шагов проблема не будет решена, рекомендуем обратиться к логам сервера OpenVPN для получения дополнительной информации об ошибках.