AWS VPN 的本地 CIDR 与远程 CIDR：哪一边是哪一边？

在 AWS VPN 选项中，LocalIpv4NetworkCidr 是客户侧，RemoteIpv4NetworkCidr 是 AWS 侧。在触碰在线隧道之前，先把两个角色标清楚。

你打开 Site-to-Site VPN 的选项，看到两个标注为本地和远程的 CIDR 输入框，于是伸手去填自己心目中的本地地址：VPC。这与 API 的含义正好相反。在连接选项里，LocalIpv4NetworkCidr 指的是客户网关一侧，RemoteIpv4NetworkCidr 指的是 AWS 一侧，因为连接是从客户网关建立的。控制台从不明说这一点，也没有任何校验会拒绝一次看起来合理的对调。

从 API 调用出发，而不是从控制台标签出发

把连接选项参考文档完整读一遍，注意每个选项都是站在客户网关的角度写的。这不是命名的巧合。隧道是站在你这一侧终结它的设备的角度描述的，所以本地指你的网关背后的网络，远程指 AWS 网关背后的网络。IPv4 和 IPv6 字段都遵循同一条规则。

在动手输入之前，先把两个标签写在便签上：客户侧、AWS 侧。然后把你的地址对应上去。

一个带着角色标注的实例

假设本地前缀是 10.20.0.0/16，VPC 前缀是 10.60.0.0/16。选项的读法正符合角色所示，本地网段填在本地字段里：

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

现在把同一组值交给配置对端设备的人，然后看着陷阱生效。在很多防火墙上，本地指隧道终结的接口，远程指远端，这对 AWS 一侧恰好是反向映射。两个人都可能没错，却造出一条永远建不起来的隧道，因为两套词汇描述的是不同的端点。

在触碰任何设备之前，先用对端的术语在纸上把这个练习重做一遍，两个 CIDR 和两个标签都写上。

默认值不是设计方案

同一份参考文档把 0.0.0.0/0 列为两个 IPv4 字段的默认值，IPv6 也有类似的取值。在已有连接里看到这些值，说明字段从未被收窄过，而不是说明已经配置了互联网出口。路由分发、子网路由表和安全控制仍然决定哪些流量真正能通过；CIDR 值只描述隧道愿意选择哪些网段。

因此，用默认值替换更窄的取值，并不是隧道出问题时可以套用的兼容性技巧。它只是放宽了选择器，其他每一层都保持原样。

对端设备用的是另一套视角

AWS 一侧弄清楚之后，剩下的大部分困惑都在对端配置里。要求填写本地网络和远程网络的设备，是把它自己的接口当作本地，所以你的 VPC 网段要填进它的远程字段，你的本地网段填进它的本地字段。如果它改为成对地要求流量选择器，那就是把两个方向都显式写出来，标签的重要性还不如配对本身。

读设备的字段帮助，而不是字段名称。厂商常常用同样两个词表示三种不同概念。

然后检查两个阶段的隧道状态，因为不匹配的选择器通常表现为第二阶段失败，而第一阶段依然安稳地建立着。

把选项当作一次变更，而不是一次文档修改

在运行中的 VPN 上编辑连接选项可能中断服务，所以要把它当作一次维护操作，准备好时间窗口、回滚值和受影响的记录。先记录当前选项，包括两个 CIDR 字段和隧道选项，这样回退是粘贴而不是重建。

变更之后，从 AWS 一侧和对端分别验证：每个网段里的一个源都能到达另一个网段里的目标，两个方向都要验证。单侧的一次 ping 只能证明一个选择器。

最后更新连接文档，把角色写清楚，这样下一个人不必重新发现本地指的是你这一侧。

相关文章