我有一个 UDP OpenVPN 服务器（在 TAP 模式下运行，但这并不重要）。连接成功启动并通过了 TLS-AUTH (HMAC)，但卡在了那里。我在服务器日志中看到重复的以下日志：
Sun Jan 14 13:34:10 2018 us=104130 <CLIENT>:59975 UDPv4 READ [54] from [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
Sun Jan 14 13:34:10 2018 us=104252 <CLIENT>:59975 UDPv4 WRITE [66] to [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0
Sun Jan 14 13:34:12 2018 us=524356 <CLIENT>:59975 UDPv4 WRITE [54] to [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
Sun Jan 14 13:34:12 2018 us=650416 <CLIENT>:59975 UDPv4 READ [54] from [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
....
但在客户端我有：
2018-01-14 13:34:56 us=989963 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:00 us=476619 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #3 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:08 us=911249 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #4 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:24 us=86742 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #5 ] [ ] pid=0 DATA len=0
这里发生了什么？这并不是说有防火墙阻止它，我可以使用其他服务通过此端口正确通信（运行 netcat 服务器，双向通信正常工作）。
答案1
您似乎有一个单向链接。客户端可以与服务器通信，但服务器无法与客户端通信。所以存在某种阻塞或误导发生在服务器 -> 客户端方向。
也许是客户端防火墙？
（强调我的）
我的解决方案是将行添加local 192.168.1.X到我的服务器配置文件中。根据 OpenVPN 文档：
--本地主机
本地主机名或 IP 地址。如果指定，OpenVPN 将仅绑定到该地址。如果未指定，OpenVPN 将绑定到所有接口。
显然，这是一个网络问题，但这是一个可以在不解决根本问题的情况下解决的问题。对我来说，问题是如何配置桥接接口和分接接口。我把它搞砸了，OpenVPN 试图通过一个接口将其响应数据包路由回，而该接口无法将其路由到目的地，因此通过指定绑定到它的特定接口只会将其从该接口发送出去与给定的IP。我还能够通过修复我的bridge-start脚本来绕过这个问题（并且不再需要本地配置标志），这样它就不会最终创建多个分接接口（所有额外的桥都是无法路由的黑洞）。请注意，即使您使用的是本地地址，它仍然可以在内部网络之外/通过 NAT 正常工作。
答案2
就我而言，这是客户端配置了 tls-crypt 的症状，而服务器没有配置。客户因“数据包太短”而取消。解决方案是添加
tls-crypt /path/to/my.tls.key
在 server.conf 中