区分 IKEv2 分片与证书链问题

隧道在办公网络里能用，回到家却卡住，日志显示第一次交换已经完成，之后就再没有任何动静。这种模式指向的是认证交换，而不是凭据：证书链会让那条消息比上一条大得多，而一条不喜欢大报文的路径会把它悄悄丢掉。这里涉及两种不同的分片机制，搞清楚你面对的是哪一种，才能决定怎么修。

两种分片机制，一个症状

IKEv2 有自己的分片扩展，定义在 RFC 7383 中，它把受保护的 IKE 消息拆成更小的 IKE 消息。双方会协商这一能力，消息由 IKE 实现而不是 IP 层重新组装。

普通的 IP 分片是另一种机制，失效方式也不同。双方之间的路由器会把大报文分片，或者直接丢弃，并回送一条可能永远到不了发送方的 ICMP 消息。有些网络会静默丢弃分片，有些中间设备只处理第一个分片，不管其余部分。从应用的角度看，这三种情况看起来一模一样。

NAT 穿透又带来第三个变量，因为此时 ESP 被封装进 UDP，外层报文变大，却仍然像 4500 端口上的普通 UDP 流量。一条能顺利放行 UDP 的路径，仍可能在放不下的报文上失败。

读那次失败的交换

要找的是转折，而不是错误。日志显示第一次交换已发送并得到回应，之后什么都没有，那就说明下一条消息从未完成。临时提高日志级别，比较双方报告的报文大小。

你要确认的是应答方到底有没有看到请求。如果发起方发了东西，而应答方没有任何记录，问题出在投递上。如果应答方解析了请求并拒绝了它，问题就在证书本身，分片只是干扰项。这个区分比一整页超时消息都值钱。

改路径，别改证书

用同一个客户端、同一张证书和同一份配置，从另一个网络再试一次。手机热点通常是最便宜的备用路径，而且它和办公线路是真正不同，而不是名义上不同。

如果第二条路径上握手能完成，证书链就是好的，第一条路径才是变量。如果两边都以同样的方式失败，就别再换网络，直接看消息本身。这一次比较就能排除掉大约一半的可能解释。

动手之前先测量交换

先拿到链的大小和路径的大小。这两个数字都约束着握手能发什么，而且都很容易测：

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

前两条给出证书数量和文件大小，这能合理估计认证消息会有多大。ping 探测报告这个大小的报文能否通过路径，接口计数器则显示你这一端有没有丢弃分片。在 Windows 上，等效的探测是带 do-not-fragment 标志并明确指定载荷大小的 ping。

从大往小反复探测，直到成功。能通过的最大尺寸就是这条路径的实际预算，它比任何公开的默认值都有用。

修真正出问题的那一层

如果路径会丢弃大报文，就在双方都启用 IKE 分片，并确认扩展是被协商过的，而不只是被提出过。如果路径在 IP 层处理分片很糟，那修复该落在那里，或者落在外层接口的 MTU 上，而不是证书存储里。

如果证书链不必要地长，就把它精简到对端真正需要的中间证书。删掉客户端本来就信任的根证书是合理的收拾；删掉中间证书就不是，而为了缩小消息去关闭校验，等于拿投递问题换安全问题。

写下你改了哪种机制，以及之后的握手是什么样子。下一次通常发生在另一条网络上，症状却一样，而这条笔记正是把两小时变成十分钟的东西。