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

问一问 VPN 子网该有多大，诚实的答案是：这个问题里可能藏着四个不同的子网。站点 VPN 可能涉及传输端点、编号的点到点隧道路径、受保护的 LAN 前缀，以及在托管网关上由服务商预留的基础设施子网。在某个具体设计里，通常只存在其中一两个。按办公设备数量来测算，就是让方案最终落到一个谁都不满意的 /24 上的原因。

分配之前先给四种角色命名

传输端点是两台网关跨越互联网或专线相互到达时使用的地址，其数量来自网关与冗余模型，而不是局域网。内部隧道路径只存在于设计为点到点接口编址的场合，基于策略的 IPsec 配置通常不会这样做。受保护前缀是必须可路由的真实办公网或 VPC 网段，而服务商预留的子网属于托管服务。

在新增任何内容之前先盘点已有的地址，因为这里代价最高的错误是复用一段已在别处路由的前缀。一个试点项目遗留的旧隧道就足以毁掉整份方案。把盘点结果连同日期记下来，因为对已下线链路的记忆往往比链路本身活得更久。

ip -br addr show
ip route show | head -40

这两条命令给出已连接网络的本地视图，以及通往其之外一切的路由。每个站点都要重复盘点，因为只按一个站点的输出做方案，必然与下一个站点冲突。在分配任何一个地址块之前，先把这些输出收集齐。

计链路与拓扑，而不是设备数量

有八个点到点邻接关系的设计会消耗八个地址块，而不是一个。在 /30 下，每个块要用四个地址来连接两台主机，于是方案为十六个可用端点准备了三十两个地址，这才是预算必须容纳的数字。支持 /31 链路的平台只需一半，但前提是两端与服务商都同意该模型。预算宁可向上取整也不要向下取整，因为日后缩小地址块意味着要给在用的链路重新编号。

服务商的限制优先于一般做法。有文档记载的内部隧道地址段即使在你的路由器上 /31 可用时也可能要求 /30，托管网关也可能为其自身子网指定特定掩码。在套用从别的平台借来的经验规则之前，先读服务要求。

多点覆盖层会再次改变算术：每台网关一个地址，由覆盖层负责它们之间的可达性。在把站点数乘以块大小之前，先确定实现到底采用哪种拓扑。

增长值得在方案里单独占一行。预留一段连贯的基础设施地址是合理的，记录其中包含哪些更小的分配同样合理，以免下一位工程师把这份预留读成单一广播域。

把网关子网排除在 LAN 地址池之外

托管网关的基础设施不是客户端地址池。预留网关子网中的地址承载服务自身的组件，远程办公人员从不会从中取用。用用户数来测算这段子网属于类别错误，结果要么浪费一大段地址，要么让网关无地址可用。

云上 VPN 连接的隧道地址段同理：服务商为每条隧道分配一小段内部地址供自己使用。那段地址不是你分支服务器所在之处，也不由你分发。

aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table

列出外部地址可以确认服务商分配了什么，以及当前哪条冗余隧道处于活动状态。这比读一份在连接存在之前写下的设计文档更快。

为每个前缀记录角色、归属与增长

一份经得起运维检验的方案会为每个前缀写明它承担的角色、远端由谁分配，以及还剩多少余量。没有归属字段，两个团队会在同一季度分配同一个 /24，冲突只有在隧道建立时才暴露。

让这些地址段远离通过其他隧道进来的家庭与分支前缀，因为地址空间重叠正是常见原因：站点到站点连接协商成功，却什么流量都过不去。

分配内部链路地址并不会宣告其背后的局域网。路由或流量选择器、回程路径与访问规则都是独立的工作项，方案应当如实说明，而不是暗示某个编号接口替你完成了路由。