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

Question

我有两台配置完全相同的服务器。其中一个工作良好，但另一个给出了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

服务器Config：

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

客户Config：

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

不明飞行物状况：

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, emailAddress=me@myhost.mydomain
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, emailAddress=me@myhost.mydomain
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握手。但另一台服务器与所有设备的配置完全相同！

Answer 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 )：

push "route 10.10.1.0 255.255.255.0"

让我知道它是怎么工作的。