我与服务器 (owner-api.teslamotors.com) 建立了 SSL 连接，该连接通过 wget、curl 或 openssl s_client 挂起。我展示的是 curl 版本，因为它提供了最多的调试消息：
# curl -iv https://owner-api.teslamotors.com
* Trying 18.203.70.200:443...
* Connected to owner-api.teslamotors.com (18.203.70.200) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
ClientHello 之后它就挂起了。TCP 连接已成功建立（也已通过 telnet/nc 确认）。其他网络连接（包括我尝试过的任何 SSL 连接）都可以正常工作。除了owner-api.teslamotors.com:443。
我发现这个帖子谈论的是 MTU，听起来有些牵强。但我减少了服务器 MTU，它就起作用了！它适用于任何 <= 1420 的 MTU。
服务器使用以太网 (MTU 1500) 连接到 Mikrotik 路由器，然后从那里通过 WireGuard 隧道 (MTU 1420)。我知道这可能不是最佳选择，因为来自服务器 >1420 的任何 IP 数据包都需要分段。但是，这与任何 L4 协议无关。TCP 上的 SSL 不应该关心分段和 MTU。然而，这个主机关心。
我在 Mikrotik 盒子上运行了数据包捕获，流量没有列出任何异常：
典型的 TCP 握手是第 1-3 次，然后是 ClientHello（第 4-5 次）和 ServerHello（第 6-7 次）。没有数据包大小接近 MTU，也没有其他 ICMP 消息表明存在碎片等问题。
根据评论，以下是 tracepath 输出：
# tracepath owner-api.teslamotors.com
1?: [LOCALHOST] pmtu 1500
1: XX.XX.56.210 0.410ms
1: XX.XX.56.210 0.198ms
2: XX.XX.56.210 0.138ms pmtu 1420
2: XX.XX.56.185 151.394ms
3: no reply
4: 100.100.200.1 157.220ms
5: 10.75.0.193 154.068ms
6: 10.75.2.53 161.950ms asymm 7
7: decix1.amazon.com 152.107ms asymm 8
8: decix2.amazon.com 153.068ms
9: no reply
[...]
我真的不知道这里到底发生了什么。
为什么这个 SSL 连接失败？
