如何在不公开密钥的情况下检查 IPsec 状态

IPsec 状态转储不是状态报告，把它当作状态报告，正是密钥材料流进公开问题跟踪器的方式。有些内核检查输出会带上内核正在使用的流量密钥，以及确实有用的地址、选择器和计数器。安全的习惯是先收集摘要，只有当摘要无法回答问题时才去读原始状态。如果一定要看原始状态，就在本地查看，并且只分享范围更窄的内容。

检查 1：这件产物究竟能不能离开这台机器

配置文件、私钥、不受限制的抓包和原始状态转储，在证明无害之前都是机密。一条会打印密钥的命令，不会因为你为了诊断运行过它，就变得安全。

规则用一句话就能说清：分享回答了问题的观测结果，而不是产生它的机器状态。

检查 2：选摘要命令，而不是状态转储

对 strongSwan 来说，swanctl --list-sas 显示关联摘要：身份、已安装的子 SA、状态和计数器。它不需要原始的密钥转储，也是应该最先粘贴进工单的内容。在内核一侧，iproute2 在记录了该选项的版本上支持 ip xfrm state list nokeys，它会隐藏密钥材料，同时保留关联字段。

依赖它之前，先在本地手册里确认语法，因为这个选项并非每个版本都有，而不带它的通用状态列表是另一条命令，输出也不同。在旧构建上运行 ip xfrm state 看标志是否存在，正是这份清单要谈的错误。

检查 3：只记录调查需要的内容

关联状态、算法、选择器、时间戳、方向和相关的计数器通常就够了。账户身份、公开地址和内部拓扑往往不需要，而且可以在不损失诊断价值的情况下脱敏。

默认脱敏，需要时再补回来。读你工单的人可以再要一个字段；但他没法让已经贴出去的密钥变成没看见过。

有一个值得知道的中间地带：摘要本身也可能是敏感的。身份、对端地址和子 SA 名称描述的是你的拓扑，在某些组织里这本身就是受限信息。粘贴之前先决定读者是谁，并且优先选择有合适访问控制的渠道，而不是公开问题。安全的命令不等于安全的去处。

检查 4：在两端对上同一次尝试

为同一次连接尝试同时抓取客户端和网关，并确认你描述的关联正是那次尝试产生的。把上一次尝试留下的过期子 SA 和新的路由快照混在一起，会得到一份内部自洽却完全误导的报告。

用唯一标识符而不是隧道来指明关联，并记下失败的方向。如果症状是某个方向没有流量，说明是哪个方向，并附上一个无害的测试目的地，让读者能推理路径而不是靠猜。一个方向为零、另一个方向在上升的计数器 比任何密钥转储都更能定位问题。时间戳统一在一个时区，并说明是哪个。

检查 5：材料已经泄露了怎么办

删除附件并不能证明没人保存过它，而公开的粘贴会被迅速复制。

把它当作事件处理，走运营方的更换流程：轮换受影响的密钥或凭据，检查泄露是否意味着更大范围的失陷，并遵循适用的通知路径。技术上的清理是容易的部分；假设没人读过它才是难的部分。

可以长期沿用的做法，是粘贴前先填一张小模板：哪一端、哪个关联标识符、哪个方向、哪个计数器，以及已经排除了什么。swanctl list-sas 文档 描述了摘要中的字段，而这正是大多数工单真正需要的。其余内容按需提供给需要的人。诊断报告应当包含证据，而不是访问权限。