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

Почему может произойти сбой рукопожатия TLS?

Мой клиент OpenVPN (Windows 10) находится в корпоративной локальной сети и подключается к серверу в Интернете (Ubuntu). Раньше установка работала, но остановилась некоторое время назад (см. Ниже небольшие изменения инфраструктуры, конфигурация сервера или клиента не изменилась).

В журналах ниже

адрес сервера OpenVPN: SERVERIP
при выходе из корпоративной локальной сети адрес источника CORPORATEIP (это SNAT с внутреннего IP клиента)

При попытке подключения с клиента я получаю следующий журнал:

Sun May 29 10:55:07 2016 OpenVPN 2.3.11 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on May 10 2016
Sun May 29 10:55:07 2016 Windows version 6.2 (Windows 8 or greater) 64bit
Sun May 29 10:55:07 2016 library versions: OpenSSL 1.0.1t  3 May 2016, LZO 2.09
Sun May 29 10:55:07 2016 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun May 29 10:55:07 2016 Need hold release from management interface, waiting...
Sun May 29 10:55:08 2016 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sun May 29 10:55:08 2016 MANAGEMENT: CMD 'state on'
Sun May 29 10:55:08 2016 MANAGEMENT: CMD 'log all on'
Sun May 29 10:55:08 2016 MANAGEMENT: CMD 'hold off'
Sun May 29 10:55:08 2016 MANAGEMENT: CMD 'hold release'
Sun May 29 10:55:08 2016 MANAGEMENT: CMD 'proxy NONE  '
Sun May 29 10:55:09 2016 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun May 29 10:55:09 2016 MANAGEMENT: >STATE:1464512109,RESOLVE,,,
Sun May 29 10:55:09 2016 UDPv4 link local: [undef]
Sun May 29 10:55:09 2016 UDPv4 link remote: [AF_INET]SERVERIP:1194
Sun May 29 10:55:09 2016 MANAGEMENT: >STATE:1464512109,WAIT,,,

На стороне сервера это соответствует

May 29 10:55:09 srv ovpn-server[732]: CORPORATEIP:15057 TLS: Initial packet from [AF_INET]CORPORATEIP:15057, sid=38d5a524 b40f69aa
May 29 10:56:09 srv ovpn-server[732]: CORPORATEIP:15057 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
May 29 10:56:09 srv ovpn-server[732]: CORPORATEIP:15057 TLS Error: TLS handshake failed
May 29 10:56:09 srv ovpn-server[732]: CORPORATEIP:15057 SIGUSR1[soft,tls-error] received, client-instance restarting
May 29 10:56:12 srv ovpn-server[732]: CORPORATEIP:15082 TLS: Initial packet from [AF_INET]CORPORATEIP:15082, sid=36d1f0e9 9cdc88ec

Таким образом, клиент достигает сервера, пытается установить соединение, а затем TLS Error: TLS key negotiation failed to occur within 60 seconds бывает.

В OpenVPN FAQ упоминает эту ошибку и предполагает, что трафик может быть защищен брандмауэром (на сервере или на клиенте). Это не так, поскольку клиент достигает сервера (поэтому udp/1154 трафик открыт на межсетевых экранах).

Раньше настройка работала, единственное изменение, о котором я могу думать, это изменение на стороне сервера: раньше он был в локальной сети с udp/1154 перенаправлен на него, теперь он находится в DMZ (где он сам управляет DNAT через iptables / shorewall, если необходимо). Поскольку пакеты от клиента достигают сервера, я не думаю, что это причина.

Прежде чем копать дальше, я бы хотел отбросить проблемы с брандмауэром:

Как я понимаю из вышеизложенного, соединение клиент -> сервер работает.
Трафик с сервера OpenVPN в мир открыт (могу пинговать CORPORATEIP например, UDP и TCP тоже открыты)

Верно ли мое предположение о том, что проблема в брандмауэре?

(Поскольку я хотел убедиться, что обратный путь не заблокирован, я установил на сервере небольшой HTTP-сервер и подключился к нему из корпоративной локальной сети, соединение проходит (тот же путь))

# server configuration
port 1194
proto udp
dev tun0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
dh /etc/openvpn/dh2048.pem
server 10.10.13.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
duplicate-cn
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

# client configuration
route-nopull
route 10.10.10.0 255.255.255.0
route 10.10.11.0 255.255.255.0
route 10.10.12.0 255.255.255.0
client
dev tun
proto udp
remote SERVER_IP 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
comp-lzo
verb 3
<ca>
-----BEGIN CERTIFICATE-----
MIIEgDCCA2igAwIBAgIJ...
(...)
b4yiCAmaA8p5JRYqYBiT...
p20oZw==
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
(...)
         8f:d4:9d:d0
-----BEGIN CERTIFICATE-----
MIIE3DCCA8SgAwIBAgIBA...
(...)
eGOJMoV4vXQ31DZmEl33l...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIIEvwIBADANBgkqhkiG9...
(...)
APOSuHJ4aXJocgOK3jGoK...
-----END PRIVATE KEY-----
</key>

openvpn

TL; DR: проблема заключалась в исходящем межсетевом экране.

Это брандмауэр с прозрачным прокси-сервером, который фильтрует, среди прочего, «приложения» (как это делается - это проприетарно - это устройство BlueCoat). Мне разрешено использовать VPN (включая OpenVPN), и демон, обрабатывающий авторизацию, вылетел из строя в выходные, что фактически отбросило мои пакеты.

Это локализованная проблема, и я подумал об удалении вопроса, но есть странное поведение, которое может помочь кому-то, кто сталкивается с аналогичной проблемой: только некоторые из пакетов OpenVPN помечены BlueCoat как "VPN", поэтому первоначальное соединение проходило через (а именно CLIENT_HARD_RESET) но другие пакеты (SERVER_HARD_RESET для начала) были заблокированы.

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