Azure 虚拟 WAN是一种网络解决方案，使用它可以轻松地创建复杂的网络拓扑：它包含通过点到站点 VPN、站点到站点 VPN、ExpressRoute 和集成的 SDWAN 设备在 Azure VNet 与本地位置之间跨 Azure 区域路由，包括保护流量的选项。 在大多数方案中，不需要对虚拟 WAN 内部路由的工作原理有深入了解，但在某些情况下，了解虚拟 WAN 路由概念会很有用。
本文档将探讨示例虚拟 WAN 方案，这些方案将解释组织在复杂网络中互连 VNet 和分支时可能会遇到的一些行为。 本文中显示的方案绝不是设计建议，它们只是为演示某些虚拟 WAN 功能而设计的示例拓扑。
方案 1：具有默认路由首选项的拓扑
本文中的第一个方案将分析具有两个虚拟 WAN 中心的拓扑：ExpressRoute、VPN 和 SDWAN 连接。 每个中心中都有直接连接的 VNet（VNet 11 和 21）和通过 NVA 间接连接的 VNet（VNet 121、122、221 和 222）。 VNet 12 通过 BGP 与中心 1 交换路由信息（请参阅 BGP 与虚拟中心对等互连），VNet 22 配置了静态路由，以便可以显示两个选项之间的差异。
在每个中心中，VPN 和 SDWAN 设备都具有双重用途：一方面，它们播发自己单独的前缀（10.4.1.0/24 通过中心 1 中的 VPN，10.5.3.0/24 通过中心 2 中的 SDWAN），而另一方面，它们播发与同一区域中的 ExpressRoute 线路相同的前缀（中心 1 中为 10.4.2.0/24，中心 2 中为 10.5.2.0/24）。 这种差异用于演示虚拟 WAN 中心路由首选项的工作原理。
所有 VNet 和分支连接都是关联的并传播到默认路由表。 尽管中心是受保护的（每个中心中都部署 Azure 防火墙），但它们未配置为保护专用或 Internet 流量。 这样做将导致所有连接都传播到 None 路由表，这将从 Default 路由表中删除所有非静态路由，并破坏本文的目的，因为门户中的有效路由边栏选项卡将几乎为空（将流量发送到 Azure 防火墙的静态路由除外）。
重要说明
上图显示了两个受保护的安全虚拟中心。 路由意向支持此拓扑。 有关详细信息，请参阅如何配置虚拟 WAN 中心路由意向和路由策略。
现成的虚拟 WAN 中心将彼此交换信息，从而实现跨区域的通信。 可以检查虚拟 WAN 路由表中的有效路由：例如，下图显示了中心 1 中的有效路由：
然后，这些有效路由将由虚拟 WAN 播发到分支，并将这些路由注入到连接到虚拟中心的 VNet 中，从而不需要使用用户定义的路由。 检查虚拟中心中的有效路由时，“下一个跃点类型”和“源”字段将指示路由来自何处。 例如，“虚拟网络连接”的“下一个跃点类型”指示前缀在直接连接到虚拟 WAN 的 VNet（上面的屏幕截图中的 VNet 11 和 12）中定义
VNet 12 中的 NVA 通过 BGP 注入路由 10.1.20.0/22，正如下一个跃点类型“HubBgpConnection”所暗示的（请参阅 BGP 与虚拟中心对等互连）。 此汇总路由涵盖间接分支 VNet 121 (10.1.21.0/24) 和 VNet 122 (10.1.22.0/24)。 远程中心中的 VNet 和分支可见具有下一个跃点 hub2，在 AS 路径中可以看到，自治系统编号 65520 已两次预置到这些中心间路由。
在中心 2 中，有一个集成的 SDWAN 网络虚拟设备。 有关此集成支持的 NVA 的更多详细信息，请访问关于虚拟 WAN 中心内的 NVA。 请注意，到 SDWAN 分支 10.5.3.0/24 的路由有下一个跃点 VPN_S2S_Gateway。 这种类型的下一跃点目前可以指示来自 Azure 虚拟网络网关的路由或来自中心中集成的 NVA 的路由。
在中心 2 中，10.2.20.0/22 到间接分支 VNet 221 (10.2.21.0/24) 和 VNet 222 (10.2.22.0/24) 的路由安装为静态路由，如源 defaultRouteTable 所示。 如果签入中心 1 的有效路由，该路由不存在。 原因是静态路由不通过 BGP 传播，但需要在每个中心中配置。 因此，中心 1 需要静态路由才能在中心 1 中的 VNet 和分支到中心 2 中的间接支路 (VNet 221 和 222) 之间提供连接：
添加静态路由后，中心 1 还将包含 10.2.20.0/22 路由：
方案 2：Global Reach 和中心路由首选项
即使中心 1 知道来自线路 2 (10.5.2.0/24) 的 ExpressRoute 前缀并且中心 2 知道来自线路 1 (10.4.2.0/24) 的 ExpressRoute 前缀，来自远程区域的 ExpressRoute 路由也不会被播发回到本地 ExpressRoute 链接。 因此，ExpressRoute 位置需要 ExpressRoute Global Reach 才能相互通信：
重要说明
上图显示了两个安全虚拟中心，路由意向支持此拓扑。 有关详细信息，请参阅如何配置虚拟 WAN 中心路由意图和路由策略。
如虚拟中心路由首选项中所述，虚拟 WAN 默认首选来自 ExpressRoute 的路由。 由于路由从中心 1 播发到 ExpressRoute 线路 1，从 ExpressRoute 线路 1 播发到线路 2，从 ExpressRoute 线路 2 播发到中心 2（反之亦然），虚拟中心现在将首选此路径而不是更直接的中心间链接。 中心 1 中的有效路由显示：
如在路由中所见，ExpressRoute Global Reach 会在将路由发送回 Azure 之前多次预置 ExpressRoute 自治系统编号 (12076)，以降低这些路由的可取性。 但是，ExpressRoute 的虚拟 WAN 默认中心路由优先级在进行路由决策时会忽略 AS 路径长度。
中心 2 中的有效路由将类似：
路由首选项可以更改为 VPN 或 AS 路径，如虚拟中心路由首选项中所述。 例如，可以将首选项设置为 VPN。
使用中心路由首选项 VPN，中心 1 中的有效路由如下所示：
上图显示，到 10.4.2.0/24 的路由现在具有下一个跃点 VPN_S2S_Gateway，而使用默认路由首选项 ExpressRoute，则为 ExpressRouteGateway。 但是，在中心 2 中，到 10.5.2.0/24 的路由仍会显示具有下一个跃点 ExpressRoute，因为在这种情况下，备用路由不是来自 VPN 网关，而是来自中心中集成的 NVA：
但是，中心之间的流量仍首选通过 ExpressRoute 的路由。 若要在虚拟中心之间使用更高效的直接连接，可在两个中心上将路由首选项设置为“AS 路径”。
现在，中心 1 中远程支路和分支的路由将具有预期的下一个跃点 Remote Hub：
可以看到，中心 2 的 IP 前缀 (192.168.2.0/23) 仍显示可通过 Global Reach 链接访问，但这不应影响流量，因为不应存在发送到中心 2 中设备的任何流量。 不过，如果两个中心中都有 NVA 在彼此之间建立 SDWAN 隧道，则此路由可能会成为一个问题。
但请注意，10.4.2.0/24 现在优先于 VPN 网关。 如果通过 VPN 播发的路由的 AS 路径比通过 ExpressRoute 播发的路由短，则可能会发生这种情况。 将本地 VPN 设备配置为将其自治系统编号 (65501) 预置到 VPN 路由以降低其可取性后，中心 1 现在会选择 ExpressRoute 作为 10.4.2.0/24 的下一个跃点：
中心 2 将显示类似的有效路由表，其中其他中心中的 VNet 和分支现在显示 Remote Hub 作为下一个跃点：
方案 3：将 ExpressRoute 线路交叉连接到两个中心
为了在通过 ExpressRoute 连接的 Azure 区域与本地位置之间添加直接链接，通常需要以有时描述为“领结”的拓扑将单个 ExpressRoute 线路连接到多个虚拟 WAN 中心，如以下拓扑所示：
重要说明
上图显示了两个安全虚拟中心，路由意向支持此拓扑。 有关详细信息，请参阅如何配置虚拟 WAN 中心路由意向和路由策略。
虚拟 WAN 显示两个线路都连接到两个中心：
回到 ExpressRoute 的默认中心路由首选项，中心 1 中的远程分支和 VNet 的路由将再次显示 ExpressRoute 为下一个跃点。 虽然这次的原因不是 Global Reach，但事实是 ExpressRoute 线路会将它们从一个中心获取的路由播发反弹回另一个中心。 例如，以下是中心路由首选项为 ExpressRoute 的中心 1 的有效路由：
再次将中心路由首选项更改回 AS 路径会将中心间路由返回到在中心 1 与 2 之间使用直接连接的最佳路径：
后续步骤
有关虚拟 WAN 的详细信息，请参阅：
- 虚拟 WAN 常见问题解答