主页 / server / 问题 / 765521
Accepted
vmasanas
Asked: 2016-03-23 23:04:07 +0800 CST

OpenVPN 问题 - TLS 密钥协商未能在 60 秒内发生

  • 772

我正在 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。所以我从中了解到客户端至少能够到达服务器，所以没有路由或防火墙问题。

我按照这里提供的描述 Easy Windows Guide 有什么想法吗？

openvpn

12 个回答

  1. Best Answer

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

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

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

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

    此类设备通常仅使用 UDP 执行此操作，因此我建议您确认您使用的是 UDP，然后尝试使用 TCP。您已完成此操作，并发现它可以解决问题。下一步是识别行为不端的 NAT 设备，用棍子锤击它，然后用不会犯假设所有 UDP 通信都是短暂的重大错误的设备替换它；但是您表示您很高兴将更改为 TCP 作为一种解决方法，因此事情已经结束。

    • 31

  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 秒内发生（检查您的网络连接）

    • 7

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

    我们的 pfSense 防火墙上的 VPN 被错误地放在 LAN 接口而不是 WAN 接口上，因此导出的配置被设置为尝试连接到防火墙的 LAN IP 地址 - 这永远不会与客户端自然运行不同的局域网。

    我认为主要的收获是：

    • 获得密钥协商超时并不一定意味着您甚至已经设法连接到任何东西。

      所以在这个阶段，可能仍然值得检查您是否真的连接到正确的位置，并且没有防火墙规则阻止连接等。特别是如果您的配置是自动生成的。

      请注意，获得登录提示并不意味着您已连接，因为 OpenVPN 在尝试连接之前会询问您的凭据。

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

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

    • 4

  4. 我遇到了同样的错误，没有任何建议有帮助，一切似乎都很好：IP、端口、防火墙，一切。疯了2个小时。

    解决方案是在客户端配置中将协议从 UDP 更改为 TCP（显然我很久以前就故意禁用了 UDP）。

    希望这可以帮助某人:)

    LE：这解决了我的问题，但根据以下评论，这不是最好的方法。您应该使用 UDP 而不是 TCP。它对我有帮助，因为我在客户端和服务器配置之间有不同的设置。

    • 3

  5. 前面提到的解决方案都不起作用。就我而言，即使客户端日志显示相同的错误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
    • 2

  6. 请注意，您可能会收到 TLS 密钥协商错误，但无法成功连接到 OpenVPN 服务器 -甚至根本无法成功连接到任何东西！

    我修改了一个 VPN 配置以连接到 localhost，在一个没有监听任何东西的端口上：

    OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] 建于 2018 年 4 月 26 日
Windows 6.2 版（Windows 8 或更高版本）64 位
库版本：OpenSSL 1.1.0h 2018 年 3 月 27 日，LZO 2.10
TCP/UDP：保留最近使用的远程地址：[AF_INET]127.0.0.1:12345
UDP 链接本地（绑定）：[AF_INET][undef]:0
UDP 链接远程：[AF_INET]127.0.0.1:12345 
TLS 错误：TLS 密钥协商未能在 60 秒内发生（检查您的网络连接）
TLS 错误：TLS 握手失败
收到 SIGUSR1[soft,tls-error]，进程重新启动
...

    该错误可能会让您误以为您正在与 VPN 服务器通话。

    您甚至可能会首先收到提示输入凭据，但您的计算机之外的任何内容实际上都没有要求提供凭据。

    • 1

  7. 我在 AWS 中遇到了这个错误，其中 OpenVPN 安装在具有公共 IP 的服务器上，但安装在私有子网中的实例上，即没有通往互联网网关的路由的子网。

    一旦我在公共子网内的服务器上部署 OpenVPN，一切都运行良好 :)

    在 AWS 的公共/私有子网上：https ://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

    • 1

  8. 我也遇到了这个TLS key negotiation failed to occur within 60 seconds问题。

    从官方的建议来看，正如 Diamant 的帖子，网络连接肯定有问题。但是，防火墙和 NAT 都不会导致问题。

    就我而言，我首先通过nc -uvz xxx.xxx.xxx.xxx 1194. 链接没问题。

    此外，同一局域网内的其他几个 vpn 客户端工作正常。

    从某个地方我注意到 udp 连接在响应或端口转发方面存在一些问题。

    因此，我将正在运行的 vpn 客户端从最大 ip 停止到挂起的客户端，例如，从“10.8.0.100”到“10.8.0.50”。

    然后反向启动停止的 vpn 客户端。

    砰! 所有的 vpn 客户端都可以正常工作。

    总之，有可能导致TLS key negotiation failed to occur within 60 secondsLAN 中的多个 vpn 客户端以错误的顺序启动的问题。

    • 1

  9. 一个可能的原因是，如果服务器需要比客户端支持的 TLS 更新的 TLS 版本。即 1.2 对 1.0。

    显而易见的尝试是更新 OpenVPN 客户端，或修改服务器端以接受 TLS 1.0。

    • 0

  10. 您应该在 OMV 上创建 SSL/TLS 证书，然后启用安全连接 SSL/TLS 并添加创建的证书。很简单！

    • 0

相关问题