为 GET VPN 成员选择稳定的注册源地址

有人把组成员注册指向一个环回地址，然后宣布 GET VPN 的不稳定问题已解决。有时确实如此。但环回地址常常只能从成员自身的路由表访问，别处一律不可达，所以承载它的上行链路下一次抖动时，注册仍旧会断。注册地址是控制面上的身份，只有在两个方向都有真实路径时才有意义。有意识地选择它是值得的，而且这比传闻中说的改动要小。

注册地址标识的是什么

在 GDOI 部署中，组成员向密钥服务器注册，并从它那里获得组策略。密钥服务器记录的地址，就是该成员在这段会话中的身份。

这个身份覆盖控制面会话：注册、密钥更新和策略下载。 它不会成为客户流量的源地址，也不会改变哪些接口保护哪些流量。

把两者分开是第一步，因为围绕这项设置的混乱大多来自一种期待：以为改动控制面就能修好数据面上的症状。

环回地址的价值只取决于它的路由

环回地址为成员提供一个逻辑地址，单条物理上行链路故障时它不会消失。在多条路径通往密钥服务器的路由器上，这是实打实的好处。

但它也只是一个地址。如果密钥服务器没有回程路由，注册会像以前一样失败。如果成员路由表只通过一条上行链路到达密钥服务器，那么环回地址是稳定的，路径却不是。

对每一条你希望其存活的上行链路，都要验证双向可达性。只保持管理层面处于 up 的环回地址并不能证明转发可用，故障会表现为密钥服务器不可达，而不是接口问题。把检查写成针对每条上行链路的命令，而不是想当然。这样下一个变更窗口就能从证据出发，而不是从图出发。

把控制面流量与受保护流量分开

Cisco 的 GDOI 绕过指南 记录了注册接口以及注册与绕过处理之间的关系。要阅读你实际运行版本的说明，而不是把某句话当成通用命令。

检查控制路径上的过滤与转换，并确认密钥管理流量没有被意外卷入某条保护策略，而那条策略恰恰依赖它正要获取的组策略。这种循环依赖是让正常部署在策略变更后失效的经典做法。

数据面策略是另一套设计。改变注册的来源，受保护的流量、选择器和绕过规则都留在原处。

在过渡过程中校验身份

变更之前，记录组、选定的注册地址、密钥服务器目的地址、路由上下文和允许的控制路径。经过批准的上行链路变更之后，再次查看密钥服务器上的已注册成员视图，以及成员的控制状态。

你希望看到的是：既定的逻辑端点仍然可达，并且仍按你设计的方式呈现。你不希望看到的是：来自非预期地址的第二次注册——成员条目的重复就是这样产生的。

然后单独测试受保护的业务流量。传输可能成功，而下一次密钥更新却无处可去；注册成功也完全不能说明某条具体流量是否被正确选中并路由。

稳定源地址解决不了的问题

它不会清除此前错误配置遗留的重复成员条目。它不会修复因成员与密钥服务器策略不一致而导致的密钥更新失败。它也撑不住删掉了通往密钥服务器唯一路由的物理路径故障。

它做的是去掉一个变量：上行链路地址变化时，身份不再跟着变。这一点值得拥有，而它只是设计中的一行，不是整个设计。

工作顺序：命名控制路径，选择双向都有路由的地址，确认密钥服务器视图，然后单独测试受保护流量。如果注册仍然失败，那环回地址从来就不是问题所在。