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

Question

У меня проблемы с подключением к домашней сети VPN через ноутбук, подключенный к мобильной точке доступа.

Журнал OpenVPN клиента выглядит следующим образом:

trevor@xps:~$ sudo openvpn --config ~/dev/net/vpn/vpn.sears.network.ovpn 
[sudo] password for trevor: 
Wed Aug 22 11:53:55 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Wed Aug 22 11:53:55 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Wed Aug 22 11:53:55 2018 WARNING: you are using user/group/chroot/setcon without persist-tun -- this may cause restarts to fail
Wed Aug 22 11:53:55 2018 WARNING: you are using user/group/chroot/setcon without persist-key -- this may cause restarts to fail
Wed Aug 22 11:53:55 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]97.83.39.84:1194
Wed Aug 22 11:53:55 2018 UDP link local (bound): [AF_INET][undef]:1194
Wed Aug 22 11:53:55 2018 UDP link remote: [AF_INET]97.83.39.84:1194
Wed Aug 22 11:53:55 2018 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Wed Aug 22 11:54:55 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Aug 22 11:54:55 2018 TLS Error: TLS handshake failed
Wed Aug 22 11:54:55 2018 SIGUSR1[soft,tls-error] received, process restarting
^CWed Aug 22 11:54:59 2018 SIGINT[hard,init_instance] received, process exiting

Информация о сервере и клиенте:

Server Info:
    OS: CentOS 7
    OpenVPN version: 2.4.6

Client Info:
    OS: Debian 9
    OpenVPN version: 2.4.0

Из локальной сети сервера:

trevor@xps:~$ sudo nmap -sU -p 1194 192.168.2.104
[sudo] password for trevor: 

Starting Nmap 7.40 ( https://nmap.org ) at 2018-08-22 16:23 EDT
Nmap scan report for 192.168.2.104
Host is up (0.0049s latency).
PORT     STATE    SERVICE
1194/udp filtered openvpn
MAC Address: 1E:FB:74:5F:D6:C5 (Unknown)

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

Через Интернет / через точку доступа:

trevor@xps:~$ sudo nmap -sU -p 1194 vpn.sears.network
[sudo] password for trevor:

Starting Nmap 7.40 ( https://nmap.org ) at 2018-08-22 16:27 EDT
Nmap scan report for vpn.sears.network (97.83.39.84)
Host is up (0.088s latency).
rDNS record for 97.83.39.84: 97-83-39-84.dhcp.trcy.mi.charter.com
PORT     STATE    SERVICE
1194/udp filtered openvpn

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

На сервере:

[root@vpn ~]# netstat -uapn | grep openvpn
udp    0    0 192.168.2.104:1194    0.0.0.0:*                  14096/openvpn

И у меня есть настройка правила пересылки на маршрутизаторе:

External 97.83.39.84:1194 --> Internal 192.168.2.104:1194

Файл конфигурации моего сервера можно найти здесь.

Мой файл конфигурации клиента можно найти здесь.

И как он есть, я вообще не смог подключиться к vpn, как вы видите в журнале выше. Кто-нибудь знает, что здесь может происходить?

Answer 1

Вам не хватает строки в файле клиента:

cipher AES-256-CBC

Я думаю, что это единственная проблема, которая у вас есть, остальная часть конфигурации сервера и клиента выглядит хорошо, согласно документации. Мои конфиги несколько отличаются, поэтому я не могу сравнивать напрямую ...

Что касается теста вашего порта, то, к сожалению, nmap не даст вам никакой полезной информации. Он отправит пустой UDP-пакет на этот порт в надежде, что работающая служба ответит; в случае OpenVPN это не так. Что касается nmap, то порт может быть открыт или молча отбрасывать пакеты. Все, что мы знаем, это то, что вы не отклоняете (то есть с iptables) соединения, потому что нет сообщения ICMP о недоступности. Поскольку UDP не имеет состояния, нет открытия TCP-соединения независимо от того, какая служба запущена, поэтому он просто использует пакет Hit-and-Hope. Nmap поддерживает протокол, поэтому, например, если вы сканируете порт 53, он фактически отправляет запрос запроса состояния DNS-сервера (0x1000), на который он должен получить ответ, но по очевидным причинам не существует эквивалентного запроса "Вы живы".

Перед тестированием через Интернет измените конфигурацию клиента на

remote 192.168.2.104 1194 udp

чтобы увидеть, если вы можете подключиться локально, просто чтобы быть уверенным.

Если у вас все еще есть проблемы, то стоит проверить, что вы тоже пошли на создание сертификата.

НТН!