对等互连的 Azure VNet 需要自己的 VPN 网关吗？

新的 spoke VNet 出现了，hub 已经有可用的站点到站点网关，显而易见的问题是：是否必须为第二个网关付费。通常不需要：网关传输让 spoke 通过对等互连使用 hub 的网关。三个条件决定这是否可行，而它们都不会显示在对等互连状态徽章上。对等互连的连通性与使用他人网关的权限是两项独立设置，因此两台已经能互相 ping 通的 VM 并不能证明 VPN 路径可用。

第一个条件：网关，以及 spoke 没有自己的网关

Azure 对除 Basic 以外的 VPN Gateway SKU 支持网关传输，区域对等互连和全局对等互连都能承载它。spoke 使用的是自己并不拥有的网关，因此不能再有自己的网关：如果 spoke 中已经存在网关，或已经选择了远程网关选项，你想要的那项传输设置就会不可用或无效。在调试任何东西之前先检查这一点，因为复选框变灰是症状，不是故障。先读取 SKU 和现有网关，然后再看对等互连设置。

在弄清有哪些依赖之前，不要为了显示该选项而删除现有 spoke 网关。迁移顺序比复选框更重要。

第二个条件：每个对等互连方向各需要一项设置

对等互连是两个对象，每个 VNet 上一个，而传输设置分别位于这对对象的两侧。hub 指向 spoke 的对等互连必须允许 hub 网关为 spoke 服务；spoke 指向 hub 的对等互连必须接受 hub 的网关。Microsoft 的网关传输指南按方向分别命名，这也是唯一能记清的方式：

标有 remote 的控件会随你编辑的是哪个 VNet 的对等互连而改变含义，所以要读方向，而不是读那个词。两侧都设置好，保存，并确认两处的对等互连都报告已连接。

第三个条件：地址空间与权限边界

传输无法让同一个目标前缀代表两个网络，因此 hub、spoke 和本地网络的网段必须在这一切生效之前互不重叠。VNet 还可能位于不同的订阅或不同的租户中；这不是禁止，但创建或更新每条对等互连的身份需要在该网络上具备所需权限。跨订阅的更改常因权限失败，而这个错误很容易被误读为拓扑问题。

在更改之前写下网段和负责人。对其中任何一项靠猜，都会得到一条能连上却不路由任何流量的对等互连。

用有效路由验证，而不是用对等互连状态

查看 spoke 工作负载网络接口上的有效路由，找到实际的本地前缀。检查子网的路由表，以及是否已禁用网关路由传播，因为用户定义路由或检查设备可能覆盖对等互连标志所暗示的路径。然后确认另一个方向：本地网络必须知道如何通过站点到站点连接到达 spoke 前缀，无论是通过学习到的通告，还是通过显式路由和客户设备上匹配的受保护网络条目。如果任一侧缺少该前缀，需要改的都不是对等互连标志。

从 spoke 工作负载测试一项服务并跟踪回复。从 VPN 网关或从 hub 的 VM 测试，走的是不同的源前缀和不同的路径。

如果拓扑还服务于点到站点客户端，请单独验证它们已安装的路由。拓扑变更后，Windows 客户端包可能需要重新生成，而这是客户端路由的任务，并不能说明网关共享失败。

共享网关不会带来的东西

网关传输是一种路由便利，而不是授权。网络安全组、本地过滤器和服务级规则仍然决定 spoke 工作负载能到达什么，因此应启用具体的源到目标服务，而不是假设共享隧道允许其背后的一切。

对等互连也不是人们期望的那种可传递关系。 再添加一个 spoke 或一个专用终结点，会带来现有传输设置并未涵盖的路由和访问要求。