☰

OpenVPN TLS 握手失败-还能是什么原因？

tag-icon • tag-icon openvpn
OpenVPN TLS 握手失败-还能是什么原因？

我有两个完全不同的客户端，它们位于两个完全不同的网络上，都无法连接到新配置的 OpenVPN 服务器，并且都导致日志条目在服务器上如下所示：

Aug  8 20:37:15 myserver ovpn-server[3797]: 12.34.56.78:48573 TLS: Initial packet from [AF_INET]12.34.56.78:48573, sid=80063aef 9e45c93a
Aug  8 20:38:15 myserver ovpn-server[3797]: 12.34.56.78:48573 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Aug  8 20:38:15 myserver ovpn-server[3797]: 12.34.56.78:48573 TLS Error: TLS handshake failed
Aug  8 20:38:15 myserver ovpn-server[3797]: 12.34.56.78:48573 SIGUSR1[soft,tls-error] received, client-instance restarting

客户端是连接到 NAT ADSL 路由器的 *buntu 笔记本电脑上的 OpenVPN，以及内置 OpenVPN 客户端的 3G/4G WWAN 路由器。

以下是我目前检查过的内容：

  • 防火墙已打开（否则 TLS 握手如何开始）
  • 两端的时间/日期设置正确
  • OpenVPN 客户端是最新的（至少在笔记本电脑上，在 3G/4G 路由器上更难检查）
  • UDP 端口号在协商的整个生命周期内不会改变（参见上面的日志）

还有什么原因可能导致这种情况？

编辑：所以，情节变得复杂了……无奈之下，我尝试将整个配置链改为使用 TCP，否则就让一切保持原样。砰！我的 *buntu 笔记本电脑上的 OpenVPN 客户端能够立即连接。但是，当 3G/4G 路由器的 OpenVPN 客户端甚至不支持 TCP 传输时该怎么办？我还没做完！

编辑：只是为了清楚起见；我改变了四要让它发挥作用，需要做以下事情：

  1. 编辑 OpenVPN 的配置，改为：proto tcp并proto udp重新启动 OpenVPN
  2. 在服务器的 iptables 防火墙中添加了一条新规则，以允许 TCP 1194 - 否则与允许 UDP 1194 的现有规则相同
  3. 编辑了我的笔记本电脑所连接的路由器上的防火墙规则上的服务定义协议，以允许 TCP 1194 出站而不是 UDP 1194 出站（实际上只是一个下拉框）
  4. 通过网络管理器编辑笔记本电脑上的 OpenVPN 连接信息，并选中Use a TCP connection复选框

每一个其他设置和配置保持不变完全相同的和以前一样。

编辑：我隐隐觉得我的 VPN 服务器上的 UDP 流量路由出现了一些异常；OpenVPN 配置绑定的 IP 地址不是服务器的主 IP 地址，实际上它甚至不在同一子网中。路由表如下所示：

$ route
Kernel IP routing table
Destination     Gateway          Genmask         Flags Metric Ref    Use Iface
default         11-22-33-1.thing 0.0.0.0         UG    0      0        0 eth0
22.33.44.0      *                255.255.255.0   U     0      0        0 eth0
10.8.0.0        *                255.255.255.0   U     0      0        0 tun0
11.22.33.0      *                255.255.255.0   U     0      0        0 eth0

$ ip route
default via 11.22.33.1 dev eth0 onlink 
22.33.44.0/24 dev eth0  proto kernel  scope link  src 22.33.44.55 
10.8.0.0/24 dev tun0  proto kernel  scope link  src 10.8.0.1 
11.22.33.0/24 dev eth0  proto kernel  scope link  src 11.22.33.44

22.33.44.55 IP 地址是后来分配的，也是 OpenVPN 绑定的地址。现在我首先承认我知道没有什么关于 IP 路由，但可能是由于“新”IP 地址没有自己的默认路由，所以该 IP 地址上的 UDP 流量会以某种方式丢失 - 或者其他原因？

答案1

事实证明我是对的：local 22.33.44.55OpenVPN 中server.config缺少该选项。添加它并重新启动 OpenVPN 解决了​​这个问题，UDP 传输现在在我的辅助 IP 上工作。如果没有它，OpenVPN 的响应将通过默认 IP 发送 - 虽然我不明白为什么这不会阻止 TCP 工作。如果你喜欢，这是一个小学生错误，但我使用的 OpenSSL 配置脚本（https://github.com/Angristan/OpenVPN-install）做过询问在设置期间使用的 IP 地址，所以我只是假设它已正确配置。

答案2

只是分享我在处理这个问题时发现的问题。不久前，我将我的 xbox 添加到了 dmz。在搜索界面时，我发现如果启用了 DMZ，它会阻止对防火墙的外部访问。一旦我禁用了 DMZ，一切就都正常了。哎呀！

答案3

OpenVPN 问题 - TLS 密钥协商失败 - 已修复

突然，我们的服务器和所有客户端都出现了以下错误：

2023 年 7 月 26 日，星期三 05:31:45 tls-crypt 解包错误：数据包太短 2023 年 7 月 26 日，星期三 05:31:45 TLS 错误：tls-crypt 从 [AF_INET]205.210.31.209:54134 解包失败 2023 年 7 月 26 日，星期三 05:52:22 XX.XX.XX.XX:8532 TLS：来自 [AF_INET]185.220.10.55:8532 的初始数据包，sid=722b49c7 300fc366 2023 年 7 月 26 日，星期三 05:52:43 XX.XX.XX.XX:36039 TLS：来自 [AF_INET]185.220.10.55:36039 的初始数据包， sid=c3cca05e 544fb4df 2023 年 7 月 26 日，星期三 05:52:52 XX.XX.XX.XX:25800 TLS 错误：TLS 密钥协商在 60 秒内失败（请检查您的网络连接）2023 年 7 月 26 日，星期三 05:52:52 XX.XX.XX.XX:25800 TLS 错误：TLS 握手失败 2023 年 7 月 26 日，星期三 05:52:52 XX.XX.XX.XX:25800 SIGUSR1[soft,tls-error] 已收到，客户端实例正在重新启动

经过大量检查，我们意识到服务器证书已经过期。

sudo openssl x509 -enddate -noout -in server_certificate.crt

我们使用 debian10-vpn.sh 脚本安装了服务器，该脚本可以自动完成很多配置，但它生成的证书有效期约为 800 天。

我们找不到替换服务器证书的方法，因此我们找到的解决方案是卸载并重新安装 OpenVPN。

我们必须再次重新生成所有客户端的证书，但它起作用了。

答案4

还能是什么？

嗯，有一件事也影响到了我：我的客户端配置为 UDP，而服务器需要 TCP。

这肯定不是 OP 的情况，而且可能是新手错误，但我想有人在野外提到它是件好事。

相关内容