☰

OpenVPN 问题 - TLS 密钥协商在 60 秒内失败

tag-icon • tag-icon openvpn
OpenVPN 问题 - TLS 密钥协商在 60 秒内失败

我正在 Windows 2012 服务器上配置 OpenVPN（版本 2.3.10）服务器，但无法使其正常工作。

服务器位于路由器后面，我打开了 1194 端口并创建了一条规则，将此端口上的流量转发到服务器。

这是我尝试从客户端连接时在服务器上看到的日志：

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS handshake failed
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 SIGUSR1[soft,tls-error] received, client-instance restarting

其中 XX.XX.XX.XX 是客户端的 IP。因此，我由此理解，客户端至少能够到达服务器，因此不存在路由或防火墙问题。

我按照这里提供的描述阅读了《简易 Windows 指南》，有什么想法吗？

答案1

有趣的是端口号在中途是如何变化的：

2016 年 3 月 21 日星期一 11:11:47 XX.XX.XX.XX：57804TLS：来自 [AF_INET]XX.XX.XX.XX:57804 的初始数据包，sid=fdf7a7ac 0264c7f3

2016 年 3 月 21 日星期一 11:12:38 XX.XX.XX.XX：55938TLS：来自 [AF_INET]XX.XX.XX.XX:55938 的初始数据包，sid=1f242a3f e454a525

这让我想到，在客户端和服务器之间的某个地方，存在一个行为不当的 NAT 设备，该设备具有非常短暂的状态表条目，它正在更改它应用于客户端已建立的流的源端口号，导致服务器认为正在进行两个短暂的通信，而不是一个连续的通信。

此类设备通常只使用 UDP 才能实现这一点，因此我建议您确认您使用的是 UDP，并尝试使用 TCP。您已这样做，并发现它解决了问题。下一步是识别行为不当的 NAT 设备，用大锤敲打它，并将其替换为不会犯下大错（即假设所有 UDP 通信都是短暂的）的设备；但您已表示您乐意改用 TCP 作为解决方法，因此事情就此结束。

答案2

这是设置 Openvpn 时最常见的错误之一，对此有一个常见问题解答。我将在此引用此内容：

TLS 错误：TLS 密钥协商在 60 秒内失败（请检查您的网络连接）

设置 OpenVPN 时最常见的问题之一是连接两侧的两个 OpenVPN 守护进程无法相互建立 TCP 或 UDP 连接。

这几乎是以下原因造成的：

  • 服务器网络上的外围防火墙正在过滤传入的 OpenVPN 数据包（默认情况下，OpenVPN 使用 UDP 或 TCP 端口号 1194）。
  • OpenVPN 服务器机器本身上运行的软件防火墙正在过滤端口 1194 上的传入连接。请注意，许多操作系统默认会阻止传入连接，除非另有配置。
  • 服务器网络上的 NAT 网关没有针对 TCP/UDP 1194 到 OpenVPN 服务器计算机内部地址的端口转发规则。
  • OpenVPN 客户端配置在其配置文件中没有正确的服务器地址。客户端配置文件中的远程指令必须指向服务器本身或服务器网络网关的公共 IP 地址。
  • 另一个可能的原因是 Windows 防火墙阻止了对 openvpn.exe 二进制文件的访问。您可能需要将其列入白名单（将其添加到“例外”列表中）以使 OpenVPN 正常工作。

很有可能其中任何一个也会导致你遇到同样的问题。因此，只需逐一检查列表即可解决问题。

参考：TLS 错误：TLS 密钥协商在 60 秒内失败（请检查您的网络连接）

答案3

我遇到了这样的 TLS 密钥协商超时。但就我而言，我意识到远程链接是本地 IP 地址。

我们的 pfSense 防火墙上的 VPN 错误地被放置在 LAN 接口而不是 WAN 接口上，因此导出的配置被设置为尝试连接到防火墙的 LAN IP 地址——由于客户端自然位于不同的 LAN 上，这根本行不通。

我认为，这其中的主要启示是：

  • 获得密钥协商超时并不一定意味着您已经成功连接任何东西。

    因此，在这个阶段可能仍然值得检查您是否实际连接到正确的地方，并且没有防火墙规则阻止连接等。特别是如果您的配置已经自动生成。

    请注意，获取登录提示并不意味着你已经连接，因为 OpenVPN 在尝试连接之前会要求您提供凭据。

  • 确保您的 VPN 服务器正在监听正确的接口。

    （当然，这是可能发生的众多服务器端配置错误之一，例如防火墙规则、输入错误的端口号、混合 TCP 和 UDP 等。）

答案4

前面提到的解决方案均无效。就我而言，尽管客户端日志显示相同的错误TLS Error: TLS key negotiation failed to occur within 60 seconds，但服务器日志显示VERIFY ERROR: depth=0, error=CRL has expired。

在服务器上，以下步骤解决了连接问题：

# cd <easyrsa folder>
# ./easyrsa gen-crl
above command generates new crl.pem file (in my case in pki folder)
using chown/chmod make sure 'pki/crl.pem' is readable by openvpn server (for example: chmod 640 pki/crl.pem)
# systemctl restart openvpn

相关内容