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

14

我正在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指南有什么想法吗？

openvpn 
— vmasanas
source
1
假设两个批次XX.XX.XX.XX代表相同的地址（请考虑不要混淆此类内容），我对源端口号的更改（57804、55938）很感兴趣。对我来说，这意味着存在一个不可靠的NAT，而UDP最常见。您正在使用UDP或TCP传输，如果是前者，可以尝试后者，看看问题是否消失了吗？
— MadHatter
我在服务器控制台上看到了此消息，至少客户端可以到达那里，所以我假设NAT不是问题。我在这里错了吗？
— vmasanas '16
1
并非所有NAT都是一样的。其中一些状态表条目的生存期非常短，尤其是对于UDP，并且OpenVPN不能很好地适应源端口的变化。请回答我提出的问题，如果合适，请尝试我建议的更改。
— MadHatter
我在这里经验不足，所以您能告诉我如何检查我使用的是UDP还是TCP？
— vmasanas '16
好吧，您可以尝试man openvpn寻找可以控制协议的东西。如果您决定进行测试，请不要忘记在客户端和服务器上都进行更改。
— MadHatter

Answers:

21

有趣的是端口号如何在中间更改：

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更改为一种解决方法，因此事情就此结束了。

— 疯了
source
2
+1为您的鹰眼！
— 钻石
@bangal为什么，谢谢！在这个行业中，很多魔鬼都存在于细节中。
— MadHatter
是的，我知道，但是我错过了，只有在您指出之后才能看到。可以肯定这是防火墙问题。
— 钻石
好吧，所以你是对的。而且不要打败自己，下次您会看起来更加努力！
— MadHatter
使用UDP代替TCP有什么好处吗？除非有任何不利之处，否则TCP现在为我工作。
— vmasanas '16
3

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

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

设置OpenVPN时最常见的问题之一是，连接两端的两个OpenVPN守护程序都无法彼此建立TCP或UDP连接。

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

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

在您的情况下，任何这些也很可能导致相同的问题。因此，只需逐一浏览清单即可解决该问题。

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

— 钻石
source
我已经讲完了这些要点，但是不确定是否遗漏了一些内容：1.目前客户端和服务器上的防火墙都关闭了，2.相同，3.路由器对服务器有转发规则，我看到了服务器控制台上出现流量，4.client具有正确的ip地址，5.我看不到防火墙。
— vmasanas '16
好吧，老实说，我目前无法想到其他任何事情。当然，Windows Server中的网络配置如何？是否有多个网关？它是指向路由器的默认网关吗？如果是，那么正如MadHatter建议的那样，您可以测试的其余部分都可以使用tcp进行测试。
— 钻石
如果有人感觉就像伸出援手，我已经发布了（另一个）TLS握手失败的问题在这里：serverfault.com/questions/867599/...
— 奥拉Tuvesson
需要注意的另一件事是两个主机之间的高延迟。我只是在这个问题上大步挠头，出于某些不可思议的原因，我在一个方向（客户端到服务器）上获得了6000ms +的ping往返往返，而在另一方向却没有。这导致密钥协商花费了60多个时间。重新启动我的ISP提供的路由器可以解决此问题。可能是一种罕见的边缘情况，但希望可以帮助某人。
— s.co.tt
3

我正在像这样获得TLS密钥协商超时。但就我而言，我意识到远程链接是本地IP地址。

pfSense防火墙上的VPN被错误地放置在LAN接口而不是WAN接口上，因此导出的配置被设置为尝试连接到防火墙的LAN IP地址-该客户端永远无法正常工作。一个不同的局域网。

我认为主要的收获是：

  • 获得关键的协商超时并不一定意味着您已经设法连接任何东西。

    因此，在此阶段，仍然有必要检查您是否已正确连接到正确的位置，并且没有阻止连接的防火墙规则等。尤其是当您的配置已自动生成时。

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

  • 确保您的VPN服务器在正确的界面上进行侦听。

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

— 姆费恩利
source
1

我遇到了同样的错误，没有任何建议，一切似乎都还不错：IP，端口，防火墙等所有东西。疯了2个小时。

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

希望这可以帮助某人:)

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

— 博世
source
您应该知道，由于两个TCP堆栈都试图相互竞争，因此将TCP封装在TCP中很可能会导致非常糟糕的性能问题。
— EEAA
确实，它像胡扯一样工作。尽管我听不懂您说什么，但表现却很差。那我应该切换到UDP吗？
— 博世
2
是。UDP是VPN实现的标准，这是有充分理由的。TCP具有纠错功能-能够重新传输丢失的数据包等。如果将TCP封装在TCP中，并且导致数据包丢失，则两个TCP堆栈（“内部”流量以及加密的OpenVPN流量）都将尝试并纠正丢失的数据包。将TCP封装在UDP中时，这不是问题-只有内部流量会重试。
— EEAA
感谢您的提示和解释。我切换到UDP，并注意连接。另外，我需要阅读更多有关堆栈的信息……
— bosch
一个有用的页面，解释了为什么TCP over TCP是个坏主意：sites.inka.de/bigred/devel/tcp-tcp.html
— mwfearnley，
1

请注意，您可能会收到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服务器通信。

甚至可能会首先提示您输入凭据，但是计算机外部实际上并没有要求它们。

— 姆费恩利
source
1

前面提到的解决方案均无效。就我而言，即使客户端日志显示了相同的错误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
— mpprdev
source
0

我也遇到了这个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 seconds问题，即局域网中的多个vpn客户端以错误的顺序开始。

— 参孙
source
1
目前尚不清楚这与原始问题中的问题有何关系。
— 病房-恢复莫妮卡
0

一种可能的原因是，如果服务器要求的TLS版本比客户端支持的TLS版本新。即1.2与1.0。

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

— 盎司
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.