为什么点到站点连接需要基于路由的 Azure VPN 网关

基于策略的网关建立的 IPsec 隧道由流量选择器选定，它没有可供交接客户端路由的接口。点到站点是一项路由功能：网关拥有客户端地址池，并在虚拟网络中为这些客户端安装路由。正是这种不匹配，使门户不显示添加它的选项。现有网关上没有任何开关能生成该接口，因此这次变更是替换，而不是修改配置。

顺序比单个步骤更重要。顺序错了，站点到站点的中断就会拖过维护窗口。

基于策略的网关实际做什么

基于策略的网关把数据包与连接上配置的流量选择器进行匹配，并把匹配项送入单一隧道。它没有带地址的隧道接口，虚拟网络中任何地方也不会出现按客户端划分的路由。路由表只是获得指向该网关的本地前缀。对于两个固定地址空间之间的站点到站点连接，这种模型已经足够。

基于路由的网关则相反：它提供隧道接口，由路由决定什么进入该接口。点到站点，以及任何对端集合会发生变化的设计，都依赖这一接口的存在。

为什么客户端地址池需要该接口

笔记本电脑连接时，网关从点到站点地址池中为其分配地址。随后虚拟网络需要一条路由，说明该地址可通过网关到达。没有隧道接口，就没有东西可以挂接这条路由。

地址池来自你指定的范围，网关从中分配。如果该范围与本地网络或对等虚拟网络重叠，冲突只会在客户端连接之后才出现，而那并不是发现它的好时机。请在迁移开始前预留好地址池。

类型也不是按连接设置的。一个网关只有一种类型，它承载的每条连接都据此工作，因此混合设计需要第二个网关，而不是第二条连接。

类型在创建时固定

Microsoft 指出，虚拟网络网关在部署后无法在基于策略与基于路由之间更改。既没有转换命令，也没有门户开关。在同一子网中创建第二个网关同样不是变通办法，因为 Azure 每个虚拟网络只允许一个网关。因此迁移就是删除、重建、重新连接。

这也把 SKU 的决策并入同一次构建。以后再换到更大的 SKU，就是又一次网关替换和又一次中断。

一个网关，一个 GatewaySubnet

网关位于名为 GatewaySubnet 的子网中，且该子网只容纳一个网关。该子网的大小规划属于准备工作，因为更大的 SKU 需要更多地址，而子网之后无法缩小。动手之前，请记录当前的站点到站点设置、共享密钥、本地网络网关和有效路由。然后把维护窗口当作中断来处理，因为在新连接配置完成之前，站点到站点隧道一直处于断开状态。

把中断控制在有限范围内的重建顺序：创建基于路由的网关，重建到同一本地网络网关的站点到站点连接，确认隧道和一次主机到主机的请求，然后才添加点到站点并生成新的客户端包。

替换不能解决的问题

第二项限制属于对端，而不属于 Azure。基于策略的本地设备只能到达它所连接的那个虚拟网络，无法通过同一网关转到其他本地网络或其他虚拟网络。替换 Azure 一侧并不能改变对端能够选择的范围。

如果需求确实是站点之间的互通，答案是基于路由的对端设备，或者让每个目的地各自终结的拓扑。在承诺日期之前先把这一点定下来，因为仅靠替换网关无法实现。

操作与检查的顺序

逐项验证每种能力。先看站点到站点隧道状态和一次主机到主机请求，再看一次点到站点连接和一个专用资源，最后看设计所声称的任何互通路径。网关状态显示绿色只能证明安全关联已建立，别的什么都证明不了。保持这个检查顺序，失败时才能指向引入它的那个阶段。

任何拓扑变更之后都要重新生成客户端包，并让地址池避开所有本地和对等范围。相关限制与 SKU 差异汇总在 Azure VPN Gateway 设置参考中。