按分配而不是按隐蔽性来选择 VPN 地址空间

看起来不寻常的前缀让人觉得像是摆脱家庭与办公室地址冲突的出路，但通常并不是。IPv4 特殊用途注册表中的每个块都有所有者、用途和存在的理由，只因为它看起来安静就借用一块，只是把冲突挪了位置，而不是消除它。请按顺序执行：先读分配，盘点已经重叠的部分，然后再决定是重新编号、转换还是生成新空间。顺序很重要，因为第三步取决于前两步发现了什么。

借用范围之前先读分配

IANA 的 特殊用途注册表把可重复使用的私有空间与只服务于某一特定技术目的的地址段区分开来。私有使用、共享地址空间、基准测试和文档块在表格里看起来一样，一旦被路由，行为却完全不同。

只在第二个八位组不同的两个前缀并不是同一个块：198.18.0.0/15 带有基准测试保留，而 192.18.0.0/16 没有任何此类保留。仅仅看起来像保留段的数字不会继承它的含义。这种混淆相当常见，值得在它进入防火墙规则之前再看一眼。

产品有时会在协调好的覆盖层内刻意使用特殊地址段，这是它们需要记录在案的设计。这并不会让同一地址段成为无关 LAN 的空白空间。公网空间也不是藏身之处：通往属于他人地址的私有路由会让原本驶向其合法目的地的流量改道。

盘点你已经拥有的重叠

在选择前缀之前，列出所有将从隧道可达的网络。站点、客户端池、云 VPC 和合作伙伴链路都要计入，而人们往往会忘记合作伙伴链路，直到第一次连接尝试失败。

ip -4 route show table all
ip -6 route show
ip -br addr
ip route get 192.168.1.10

把结果放进一张表，旁边写上每个范围的所有者。你无法说出所有者的范围，就是日后无法重新编号的范围，而正是这份清单把关于「不寻常」前缀的争论变成关于具体数字的决定。它还会告诉你，你试图避免的冲突是真实存在还是想象出来的。

如果远程办公者的家庭网络与办公室 LAN 使用相同的前缀，这种冲突在清单中可见，可以明确处理。这并不能证明基准测试块会是聪明的选择，而这样处理恰恰会制造下一次冲突。

生成唯一的 ULA，而不是复制前缀

IPv6 用另一种机制而不是更漂亮的数字来解决复用问题。RFC 4193 定义了本地分配的、带有伪随机 40-bit 全局标识符的唯一下本地地址，这给了你一个很难与别人冲突的站点 /48。概率很高，但并非绝对，而且 ULA 前缀仍然不提供互联网可达性。

openssl rand -hex 5

十六个十六进制数字是四十位。在前面加上 fd，把它们归入 /48：输出 3f9c1a7b02 会变成 fd3f:9c1a:7b02::/48。每个站点生成一个并记录下来，而不是把同样方便的 fd00::/48 粘贴到每次部署里。

然后确认整条路径真的在说 IPv6。客户端、网关、路由、私有 DNS 和服务策略都必须一致，而给隧道分配前缀并不会让一个只支持 IPv4 的应用开始使用它。

规划你无法消除的重叠

有些重叠是永久的，通常是因为合作伙伴不愿意重新编号，而你也无法强迫他们。这时你要有意识地选择一种受支持的机制：在你这一侧重新编号、使用隔离的路由上下文，或在边界做显式转换。有意识地选择意味着写下你选了哪一种，以及为什么否定了另外两种。将来的变更评审真正会读的正是这段记录。

转换必须保留返回路径，这意味着要同时记录原始前缀和呈现的前缀，并把它们对应到解析到其中的私有 DNS 名称。映射的别名可以让一个连接不再含糊；它并不会让原始地址全球唯一，也经不起第二个重叠合作伙伴而没有第二套映射。

把分配连同它的例外一起写下来

以一份文档收尾，列出每个前缀、其类别、所有者和选择理由。把例外连同其转换或重新编号规则以及批准日期一并加入。把它放在实施它的防火墙规则旁边，而不是放在出事时没人打开的 wiki 里。文档本身就是交付物，而不是它的摘要。

正是这份记录阻止下一位工程师去寻找看起来更奇怪的数字，这也是这个问题每隔几年就以新名字被重新发现的原因。它还让变更评审有具体的东西可以批准，而不是对前缀发表意见。在分配结束时、理由还在眼前时，把它写一次。