背景

在 WireGuard 虚拟网络环境下，我尝试 SSH 连接远程主机时，TCP 连接可以建立，但会话随即卡死。

使用 ssh -v 开启详细调试模式，发现日志停滞在密钥交换（Key Exchange）的最后一步：

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
...
debug1: kex: algorithm: curve25519-sha256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY  <-- 卡死在此处，随后超时

分析

MTU 黑洞 (MTU Black Hole)。

SSH 在密钥交换（KEX）阶段会发送较大的数据包。WireGuard 协议本身会增加头部开销（Overhead）。当 [SSH Payload + TCP/IP Headers + WireGuard Overhead] 的总长度超过物理链路路径上的最小 MTU（通常受限于 PPPoE 拨号或中间路由策略）时，数据包会被静默丢弃。

由于中间链路可能禁用了 ICMP，导致发送端无法收到 “Fragmentation Needed” 通知，从而造成连接“假死”。

解决方案

WireGuard 官方推荐将 MTU 设置为保守值 1280 以适配绝大多数网络环境。