几天以来，我遇到了一个令人沮丧的 OpenVPN TLS 错误问题，有些客户端可以连接到我的 OpenVPN 服务器，有些则不能。它在 Windows 上使用 UDP/1194 运行，所有客户端都具有完全相同的设置。我附加了一个工作客户端和一个不工作客户端的服务器日志级别 6。我无法访问不工作客户端日志（它是远程的）。
此外，这个精确的装置曾经运行了很长时间（一年多），直到三天前才停止。
看起来客户端可以访问服务器，但服务器无法回复客户端。但这只发生在部分客户端上，即使是属于同一电信公司网络的客户端（在偏远地区）。所以我无法想象这怎么可能是防火墙错误。
最小的 server.conf
dev tun
proto udp
port 1194
ca ...
cert ...
key ...
dh ...
server 10.8.0.0 255.255.0.0
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
客户端未连接的服务器日志
Fri Apr 07 09:51:38 2017 us=278366 bad_client:49003 Re-using SSL/TLS context
Fri Apr 07 09:51:38 2017 us=278366 bad_client:49003 LZO compression initialized
Fri Apr 07 09:51:38 2017 us=278366 bad_client:49003 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Apr 07 09:51:38 2017 us=278366 bad_client:49003 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Apr 07 09:51:38 2017 us=278366 bad_client:49003 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Fri Apr 07 09:51:38 2017 us=278366 bad_client:49003 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Fri Apr 07 09:51:38 2017 us=278366 bad_client:49003 Local Options hash (VER=V4): 'a8f55717'
Fri Apr 07 09:51:38 2017 us=278366 bad_client:49003 Expected Remote Options hash (VER=V4): '22188c5b'
Fri Apr 07 09:51:38 2017 us=278366 bad_client:49003 UDPv4 READ [14] from [AF_INET]bad_client:49003: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Apr 07 09:51:38 2017 us=278366 bad_client:49003 TLS: Initial packet from [AF_INET]bad_client:49003, sid=7ea5008f ee298f22
Fri Apr 07 09:51:38 2017 us=278366 bad_client:49003 UDPv4 WRITE [26] to [AF_INET]bad_client:49003: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Fri Apr 07 09:51:40 2017 us=310517 bad_client:49003 UDPv4 WRITE [14] to [AF_INET]bad_client:49003: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
Fri Apr 07 09:51:44 2017 us=374822 bad_client:49003 UDPv4 WRITE [14] to [AF_INET]bad_client:49003: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
Fri Apr 07 09:51:52 2017 us=503448 bad_client:49003 UDPv4 WRITE [14] to [AF_INET]bad_client:49003: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
Fri Apr 07 09:52:08 2017 us=791909 bad_client:49003 UDPv4 WRITE [14] to [AF_INET]bad_client:49003: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
Fri Apr 07 09:52:39 2017 us=87018 bad_client:49003 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Apr 07 09:52:39 2017 us=87018 bad_client:49003 TLS Error: TLS handshake failed
Fri Apr 07 09:52:39 2017 us=87018 bad_client:49003 SIGUSR1[soft,tls-error] received, client-instance restarting
Fri Apr 07 09:52:39 2017 us=399300 MULTI: multi_create_instance called
Fri Apr 07 09:52:39 2017 us=399300 bad_client:49004 Re-using SSL/TLS context
Fri Apr 07 09:52:39 2017 us=399300 bad_client:49004 LZO compression initialized
Fri Apr 07 09:52:39 2017 us=399300 bad_client:49004 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Apr 07 09:52:39 2017 us=399300 bad_client:49004 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Apr 07 09:52:39 2017 us=399300 bad_client:49004 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Fri Apr 07 09:52:39 2017 us=399300 bad_client:49004 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Fri Apr 07 09:52:39 2017 us=399300 bad_client:49004 Local Options hash (VER=V4): 'a8f55717'
Fri Apr 07 09:52:39 2017 us=399300 bad_client:49004 Expected Remote Options hash (VER=V4): '22188c5b'
Fri Apr 07 09:52:39 2017 us=399300 bad_client:49004 UDPv4 READ [14] from [AF_INET]bad_client:49004: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Apr 07 09:52:39 2017 us=399300 bad_client:49004 TLS: Initial packet from [AF_INET]bad_client:49004, sid=3850de6b eadae20a
Fri Apr 07 09:52:39 2017 us=399300 bad_client:49004 UDPv4 WRITE [26] to [AF_INET]bad_client:49004: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Fri Apr 07 09:52:41 2017 us=775314 bad_client:49004 UDPv4 WRITE [14] to [AF_INET]bad_client:49004: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
Fri Apr 07 09:52:45 2017 us=292476 bad_client:49004 UDPv4 WRITE [14] to [AF_INET]bad_client:49004: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
客户端连接的服务器日志
Fri Apr 07 09:51:46 2017 us=109968 MULTI: multi_create_instance called
Fri Apr 07 09:51:46 2017 us=109968 good_client:62320 Re-using SSL/TLS context
Fri Apr 07 09:51:46 2017 us=109968 good_client:62320 LZO compression initialized
Fri Apr 07 09:51:46 2017 us=109968 good_client:62320 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Apr 07 09:51:46 2017 us=109968 good_client:62320 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Apr 07 09:51:46 2017 us=109968 good_client:62320 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Fri Apr 07 09:51:46 2017 us=109968 good_client:62320 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Fri Apr 07 09:51:46 2017 us=109968 good_client:62320 Local Options hash (VER=V4): 'a8f55717'
Fri Apr 07 09:51:46 2017 us=109968 good_client:62320 Expected Remote Options hash (VER=V4): '22188c5b'
Fri Apr 07 09:51:46 2017 us=109968 good_client:62320 UDPv4 READ [14] from [AF_INET]good_client:62320: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Apr 07 09:51:46 2017 us=109968 good_client:62320 TLS: Initial packet from [AF_INET]good_client:62320, sid=0a4a2388 525f8203
Fri Apr 07 09:51:46 2017 us=109968 good_client:62320 UDPv4 WRITE [26] to [AF_INET]good_client:62320: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Fri Apr 07 09:51:46 2017 us=156863 good_client:62320 UDPv4 READ [22] from [AF_INET]good_client:62320: P_ACK_V1 kid=0 [ 0 ]
Fri Apr 07 09:51:46 2017 us=156863 good_client:62320 UDPv4 READ [114] from [AF_INET]good_client:62320: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=100
Fri Apr 07 09:51:46 2017 us=156863 good_client:62320 UDPv4 WRITE [22] to [AF_INET]good_client:62320: P_ACK_V1 kid=0 [ 1 ]
Fri Apr 07 09:51:46 2017 us=156863 good_client:62320 UDPv4 READ [114] from [AF_INET]good_client:62320: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=100
Fri Apr 07 09:51:46 2017 us=156863 good_client:62320 UDPv4 WRITE [22] to [AF_INET]good_client:62320: P_ACK_V1 kid=0 [ 2 ]
如您所见，第二个客户端发回服务器的 P_ACK_V1 永远不会由第一个客户端发送。因此，它会一直尝试完成握手...
我意识到这个 TLS 错误是一个非常常见的问题，但有些客户端可以工作，有些则不行？我检查了服务器防火墙以及一些不同的配置（如下所示），但无济于事。
local xxx.xxx.xxx.xxx（公共服务器 IP 地址）
有什么办法可以解决这个问题吗？这可能是网络/路由问题吗？非常感谢您的阅读！
编辑：为正在连接的客户端添加了客户端日志。正如预期的那样，它与服务器日志相匹配，确认了数据包。我没有未连接客户端的日志，因为我无法使用来自我家庭网络的任何客户端复制该问题，而那些客户端已经是远程的了……
Fri Apr 07 17:13:25 2017 us=228914 UDPv4 link local: [undef]
Fri Apr 07 17:13:25 2017 us=228914 UDPv4 link remote: [AF_INET]vpn_server:1194
Fri Apr 07 17:13:25 2017 us=228914 MANAGEMENT: >STATE:1491578005,WAIT,,,
Fri Apr 07 17:13:25 2017 us=228914 UDPv4 WRITE [14] to [AF_INET]vpn_server:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Apr 07 17:13:25 2017 us=229914 UDPv4 READ [0] from [undef]: DATA UNDEF len=-1
Fri Apr 07 17:13:25 2017 us=272916 UDPv4 READ [26] from [AF_INET]vpn_server:1194: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Fri Apr 07 17:13:25 2017 us=272916 MANAGEMENT: >STATE:1491578005,AUTH,,,
Fri Apr 07 17:13:25 2017 us=272916 TLS: Initial packet from [AF_INET]vpn_server:1194, sid=ba8f04dc 7b6b2ffb
Fri Apr 07 17:13:25 2017 us=273916 UDPv4 WRITE [22] to [AF_INET]vpn_server:1194: P_ACK_V1 kid=0 [ 0 ]
Fri Apr 07 17:13:25 2017 us=273916 UDPv4 WRITE [114] to [AF_INET]vpn_server:1194: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=100
Fri Apr 07 17:13:25 2017 us=273916 UDPv4 WRITE [114] to [AF_INET]vpn_server:1194: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=100
Fri Apr 07 17:13:25 2017 us=273916 UDPv4 WRITE [15] to [AF_INET]vpn_server:1194: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=1
Fri Apr 07 17:13:25 2017 us=314919 UDPv4 READ [22] from [AF_INET]vpn_server:1194: P_ACK_V1 kid=0 [ 1 ]
Fri Apr 07 17:13:25 2017 us=315919 UDPv4 READ [22] from [AF_INET]vpn_server:1194: P_ACK_V1 kid=0 [ 2 ]
Fri Apr 07 17:13:25 2017 us=323919 UDPv4 READ [126] from [AF_INET]vpn_server:1194: P_CONTROL_V1 kid=0 [ 3 ] pid=1 DATA len=100
Fri Apr 07 17:13:25 2017 us=324919 UDPv4 WRITE [22] to [AF_INET]vpn_server:1194: P_ACK_V1 kid=0 [ 1 ]
答案1
出于完整性考虑，这不是网络/防火墙问题，也不是 OpenVPN 配置问题。只是一些客户端（通过预付费 3G 连接）余额不足……
问题是，客户端发出的数据包可以到达服务器，但服务器发出的数据包无法到达客户端。我猜低余额限制只限于下载。