如何为多站点 VPN 规划地址空间

VPN 子网该有多大，在你说明统计的是哪些地址之前没有答案。在一种设计里，这些地址是一条编号隧道链路的两端；在另一种里，是策略型隧道背后的办公 LAN；在第三种里，是受管网关预留的基础设施。三个对象、三份预算，而多数规模错误都来自拿一列的数目去填另一列。

四种角色，四个不同的问题

外部传输是对方连接到的地址，因此其规模取决于你的公网地址规划或提供商的规定，绝不取决于其背后的设备数量。内部隧道链路只存在于为虚拟接口编号的设计中，那里的数量取决于拓扑的相邻关系。受保护 LAN 前缀取决于真实网络及其增长计划。提供商预留的基础设施取决于受管服务文档写了什么。

其中只有第三项与办公室有多少台笔记本电脑有关。正是这一个混淆解释了大部分争论。

在打开计算器之前，把四种角色写成彼此独立的列。每列都有自己的配额、负责人和增长假设，谁也不继承别人的规模。当设计中没有编号的内部链路时，那一列是空的，而不是很小；空列是值得为下一位评审记录的事实。

数块：一个 /30 的真实成本

点到点链路需要两个地址，并占用一个大小取决于平台的块。一个 /30 容纳四个地址，其中通常两个可用，因此十二条链路在规划中占用四十八个地址，却只提供二十四个端点。一个 /31 容纳两个地址，两个都可用，这能把算术减半，但仅限两端都接受的地方。

RFC 3021 定义了两地址模型，是否支持取决于两端和服务，而不是良好的意愿。提供商 API 可能在内部隧道选项上强加自己的掩码要求，而通用 RFC 并不能推翻已成文的限制。在汇总预算之前先核对你的平台写了什么，因为四十八个地址与二十四个地址的差别决定了规划能否装进预留范围。请把算术做出来，而不是在漫长一天的末尾相信它。

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

只有在拓扑确定之后才做乘法。十二条独立链路和一个有十二个参与者的多点叠加，在同样的站点数下给出的总数相差很大。

受管网关子网不是客户端地址池

受管服务常常为自己的网关基础设施预留一个子网，该子网由服务消耗，而不交给客户端。它有成文的大小，有时还有成文的名称，并且与接入用户数没有关系。把它当作远程机器的地址池，会做出一个在第一个忙碌清晨就耗尽的方案。

把提供商的要求读作固定成本，就像对待一个机架单元。它不属于受保护前缀的预算。

同样的读法也适用于名称。一个成文用途是网关基础设施的子网，在该服务中按惯例就是基础设施；为了迁就自己的编号方案而改名，只会破坏部署，而不是改进图面。保留提供商的名称和大小，把你自己的编号方案花在你控制的部分上。

把方案写下来，让它能活过第二个站点

只活在一个工程师脑子里的方案，会在办公前缀与家庭路由器默认网段第一次重叠时失败。公布各项配额及其负责人，并说明每条链路哪一端分配哪个地址。 路由或选择器仍然必须被通告，因为给内部链路编号本身并不会发布 LAN。

记录每个块背后的增长假设，因为这部分是后来的读者无法仅凭地址重建的。

然后用棘手的情形检验方案：带着你已在使用的前缀到来的站点、远端由别人管理的链路，以及提供商要求与你记录的第一次不同的区域。如果其中任何一项迫使重新设计，你手上就是一张图，而不是一项策略。能活过它们的方案短到可以放在仓库里隧道配置的旁边，而下一批人恰恰会去那里找它。