GDOI：为什么密钥服务器不在你的数据路径上

组密钥服务器把策略和密钥分发给成员，成员自己保护流量。这句话听起来只是形式，直到某个设计把控制器当成每个受保护数据包的中转；于是拓扑多出一段本不需要的跳数，流量路径依赖一台只负责分发状态的设备。密钥服务器在哪里、数据流向哪里，是两张不同的图，GDOI 正是围绕这一区别构建的。把它弄反不是小小的建模错误，因为它会改变你监控什么、扩容什么。下面各节遵循协议本身的划分。

两类安全状态

RFC 6407 定义了成员的拉取交换，用于请求策略和密钥材料；也定义了推送交换，向已授权成员分发策略和密钥更新。两者都管理安全关联。它们都不是应用的数据流，所以交换成功只能证明控制通道可用。成员可以干净地注册、持有有效密钥，但如果数据策略有误，仍然无法保护或转发流量。一旦知道哪类交换承载哪种失败，这两种失败就完全不同。

标准还定义了保护密钥更新消息的再密钥安全关联，它与描述成员如何保护流量的数据安全关联相互独立。

跟着交换走，而不是跟着图走

看每条消息是做什么的。注册告诉控制器哪个成员在请求，并建立状态；再密钥告诉成员策略或密钥已经变化；随后受保护的应用流量使用已安装的数据安全关联在成员之间流动。控制器地址出现在前两者中，在第三者里完全不必出现。

这就是为什么 按物理邻接画出的接口图在这里会误导。控制器的接口是控制源，并不自动是每个加密包的下一跳。

值得保留的三份记录

记下成员经过认证的注册以及它能到达的控制源、后续密钥更新的传递路径，以及承载受保护应用流量的路由和接入。三份记录、三个负责人，其中任何一份出问题都会产生不同的症状。注册之后再也收不到更新的成员，看起来与用陈旧策略注册的成员一模一样，除非你同时有两份记录。

把这些记录放在配置旁边，而不是放在某人的记忆里。成员变更并不频繁，等到需要时推理过程早已消失。

接口、服务接入、处理路径

在基于服务的网关上还有一层区别：物理底层地址并不等于本地服务接入，流量如何到达其 IPsec 处理路径由平台实现决定。因为一条错误消息提到服务接口规则，就把服务挪到物理接口上，或加入无关的转换，这是披着修复外衣的猜测。

阅读平台自身的文档，了解服务接入如何接收流量。即使协议是标准的，机制也因厂商而异。

标准化的协议消息也不能建立跨厂商兼容性。在假设两种实现可以互通之前，比较所需特性、策略与关联属性、认证方法，以及确切的平台和版本。

控制可用性与数据转发是两项独立检查

为日常运行、成员变更和密钥更新分别规划控制器的可达性。在已安装状态上成功的应用交换，并不能证明下一次注册或再密钥能到达该成员，而这个缺口通常几小时后才以隧道停止接受新成员的形式出现。要测试全新的注册，而不只是可用的会话。

然后把控制器排除在外，单独测试转发。两项检查、两个结果，关于哪一半坏了的争论会短得多。