概括

2024-6-11 • tag-icon

概括

从 Multipass VM运行似乎会导致挂起 TLS 协商，因为302 重定向 URLcurl -sfL https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/sha256sum-amd64.txt没有响应。(IN), TLS handshake, Server hello (2)

细节

我正在尝试安装凯利在我的 Mac 上的 Multipass VM 上，如文档所述这里和这里。k3s 安装过程涉及下载并运行安装脚本（curl -sfL https://get.k3s.io | sh -）——但是，该脚本在 Multipass VM 上运行时会中途挂起：

[INFO]  Finding release for channel stable
[INFO]  Using v1.25.4+k3s1 as release
[INFO]  Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/sha256sum-amd64.txt
[...hangs...]

通过逐步执行脚本，我发现它挂在对的调用上curl -sfL https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/sha256sum-amd64.txt。我尝试直接复制此调用（设置了详细标志）- 选择以下输出：

$ curl -V
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.13
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

$ curl -vvv -sfL https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/sha256sum-amd64.txt
*   Trying 192.30.255.112:443...
* Connected to github.com (192.30.255.112) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
[...]
< HTTP/2 302
[...]
* Connection #0 to host github.com left intact
* Issue another request to this URL: 'https://objects.githubusercontent.com/github-production-release-asset-2e65be/135516270/546bdb42-d049-41b6-89f8-6595cecb44cf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20221128%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20221128T222055Z&X-Amz-Expires=300&X-Amz-Signature=9620505493b7e78166ac812f7aed14b75927d4fd40aa0648ab7f08a1489071a9&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=135516270&response-content-disposition=attachment%3B%20filename%3Dsha256sum-amd64.txt&response-content-type=application%2Foctet-stream'
*   Trying 185.199.108.133:443...
* Connected to objects.githubusercontent.com (185.199.108.133) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
[...hangs...]

调用第一个 URL 会导致 302 重定向到不同的 url，随后会进行 curl（由于-L） - 但是，在尝试为第二个位置协商 TLS 时，远程服务器没有响应。

将此与来自 VM 主机（Mac）的类似调用进行比较：

$ curl -V
curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1
Release-Date: 2021-09-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

$ curl -vvv -sfL https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/sha256sum-amd64.txt
*   Trying 192.30.255.112:443...
* Connected to github.com (192.30.255.112) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256
[...]
< HTTP/2 302
[...]
* Connection #0 to host github.com left intact
* Issue another request to this URL: 'https://objects.githubusercontent.com/github-production-release-asset-2e65be/135516270/546bdb42-d049-41b6-89f8-6595cecb44cf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20221128%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20221128T223206Z&X-Amz-Expires=300&X-Amz-Signature=cf2a257721dc3cd0955a4e32c5b58074340ad6c305101d1338e5f186d64c68a2&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=135516270&response-content-disposition=attachment%3B%20filename%3Dsha256sum-amd64.txt&response-content-type=application%2Foctet-stream'
*   Trying 185.199.111.133:443...
* Connected to objects.githubusercontent.com (185.199.111.133) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
[...]
< HTTP/2 200
[expected output]
* Connection #1 to host objects.githubusercontent.com left intact

在同一个网络上，使用基于 Debian 的 Raspberry Pi 进行类似调用也得到了类似的成功输出（一个值得注意的变化 -* (304) (OUT/IN), TLS handshake, ...)行变成了TLS v1.[0-3]，就像不成功的情况一样）

比较这两者时值得注意的是：

第一次请求的 TLS 协商步骤顺序在成功和失败的情况下有所不同 - 成功的情况会跳过Certificate Status一些Supplemental data步骤
IP 地址objects.githubuserconcent.com不同 - 但nslookup objects.githubusercontent.com表示185.199.[108-111].133都是预期的 IP

调试和调查

我已尝试/调查过解决此问题的方法：

我确实考虑过降级虚拟机上的版本curl以匹配主机（和 Debian Pi）上的版本，但apt-cache madison curl没有显示任何旧版本，无论如何，我在其他问题/论坛上看到了几个反对降级 curl 的警告
我再次检查了 DigiCert Root CA 是否存在于/etc/ssl/certs
我曾经openssl s_client检查过我的虚拟机是否可以连接到目标域：

$ openssl s_client -connect objects.githubusercontent.com:443
CONNECTED(00000003)

我尝试直接卷曲objects.githubusercontent.com网址（带和不带-k） - 在 TLS 协商中挂在同一个地方
我尝试明确设置允许的密码集（curl -vvv -sfL --ciphers "AES128-SHA256:AES256-SHA384" https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/sha256sum-amd64.txt）- 行为相同
我确实认为我的 OPNSense 路由器上的防火墙可能会阻止 TLS 协商的传入部分 - 但是，我怀疑这种情况不太可能发生，因为：
- 我查看了防火墙的“实时日志”，测试期间没有阻止来自 185.199.* 的请求
- 直接 curl objects.githubusercontent.comurl 会失败，因此与重定向相关的异常情况没有发生
- 我怀疑 Multipass 本身的防火墙存在问题，否则链接的文章会提到它
我尝试使用wget，但似乎在同一个地方失败了：

$ wget https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/sha256sum-amd64.txt
--2022-11-28 15:11:34--  https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/sha256sum-amd64.txt
Resolving github.com (github.com)... 192.30.255.112
Connecting to github.com (github.com)|192.30.255.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/135516270/546bdb42-d049-41b6-89f8-6595cecb44cf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20221128%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20221128T231137Z&X-Amz-Expires=300&X-Amz-Signature=4e96a7bf7f4ed5be5caa64f54fa653d584b089d15226cfa33131897eff9e7c39&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=135516270&response-content-disposition=attachment%3B%20filename%3Dsha256sum-amd64.txt&response-content-type=application%2Foctet-stream [following]
--2022-11-28 15:11:38--  https://objects.githubusercontent.com/github-production-release-asset-2e65be/135516270/546bdb42-d049-41b6-89f8-6595cecb44cf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20221128%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20221128T231137Z&X-Amz-Expires=300&X-Amz-Signature=4e96a7bf7f4ed5be5caa64f54fa653d584b089d15226cfa33131897eff9e7c39&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=135516270&response-content-disposition=attachment%3B%20filename%3Dsha256sum-amd64.txt&response-content-type=application%2Foctet-stream
Resolving objects.githubusercontent.com (objects.githubusercontent.com)... 185.199.109.133, 185.199.108.133, 185.199.110.133, ...
Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|185.199.109.133|:443... connected.
[...hangs...]

我注意到有一些已知会干扰 Mac 上的 Multipass 的工具包括 OpenVPN（我正在使用），但我没有思考这里就是这种情况，因为 DNS 解析和 ping 工作正常。不过，我对本页的解读不太确定，所以请随时纠正我。

编辑：我发现这个类似的问题- 我正在按照那里的步骤进行。

答案1

关闭我的 OpenVPN 解决了这个问题。不过，我会保留这个问题，直到我找到解决方法，因为这不是一个非常令人满意的解决方案。

编辑：正如@Steffan 指出的那样，这是由于 MTU 不匹配造成的 - 我的 Multipass 接口有（标准）MTU=1500，但我的 VPN 使用的是 1420。我为我的家庭网络设置了第二个 VPN，用它将我的第一个 VPN 重新配置为 MTU=1500，现在一切都按预期工作（在我的第一个 VPN 上）。

斯蒂芬，如果你想将此作为答案提交，我很乐意接受它并给你积分。

概括

细节

调试和调查

答案1

相关内容