一年后仍能读懂 IPv6 VPN 地址规划的方法

两个问题决定地址规划是否值得存在：哪个前缀属于哪个站点，以及应答如何从该站点返回。一次同时回答这两个问题，维护者不必询问任何人就能改动对端。文档中其余内容都是为了支撑这两个答案。两者都支撑不了的内容只是装饰。

读者在触碰对端之前必须回答什么

压缩让地址看起来整齐，而整齐不是结构。结构是知道提供商委派了哪个地址段、你选了哪一个、哪一个是客户端地址池，以及哪一个位于站点之后。

要为下季度加入、需要新增第二个站点的同事而写。除非条目本身说明，页面上没有任何内容告诉他前缀从何而来。略过这一点，第一次变更就会变成考古。

四个字段让一条记录可被审阅：前缀长度、归属方、流量下一跳去向，以及由哪个组件分发该值。把它们与正在运行的配置对照，任何不一致都会自行浮现。指向上月已删除隧道的下一跳会立刻显得不对，而不是混在其余内容里。

即使其中两个角色今天共用同一前缀，也要分行记录。合并会让后来的拆分读起来像一次新分配，而不是更正。

Entry	Fields to record	Why a reviewer needs it
Endpoint addresses	Prefix, owning side, session initiator	Firewall rules and peer config both read it
Tunnel interfaces	Prefix and length, next hop, interface name	Shows the path a packet actually takes
Client allocations	Pool range, size, distributing component	Shows room left before a redesign
Downstream networks	Prefix, site label, return route	Explains a reply that never arrives

RFC 5952 为地址规定唯一的文本形式：小写、无前导零，最长的一段零组恰好压缩一次。在笔记、工单与变更记录中使用它，两份文档便无需转换即可比较。遇到同一地址两种写法的人会开始寻找并不存在的差异。这里的统一成本很低，却能消除一整类误报。

配置文件遵循自己的规则，而那不是可读性规则。与端口配对的地址即使裸地址不需要括号也必须加括号，而从笔记复制到配置文件会毫无提示地丢掉这一区别。为每个字段写明所用形式，否则规划恰好会造成它本想避免的抄录错误。

两种写法都可以，只要各自标注清楚。正是没有标注的混用招致错误。

重叠比其他错误存活更久，因为在两个站点为同一网段作答之前，一切看起来都正常。给站点打标签，并按照有文档的流程生成本地唯一前缀，而不是照抄示例。

客户端列表从不说明应答往哪个方向走。在隧道承载的对端网段旁记下 LAN 网关的回程路径，记录就能解释一个收到请求却沉默的远端子网。在下机上运行下面的检查，并与记录比对。与 ip -6 route 不一致的规划，是人们会停止阅读的规划。

ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0

可达不等于授权，前缀也从不隐含策略。把预期访问写在其所适用的路由旁边。否则下一位读者会把规划中的地址当成可以访问其背后所有服务的许可。

把每个前缀标为已委派、本地分配或以其他方式路由。凡可能移动的内容，都要写明推动它的流程。然后列出必须同期变更的 DNS 记录与防火墙规则，因为停在路由器上的前缀更新只算完成一半。

变更之后，在编辑文档之前先访问变更触及的每道边界之后的资源。描述上月网络的规划比没有更糟，因为人们信任它。撤回的分配要连同消失日期留在清单里，以免有人误再次发放。机密不写进文件；规划解释网络，而不是打开网络。

把规划存放在变更会被审阅的地方，紧挨它所描述的配置。没人重读的文档腐烂得比它描绘的网络更快。