OpenVPN TLS 错误:TLS 密钥协商失败

OpenVPN TLS 错误:TLS 密钥协商失败

我有两台配置完全相同的服务器。其中一台运行正常,但另一台出现 TLS 错误!其他帖子中提到的解决方案均无效...

服务器 Ubuntu 16.04

OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08

服务器配置:

port 1398
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 4.2.2.4"
keepalive 10 120
tls-auth ta.key 0
key-direction 0
cipher none
auth SHA1
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

客户端配置:

client
dev tun
proto tcp
remote XX.XX.173.7 1398
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
tls-auth ta.key 1
cipher none
auth SHA1
key-direction 1
verb 3

UFW 状态:

root@static:~# sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
1398/tcp                   ALLOW       Anywhere
1398/udp                   ALLOW       Anywhere
1398/tcp (v6)              ALLOW       Anywhere (v6)
1398/udp (v6)              ALLOW       Anywhere (v6)

路由表:

root@static:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         static.1.173.9. 0.0.0.0         UG    0      0        0 ens32
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
root@static:~# ip route
default via XX.XX.173.1 dev ens32 onlink
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1

服务器日志:

May 19 10:39:54 static ovpn-server[2231]: 91.92.125.54:63515 TCPv4_SERVER WRITE [1184] to [AF_INET]91.92.125.54:63515: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=1170
May 19 10:39:55 static ovpn-server[2231]: 91.92.125.54:63515 TCPv4_SERVER WRITE [314] to [AF_INET]91.92.125.54:63515: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=300
May 19 10:40:09 static ovpn-server[2231]: 91.92.125.54:63515 TCPv4_SERVER WRITE [1184] to [AF_INET]91.92.125.54:63515: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=1170
May 19 10:40:10 static ovpn-server[2231]: 91.92.125.54:63515 TCPv4_SERVER WRITE [1184] to [AF_INET]91.92.125.54:63515: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=1170
May 19 10:40:11 static ovpn-server[2231]: 91.92.125.54:63515 TCPv4_SERVER WRITE [314] to [AF_INET]91.92.125.54:63515: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=300
May 19 10:40:37 static ovpn-server[2231]: 91.92.125.54:63515 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
May 19 10:40:37 static ovpn-server[2231]: 91.92.125.54:63515 TLS Error: TLS handshake failed
May 19 10:40:37 static ovpn-server[2231]: 91.92.125.54:63515 Fatal TLS error (check_tls_errors_co), restarting
May 19 10:40:37 static ovpn-server[2231]: 91.92.125.54:63515 SIGUSR1[soft,tls-error] received, client-instance restarting
May 19 10:40:37 static ovpn-server[2231]: TCP/UDP: Closing socket

客户端日志:

Sun May 19 15:08:28 2019 NOTE: --user option is not implemented on Windows
Sun May 19 15:08:28 2019 NOTE: --group option is not implemented on Windows
Sun May 19 15:08:28 2019 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Sun May 19 15:08:28 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Sun May 19 15:08:28 2019 library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
Sun May 19 15:08:28 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun May 19 15:08:28 2019 Need hold release from management interface, waiting...
Sun May 19 15:08:29 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'state on'
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'log all on'
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'echo all on'
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'bytecount 5'
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'hold off'
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'hold release'
Sun May 19 15:08:29 2019 ******* WARNING *******: '--cipher none' was specified. This means NO encryption will be performed and tunnelled data WILL be transmitted in clear text over the network! PLEASE DO RECONSIDER THIS SETTING!
Sun May 19 15:08:29 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun May 19 15:08:29 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun May 19 15:08:29 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]5.9.173.7:1398
Sun May 19 15:08:29 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun May 19 15:08:29 2019 Attempting to establish TCP connection with [AF_INET]5.9.173.7:1398 [nonblock]
Sun May 19 15:08:29 2019 MANAGEMENT: >STATE:1558262309,TCP_CONNECT,,,,,,
Sun May 19 15:08:30 2019 TCP connection established with [AF_INET]5.9.173.7:1398
Sun May 19 15:08:30 2019 TCP_CLIENT link local: (not bound)
Sun May 19 15:08:30 2019 TCP_CLIENT link remote: [AF_INET]5.9.173.7:1398
Sun May 19 15:08:30 2019 MANAGEMENT: >STATE:1558262310,WAIT,,,,,,
Sun May 19 15:08:30 2019 MANAGEMENT: >STATE:1558262310,AUTH,,,,,,
Sun May 19 15:08:30 2019 TLS: Initial packet from [AF_INET]5.9.173.7:1398, sid=aa04c80d cadbb603
Sun May 19 15:08:30 2019 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=MyOrganizationalUnit, CN=Fort-Funston CA, name=EasyRSA, [email protected]
Sun May 19 15:08:30 2019 VERIFY KU OK
Sun May 19 15:08:30 2019 Validating certificate extended key usage
Sun May 19 15:08:30 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun May 19 15:08:30 2019 VERIFY EKU OK
Sun May 19 15:08:30 2019 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=MyOrganizationalUnit, CN=server, name=EasyRSA, [email protected]
Sun May 19 15:09:30 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun May 19 15:09:30 2019 TLS Error: TLS handshake failed
Sun May 19 15:09:30 2019 Fatal TLS error (check_tls_errors_co), restarting
Sun May 19 15:09:30 2019 SIGUSR1[soft,tls-error] received, process restarting
Sun May 19 15:09:30 2019 MANAGEMENT: >STATE:1558262370,RECONNECTING,tls-error,,,,,
Sun May 19 15:09:30 2019 Restart pause, 5 second(s)

奇怪的是客户端日志中显示“验证成功”

PS1:一个新的发现是,虽然我无法通过 WiFi 使用手机连接到服务器,但同一设备可以通过移动数据连接,而其他移动设备既无法通过 WiFi 也无法通过移动数据连接!!!!这意味着不同的 ISP 有不同的结果。并且在所有情况下,服务器都会看到客户端,只是无法握手 TLS。但另一台服务器在所有设备上使用完全相同的配置都能正常工作!!!!

答案1

我看到您将服务器配置为使用 tcp。

据我所知,为了使用 tls-auth 指令,您必须使用“udp”协议而不是“tcp”。

OpenVPN 官方文档

The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:

* DoS attacks or port flooding on the OpenVPN UDP port.
* Port scanning to determine which server UDP ports are in a listening state.
* Buffer overflow vulnerabilities in the SSL/TLS implementation.
* SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).

编辑#1:

我相信您缺少到 OpenVPN 子网的“推送路由”,请尝试将其添加到您的 server.conf 中:

push "route 10.8.0.0 255.255.255.0" 

此外,如果您希望 OpenVPN 客户端能够与 LAN 中的其他机器建立连接,请添加另一个推送,如下所示(将 10.10.1.0 替换为您的 LAN cidr):

push "route 10.10.1.0 255.255.255.0"

让我知道它是如何工作的。

相关内容