在站点冲突之前规划私有 VPN 地址段

两个都使用 192.168.1.0/24 的站点，各自都能上网，却无法互相访问。网关不会报错；它为这个前缀只安装一条路由，把所有数据包发给最先声明该前缀的对端。握手、加密套件列表或接口度量都不会说明哪个对端是错的。地址规划正是设计里在任何人连接之前就把这件事定下来的部分。

清点每一个必须可达的空间

写下需要路由的地址段，而不只是你正在配置的那些。这包括站点 LAN、VPN 客户端地址池、云子网、管理与带外网络、实验网段，以及用户通常从家里连接的那些网络。出厂就是 192.168.1.0/24 的家用路由器并不是假设，同一个前缀也会出现在酒店和会议场所。清点表是前缀、归属与用途的表格，也是唯一能阻止同一个地址段被发放两次的东西。

把明年预计出现的前缀也加进来，因为只覆盖今天的方案会在第一个新站点上失败。在每一行标明谁能修改它，而不只是谁拥有它。

正是复用让这件事变难：私有空间有限，而每个组织都把 10.0.0.0/8 当成自己的。方案无法保证将来某个访客网络不会落在你的某个前缀上，所以设计必须说明真发生时会怎样。大部分工作由两条规则完成。把客户端地址池放进一个可以汇总的连续区块，并且绝不分配别的团队已经在路由的地址段。其余的一切都是某个人持续维护的记录。

为什么重叠会打败路由表

路由是前缀加下一跳，转发会选择最长匹配的前缀。当两个对端都声明同一个 192.168.1.0/24 时，表里只有一条记录，于是两个站点的流量都从同一条隧道出去。第二个站点并没有配错；它不可达，是因为第一个站点替同样的地址应答了。没有任何度量能把它们分开，因为匹配发生在查看度量之前。

故障是不对称的，也很容易被误读。A 站点的主机能到网关和部分服务，B 站点的主机却什么都不应答，而日志显示两个方向的隧道都健康。这种模式是地址冲突，不是认证或防火墙故障，确认它需要把一次路由表转储与清点表对照。

有意识地规划客户端池与站点地址段的规模

VPN 客户端池是网关一次发一个地址的地址段，所以它的大小决定了并发上限。/24 有 254 个可用地址，对小团队很宽裕，对跑容器的分支却很紧张；/22 在私有空间里不额外花钱，还能省掉争论。让池保持连续，并与每个站点 LAN 都错开，这样通往客户端的汇总路由永远不会把站点吞进去。即使池是空的也要预留这个地址段，因为没写下来的段正是下一位工程师会分配的那一段。

站点按预期主机数加增长来定地址段大小，并对齐到能干净汇总的边界。分配之间留出的空隙不花钱，还换来以后聚合的余地。

然后检查人们常忘的方向：回程。每个站点路由器都需要一条到客户端池的路由，而集中器需要到它所服务的每个站点前缀的路由。一张没有回池路径的整齐前缀表仍然是坏设计，症状是单向连接、什么都不应答。把两个方向放在同一张表里，并在新增站点时复查。

地址转换与重新编址解决的是不同问题

当重叠已经存在时，有两个诚实的选项和一个不诚实的选项。重新编址永久消除冲突，代价是一次维护窗口，加上每一个你忘掉的硬编码地址。地址转换把一侧的私有段在隧道边缘映射成另一段，两个站点都不用动，但会增加状态、破坏内嵌地址的协议，还让日志更难读。不诚实的选项是到单台服务器的主机路由，它能通过一项测试，其余全都不行。

按可控性和寿命来选。你自己拥有、能排期的站点走重新编址这条路；你碰不得、只为一个应用服务的合作方网络，可以考虑在文档化映射的前提下做转换。把那份映射写下来，因为只存在于配置文件里的转换，会在文件被替换的那一刻消失。

部署前从远端测试

从不托管网关的网络测试，因为网关自己的 LAN 会掩盖大多数路由错误。把客户端接在普通家用路由器后面，然后访问每个站点上的一个服务，以及客户端池内部的一个服务。也要测反方向，从站点主机到客户端，因为回程是独立失败的。只 ping 网关的测试只能证明隧道是通的，别的什么都证明不了。

把地址段、归属和转换映射放在一份共享记录里，下一个站点在分配任何东西之前先读它。新增站点时复查，并把没有文档的地址段当作缺陷，而不是意外。

这份记录本身就是交付物。活在三个人记忆里的方案，在其中一个休假时第一次就会失效，而生产环境里发现的重叠，代价比那张表高得多。