☰

客户端问候后，curl 挂起

tag-icon • tag-icon curl ssl handshake
客户端问候后，curl 挂起

当我在 Ubuntu 中执行以下命令时：

 curl -v --insecure -XGET 'https://user:pass@IP_ADDR:PORT/SOME_FILE.php'

我得到这个输出：

* Hostname was NOT found in DNS cache
*   Trying IP_ADDR...
* Connected to IP_ADDR (IP_ADDR) port PORT (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):

几分钟后我得到了这个：

* Unknown SSL protocol error in connection to IP_ADDR:PORT 
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to IP_ADDR:PORT

当我在 CentOS 中尝试同样的事情时，我仍然陷入困境Client Hello，但最终我得到了这个：

curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received

有谁知道是什么原因导致的以及如何修复它？

答案1

我们遇到了同样的问题，原因是 MTU 配置错误，但还有许多其他可能的原因。

关键是嗅探我们边缘路由器上的流量，我们在其中看到发往服务器 (GitHub.com) 的 ICMP 消息，请求碎片化。这会导致连接混乱，导致重传、重复的 ACK 等。

在此输入图像描述

ICMP 数据包有一个字段，MTU of next hop其值为奇怪的 1450。通常的值为 1500。

在此输入图像描述

我们检查了路由器，其中一个接口（以太网隧道）具有该值作为 MTU，因此路由器将所有接口的最小 MTU 作为下一跳。一旦我们删除了这个接口（它未被使用），SSH 握手就再次开始工作。

答案2

我在通过 OpenVPN 连接两个基础设施时遇到了同样的问题。

Curl 不适用于 https/http

查理的解决方案适合我。

我点击了这个链接：https://www.sonassi.fr/help/troubleshooting/setting- Correct-mtu-for-openvpn。

因此，要找到正确的 MTU，您可以使用以下命令：

bryan@debian-dev11@ping -c 1 -M do -s 1472 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 1472(1500) bytes of data.
1480 bytes from 10.0.0.5: icmp_seq=1 ttl=126 time=6.19 ms

其中 1472 是您测试的 MTU

以及 MTU 错误的响应

bryan@debian-dev11:~$ ping -c 1 -M do -s 1474 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 1474(1502) bytes of data.
ping: local error: Message too long, mtu=1500

您的目标服务器的防火墙必须接受 icmp/echo 请求。

在我的具体情况下，我位于两个路由器后面，通过两个 nat 规则，一个接一个。当数据包到达最终主机时，最终主机请求的是网关以外的缺失部分，而不是原始 IP。因此，请求无法到达原始主机。

答案3

我的猜测是，您尝试对服务器使用 https：端口，其中 https 根本不可用。在这种情况下，服务器仍然等待 HTTP 请求结束，而客户端则等待服务器继续 SSL 握手。检查是否可以使用浏览器访问与 https 完全相同的 URL。

答案4

我没有足够的观点来评论，但查理的回答帮助我解决了设置伪装的问题。但是我无法删除该设备，因为在我的情况下它是传出 ppp0 连接。

在这种情况下，它帮助我直接或通过 dhcpd 配置将其他客户端的 MTU 减少到 ppp0 设备值 (1492)。在这种情况下，症状是尝试获取电子邮件（仅在某些服务器上）时出现 TLS 握手问题，以及来自其他客户端的视频流出现问题。

相关内容