用一个 /23 取代两个 /24：协商中到底变了什么

两个相邻的 /24 干净地合并成一个 /23，这种整齐的算术让人以为改动只是表面的。那只是关于地址的算术，而隧道在意的是选择器，它是一种协商要约，并非对网络的描述。更短的那一行可能让同样的流量仍然受保护，也可能保护得比预期更多，或者连一半都覆盖不到，取决于双方愿意接受什么。只有读取实际装入的结果，才能知道这三种情况里发生了哪一种。

人们常合并成一条的三件事

地址集说明哪些主机应当受到保护。编组方式说明这些地址如何被提出：一个选择器还是多个，放在一个关联里还是多个关联里。协商结果说明双方真正装入了什么，而它可能比前两者中的任何一个都更窄。

在变更记录里把它们分开写。一行配置往往藏着三个不同的答案。分不开这三者的评审者，也同样无法批准这次变更。

响应方能对你的汇总做什么

IKEv2 响应方可以把提出的选择器对收窄为它愿意接受的子集，也可以在不存在可接受内容时直接拒绝该要约。它还可以表示额外流量需要另一个关联，而不是塞进这一个。

什么都不接受的响应方会改为返回一个错误，这至少说明要约被拒绝了，而不是被悄悄收窄。

这意味着一次成功的交换只证明双方在某件事上达成了一致，而不是在你列出的每件事上都一致。最初的成功能告知只是读取结果的起点，绝不是结论。被接受的子集可能比一个 /24 还小，于是装入的集合看上去与要约完全不像。

汇总在哪儿悄悄抹掉一条边界

两个 /24 可以有不同的服务规则：一个可能只允许管理协议，另一个允许通用应用。在 IP 层覆盖这两个地址的选择器并不能保住那些规则，汇总只是把边界挪进隧道之后的任何过滤里。汇总之前先按子网列出服务规则，否则这个比较永远不会发生。

协议和端口取值是选择器的一部分，而不是可选的附加项。如果原策略对它们做了限制，汇总后必须带着同样的限制，否则这次变更就是一次披着路由外衣的权限变更。如果限制正是原策略的要点，就在汇总之后把它明确保留下来，并在记录里写明。

按前缀逐个读取结果

变更之后，看的是装入了什么，而不是配置了什么。然后从每个前缀、每个方向各生成一条流，并检查处理它的那个关联所属的计数器。两个前缀在同一个关联上产生流量没有问题；两个前缀里有一个什么都不产生，那才是发现。

用用户实际运行的那个应用来做这件事。从网关上发起的探测所走的路径，与它后面的客户端并不相同，而差别恰恰就是选择器缺陷藏身的地方。本该繁忙的前缀上计数器却是平的，这比任何一行日志都更有说服力，因为它度量的是缺失。

把变更做成可回退的

在新策略从每一种前缀组合都跑过之前，把原策略留在配置里，并记下每条流落到了哪个关联。如果对端在要约变化时会替换关联，那么回退就必须恢复旧的要约，而不只是旧地址。

在窗口打开之前，先和对端的负责人协调。一侧觉得显而易见的汇总，在另一侧可能是不被接受的编组方式，而在变更过程中才发现这一点代价很高。把要约的编组方式书面约定下来，再拿它和交换实际装入的结果对比。把这份约定留在变更工单里，而不是留在下周就消失的聊天串里。