概括
从 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.com
url 会失败,因此与重定向相关的异常情况没有发生 - 我怀疑 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 上)。
斯蒂芬,如果你想将此作为答案提交,我很乐意接受它并给你积分。