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, 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 連接到伺服器，但同一設備可以連接 MOBILE DATA，而其他移動設備既不能連接 WiFi 也不能連接 MOBILE DATA ！！！！！！意味著不同的 ISP 不同的結果。在所有情況下，伺服器都會看到客戶端並且無法與 TLS 握手。但是另一台伺服器在所有設備的配置完全相同的情況下工作正常！！！！

我看到您將伺服器配置為使用 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"

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

引用自：https://serverfault.com/questions/967953