你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
如何配置虚拟 WAN 中心路由意向和路由策略
虚拟 WAN 中心路由意向允许你设置简单的声明性路由策略，以将流量发送到虚拟 WAN 中心内部署的 bump-in-the-wire 安全解决方案，例如 Azure 防火墙、网络虚拟设备或软件即服务 (SaaS) 解决方案。
背景
通过路由意向和路由策略，可将虚拟 WAN中心配置为将 Internet 绑定和专用（点到站点 VPN、站点到站点 VPN、ExpressRoute、虚拟网络和网络虚拟设备）流量转发到虚拟中心部署的 Azure 防火墙、下一代防火墙 (NGFW)、网络虚拟设备 (NVA) 或安全软件即服务 (SaaS) 解决方案。
有两种类型的路由策略：Internet 流量路由策略和专用流量路由策略。 每个虚拟 WAN 中心最多可以有一个 Internet 流量路由策略和一个专用流量路由策略，每个策略都有一个“下一个跃点”资源。 虽然专用流量同时包含分支和虚拟网络地址前缀，但路由策略将它们视为路由意向概念中的一个实体。
Internet 流量路由策略：在虚拟 WAN 中心配置 Internet 流量路由策略时，到该虚拟 WAN 中心的所有分支（远程用户 VPN（点到站点 VPN）、站点到站点 VPN 和 ExpressRoute）连接以及虚拟网络连接都会将 Internet 绑定流量转发到在路由策略中指定的 Azure 防火墙、第三方安全提供程序、网络虚拟设备或 SaaS 解决方案。
换句话说，在虚拟 WAN 中心配置 Internet 流量路由策略时，虚拟 WAN 将向所有分支、网关和网络虚拟设备（部署在中心或分支中）播发默认 (0.0.0.0/0) 路由。
专用流量路由策略：在虚拟 WAN 中心配置专用流量路由策略时，进出虚拟 WAN 中心的所有分支和虚拟网络流量（包括中心间流量）都会转发到下一个跃点 Azure 防火墙、网络虚拟设备或 SaaS 解决方案资源。
换句话说，在虚拟 WAN 中心配置专用流量路由策略时，所有分支到分支、分支到虚拟网络、虚拟网络到分支和中心间流量都将通过虚拟 WAN 中心部署的 Azure 防火墙、网络虚拟设备或 SaaS 解决方案进行发送。
用例
以下部分介绍将路由策略应用于安全虚拟 WAN 中心的两种常见方案。
所有虚拟 WAN 中心都受到保护（部署有 Azure 防火墙、NVA 或 SaaS 解决方案）
在此方案中，所有虚拟 WAN 中心都部署了 Azure 防火墙、NVA 或 SaaS 解决方案。 在此方案中，你可以在每个虚拟 WAN 中心配置 Internet 流量路由策略和/或专用流量路由策略。
以下面的配置为例，其中，中心 1 和中心 2 具有用于专用流量和 Internet 流量的路由策略。
中心 1 配置：
- 使用下一个跃点中心 1 Azure 防火墙、NVA 或 SaaS 解决方案的专用流量策略
- 使用下一个跃点中心 1 Azure 防火墙、NVA 或 SaaS 解决方案的 Internet 流量策略
中心 2 配置：
- 使用下一个跃点中心 2 Azure 防火墙、NVA 或 SaaS 解决方案的专用流量策略
- 使用下一个跃点中心 2 Azure 防火墙、NVA 或 SaaS 解决方案的 Internet 流量策略
下面是这种配置产生的流量流。
注意
Internet 流量必须通过中心内的本地安全解决方案流出，因为默认路由 (0.0.0.0/0) 不会跨中心传播。
| 源 | 功能 | 中心 1 VNet | 中心 1 分支 | 中心 2 VNet | 中心 2 分支 | Internet |
|---|---|---|---|---|---|---|
| 中心 1 VNet | → | 中心 1 AzFW 或 NVA | 中心 1 AzFW 或 NVA | 中心 1 和 2 AzFW、NVA 或 SaaS | 中心 1 和 2 AzFW、NVA 或 SaaS | 中心 1 AzFW、NVA 或 SaaS |
| 中心 1 分支 | → | 中心 1 AzFW、NVA 或 SaaS | 中心 1 AzFW、NVA 或 SaaS | 中心 1 和 2 AzFW、NVA 或 SaaS | 中心 1 和 2 AzFW、NVA 或 SaaS | 中心 1 AzFW、NVA 或 SaaS |
| 中心 2 VNet | → | 中心 1 和 2 AzFW、NVA 或 SaaS | 中心 1 和 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS |
| 中心 2 分支 | → | 中心 1 和 2 AzFW、NVA 或 SaaS | 中心 1 和 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS |
部署安全虚拟 WAN 中心和常规虚拟 WAN 中心
在此方案中，并非 WAN 中的所有中心都是安全虚拟 WAN 中心（其中部署了安全解决方案的中心）。
以下面的配置为例，其中，中心 1（标准）和中心 2（安全）部署在虚拟 WAN 中。 中心 2 具有用于专用流量和 Internet 流量的路由策略。
中心 1 配置：
- N/A（如果中心未部署 Azure 防火墙、NVA 或 SaaS 解决方案，则无法配置路由策略）
中心 2 配置：
- 使用下一个跃点中心 2 Azure 防火墙、NVA 或 SaaS 解决方案的专用流量策略。
- 使用下一个跃点中心 2 Azure 防火墙、NVA 或 SaaS 解决方案的 Internet 流量策略。
下面是这种配置产生的流量流。 连接到中心 1 的分支和虚拟网络无法通过中心部署的安全解决方案访问 Internet，因为默认路由 (0.0.0.0/0) 不会跨中心传播。
| 源 | 功能 | 中心 1 VNet | 中心 1 分支 | 中心 2 VNet | 中心 2 分支 | Internet |
|---|---|---|---|---|---|---|
| 中心 1 VNet | → | 直接 | 直接 | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | - |
| 中心 1 分支 | → | 直接 | 直接 | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | - |
| 中心 2 VNet | → | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS |
| 中心 2 分支 | → | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS | 中心 2 AzFW、NVA 或 SaaS |
已知限制
- 下表介绍了不同 Azure 环境中的路由意向的可用性。
- 路由意向在由世纪互联运营的 Mirosoft Azure 中不可用。
- Palo Alto Cloud NGFW 仅在 Azure 公共中可用。 联系 Palo Alto Networks，了解 Azure 政府中云 NGFW 和 Viacom 运营的 Microsoft Azure 的可用性。
- 网络虚拟设备在所有 Azure 政府区域中均不可用。 请联系 NVA 合作伙伴，了解 Azure 政府的可用性。
| 云环境 | Azure 防火墙 | 网络虚拟设备 | SaaS 解决方案 |
|---|---|---|---|
| Azure Public | 是 | 是 | 是 |
| Azure 政府 | 是 | 受限 | 否 |
| 由世纪互联运营的 Microsoft Azure | 否 | No | 否 |
- 通过管理所有连接（虚拟网络、站点到站点 VPN、点到站点 VPN 和 ExpressRoute）的路由表关联和传播，路由意向可简化路由。 因此，具有自定义路由表和自定义策略的虚拟 WAN 不能与路由意向构造一起使用。
- 如果 Azure 防火墙配置为允许 VPN 隧道终结点（站点到站点 VPN 网关专用 IP 和本地 VPN 设备专用 IP）之间的流量，则配置了路由意向的中心支持加密 ExpressRoute（通过 ExpressRoute 线路运行的站点到站点 VPN 隧道）。 有关所需配置的详细信息，请参阅采用路由意向的加密 ExpressRoute。
- 路由意向不支持以下连接用例：
- defaultRouteTable 中指向虚拟网络连接的静态路由不能与路由意向结合使用。 但是，可以使用 BGP 对等互连功能。
- 使用“静态路由传播”的虚拟网络连接上的静态路由不适用于专用路由策略中指定的下一跃点资源。 在虚拟网络连接上将静态路由应用到专用路由策略下一跃点的支持正在路线图中。
- 目前，在同一虚拟 WAN 中心同时部署 SD-WAN 连接 NVA 和单独的防火墙 NVA 或 SaaS 解决方案的功能已在路线图中。 使用下一个跃点 SaaS 解决方案或防火墙 NVA 配置路由意向后，SD-WAN NVA 和 Azure 之间的连接将受到影响。 可改为在不同的虚拟中心内部署 SD-WAN NVA 和防火墙 NVA 或 SaaS 解决方案。 也可以在连接到中心的分支虚拟网络中部署 SD-WAN NVA，并利用虚拟中心 BGP 对等互连功能。
- 仅当它们是下一代防火墙或双角色下一代防火墙和 SD-WAN NVA 时，才能将网络虚拟设备 (NVA) 指定为路由意向的下一个跃点资源。 目前，checkpoint、fortinet-ngfw 和 fortinet-ngfw-and-sdwan 是唯一有资格配置为路由意向的下一个跃点的 NVA。 如果尝试指定其他 NVA，则路由意向创建将失败。 可以通过导航到虚拟中心 -> 网络虚拟设备，然后查看“供应商”字段来检查 NVA 的类型。 Palo Alto Networks Cloud NGFW 也可作为路由意向的下一跃点，但被视为 SaaS 解决方案类型的下一跃点。
- 对于希望将多个 ExpressRoute 线路连接到虚拟 WAN 并通过中心部署的安全解决方案在它们之间发送流量的路由意向用户，可以提交支持案例以启用此用例。 有关详细信息，请参阅启用跨 ExpressRoute 线路的连接。
虚拟网络地址空间限制
注意
可以调整连接到单个虚拟 WAN 中心的最大虚拟网络地址空间数。 打开 Azure 支持案例来请求增加限制。 这些限制适用于虚拟 WAN 中心级别。 如果有多个需要增加限制的虚拟 WAN 中心，请在虚拟 WAN 部署中请求增加所有虚拟 WAN 中心的限制。
对于使用路由意向的客户，在直接连接到单个虚拟 WAN 中心的所有虚拟网络中，最大地址空间数为 400。 此限制单独应用于虚拟 WAN 部署中的每个虚拟 WAN 中心。 连接到远程（同一虚拟 WAN 中的其他虚拟 WAN 中心）中心的虚拟网络地址空间不计入此限制。
如果连接到中心的直连虚拟网络地址空间数超过限制，则启用或更新虚拟中心的路由意向将失败。 对于已配置路由意向的中心，如果其中虚拟网络地址空间由于操作（如虚拟网络地址空间更新）而超出限制，则新连接的地址空间可能无法路由。
如果所有本地连接的虚拟网络中的地址空间总数超过记录的限制的 90%，或者有任何计划的网络扩展或部署操作将增加超出限制的虚拟网络地址空间数，则主动请求增加限制。
下表提供了示例虚拟网络地址空间计算。
| 虚拟中心 | 虚拟网络计数 | 每个虚拟网络的地址空间 | 连接到虚拟中心的虚拟网络地址空间总数 | 建议的操作 |
|---|---|---|---|---|
| 虚拟中心 1 | 200 | 1 | 200 | 无需执行任何操作，监视地址空间计数。 |
| 虚拟中心 2 | 150 | 3 | 450 | 请求限制增加以使用路由意向。 |
| 虚拟中心 3 | 370 | 1 | 370 | 请求调高限制。 |
可以使用以下 Powershell 脚本来估算连接到单个虚拟 WAN 中心的虚拟网络中的地址空间数。 对虚拟 WAN 中的所有虚拟 WAN 中心运行此脚本。 Azure Monitor 指标，用于跟踪和配置路线图中已连接的虚拟网络地址空间的警报。
请确保修改脚本中虚拟 WAN 中心的资源 ID 以匹配环境。 如果具有跨租户虚拟网络连接，请确保有足够的权限读取虚拟 WAN 虚拟网络连接对象以及连接的虚拟网络资源。
$hubVNETconnections = Get-AzVirtualHubVnetConnection -ParentResourceId "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualHubs/<virtual hub name>"
$addressSpaceCount = 0
foreach($connection in $hubVNETconnections) {
try{
$resourceURI = $connection.RemoteVirtualNetwork.Id
$RG = ($resourceURI -split "/")[4]
$name = ($resourceURI -split "/")[8]
$VNET = Get-AzVirtualNetwork -Name $name -ResourceGroupName $RG -ErrorAction "Stop"
$addressSpaceCount += $VNET.AddressSpace.AddressPrefixes.Count
}
catch{
Write-Host "An error ocurred while processing VNET connected to Virtual WAN hub with resource URI: " -NoNewline
Write-Host $resourceURI
Write-Host "Error Message: " -ForegroundColor Red
Write-Host $_.Exception.Message -ForegroundColor Red
}
finally{
}
}
Write-Host "Total Address Spaces in VNETs connected to this Virtual WAN Hub: " -ForegroundColor Green -NoNewline
Write-Host $addressSpaceCount -ForegroundColor Green
注意事项
对于当前在没有路由意向的虚拟 WAN 中心使用 Azure 防火墙的客户，可以使用 Azure 防火墙管理器、虚拟 WAN 中心路由门户或通过其他 Azure 管理工具（PowerShell、CLI、REST API）来启用路由意向。
在启用路由意向之前，请考虑以下事项：
- 只能在 defaultRouteTable（下一个跃点为虚拟网络连接）中没有自定义路由表且没有静态路由的中心配置路由意向。 有关详细信息，请参阅先决条件。
- 在启用路由意向之前，请保存网关、连接和路由表的副本。 系统不会自动保存并应用以前的配置。 有关详细信息，请参阅回滚策略。
- 路由意向会更改 defaultRouteTable 中的静态路由。 由于 Azure 门户优化，如果使用 REST、CLI 或 PowerShell 配置路由意向，则配置路由意向后，defaultRouteTable 的状态可能有所不同。 有关详细信息，请参阅静态路由。
- 启用路由意向会影响向本地播发前缀。 有关详细信息，请参阅前缀播发。
- 可以提交支持案例，以便通过中心内的防火墙设备启用跨 ExpressRoute 线路的连接。 启用此连接模式会修改播发到 ExpressRoute 线路的前缀。 有关详细信息，请参阅关于 ExpressRoute。
- 路由意向是虚拟 WAN 中唯一的机制，用于通过中心内部署的安全设备启用中心间流量检查。 中心间流量检查还需要在所有中心上启用路由意向，以确保在虚拟 WAN 中心部署的安全设备之间对称路由流量。
- 路由意向将虚拟网络和本地流量发送到路由策略中指定的下一个跃点资源。 虚拟 WAN 对底层 Azure 平台进行编程，以根据配置的路由策略路由本地和虚拟网络流量，不通过虚拟中心路由器处理流量。 由于通过路由意向路由的数据包不由路由器处理，因此无需在配置了路由意向的中心为数据平面数据包转发分配额外的路由基础结构单元。 但是，你可能需要根据连接到虚拟 WAN 中心的虚拟网络中的虚拟机数量分配额外的路由基础结构单元。
- 路由意向允许为专用路由和 Internet 路由策略配置不同的下一跃点资源。 例如，可以将专用路由策略的下一跃点设置为中心的 Azure 防火墙，将 Internet 路由策略的下一跃点设置为中心内的 NVA 或 SaaS 解决方案。 由于 SaaS 解决方案和防火墙 NVA 部署在虚拟 WAN 中心的同一子网中，因此在同一中心部署具有防火墙 NVA 的 SaaS 解决方案可能会影响 SaaS 解决方案的横向可缩放性，因为横向扩展可用的 IP 地址较少。此外，每个虚拟 WAN 中心最多可以部署一个 SaaS 解决方案。
先决条件
若要启用路由意向和策略，虚拟中心必须满足以下先决条件：
- 虚拟中心没有部署自定义路由表。 唯一存在的路由表是 noneRouteTable 和 defaultRouteTable。
- 静态路由不能具有下一个跃点“虚拟网络连接”。 defaultRouteTable 中的静态路由可以具有下一个跃点“Azure 防火墙”。
对于不符合上述要求的中心，用于配置路由意向的选项将灰显。
在 Azure 防火墙管理器中使用路由意向（启用中心间选项）还有其他要求：
- 由 Azure 防火墙管理器创建的路由遵循 private_traffic、internet_traffic 或 all_traffic 的命名约定。 因此，defaultRouteTable 中的所有路由都必须遵循此约定。
回滚策略
注意
从中心完全删除路由意向配置时，与中心的所有连接都将设置为传播到默认标签（适用于虚拟 WAN 中的“所有”defaultRouteTable）。 因此，如果你正在考虑在虚拟 WAN 中实现路由意向，则应保存现有配置（网关、连接、路由表）的副本，以便在你希望恢复到原始配置时进行应用。 系统不会自动还原以前的配置。
通过管理中心中所有连接的路由关联和传播，路由意向可简化路由和配置。
下表介绍了配置路由意向后，所有连接的关联路由表和传播的路由表。
| 路由意向配置 | 关联的路由表 | 传播的路由表 |
|---|---|---|
| Internet | defaultRouteTable | 默认标签（虚拟 WAN 中所有中心的 defaultRouteTable） |
| 私有 | defaultRouteTable | noneRouteTable |
| Internet 和专用 | defaultRouteTable | noneRouteTable |
defaultRouteTable 中的静态路由
以下部分介绍在中心上启用路由意向时，路由意向如何管理 defaultRouteTable 中的静态路由。 路由意向对 defaultRouteTable 所做的修改是不可逆的。
如果删除路由意向，则必须手动还原以前的配置。 因此，建议在启用路由意向之前保存配置快照。
Azure 防火墙管理器和虚拟 WAN 中心门户
在中心上启用路由意向时，将自动在 defaultRouteTable 中创建与配置的路由策略对应的静态路由。 这些路由包括：
| 路由名称 | 前缀 | 下一个跃点资源 |
|---|---|---|
| _policy_PrivateTraffic | 10.0.0.0/8、192.168.0.0/16、172.16.0.0/12 | Azure 防火墙 |
| _policy_PublicTraffic | 0.0.0.0/0 | Azure 防火墙 |
注意
对于 defaultRouteTable 中包含与 0.0.0.0/0 或 RFC1918 超级网（10.0.0.0/8、192.168.0.0/16 和 172.16.0.0/12）不完全匹配的前缀的任何静态路由，它们会自动合并为名为 private_traffic 的单个静态路由。 配置路由意向后，无论策略类型如何，defaultRouteTable 中与 RFC1918 超级网或 0.0.0.0/0 匹配的前缀始终会自动删除。
例如，假设 defaultRouteTable 在配置路由意向之前具有以下路由：
| 路由名称 | 前缀 | 下一个跃点资源 |
|---|---|---|
| private_traffic | 192.168.0.0/16、172.16.0.0/12、40.0.0.0/24、10.0.0.0/24 | Azure 防火墙 |
| to_internet | 0.0.0.0/0 | Azure 防火墙 |
| additional_private | 10.0.0.0/8、50.0.0.0/24 | Azure 防火墙 |
在此中心启用路由意向将导致 defaultRouteTable 出现以下结束状态。 所有不是 RFC1918 或 0.0.0.0/0 的前缀都将合并为名为 private_traffic 的单个路由。
| 路由名称 | 前缀 | 下一个跃点资源 |
|---|---|---|
| _policy_PrivateTraffic | 10.0.0.0/8、192.168.0.0/16、172.16.0.0/12 | Azure 防火墙 |
| _policy_PublicTraffic | 0.0.0.0/0 | Azure 防火墙 |
| private_traffic | 40.0.0.0/24、10.0.0.0/24、50.0.0.0/24 | Azure 防火墙 |
其他方法（PowerShell、REST、CLI）
使用非门户方法创建路由意向会自动在 defaultRouteTable 中创建相应的策略路由，并且还会删除静态路由中与 0.0.0.0/0 或 RFC1918 超级网（10.0.0.0/8、192.168.0.0/16 或 172.16.0.0/12）完全匹配的任何前缀。 但是，其他静态路由不会自动合并。
例如，假设 defaultRouteTable 在配置路由意向之前具有以下路由：
| 路由名称 | 前缀 | 下一个跃点资源 |
|---|---|---|
| firewall_route_ 1 | 10.0.0.0/8 | Azure 防火墙 |
| firewall_route_2 | 192.168.0.0/16、10.0.0.0/24 | Azure 防火墙 |
| firewall_route_3 | 40.0.0.0/24 | Azure 防火墙 |
| to_internet | 0.0.0.0/0 | Azure 防火墙 |
下表表示路由意向创建成功后 defaultRouteTable 的最终状态。 请注意，firewall_route_1 和to_internet 已被自动删除，因为这些路由中唯一的前缀是 10.0.0.0/8 和 0.0.0.0/0。 firewall_route_2 已修改为删除 192.168.0.0/16，因为该前缀是 RFC1918 聚合前缀。
| 路由名称 | 前缀 | 下一个跃点资源 |
|---|---|---|
| _policy_PrivateTraffic | 10.0.0.0/8、192.168.0.0/16、172.16.0.0/12 | Azure 防火墙 |
| _policy_PublicTraffic | 0.0.0.0/0 | Azure 防火墙 |
| firewall_route_2 | 10.0.0.0/24 | Azure 防火墙 |
| firewall_route_3 | 40.0.0.0/24 | Azure 防火墙 |
向本地播发前缀
以下部分介绍在虚拟中心上配置路由意向后，虚拟 WAN 如何将路由播发到本地。
Internet 路由策略
注意
0.0.0.0/0 默认路由不会跨虚拟中心播发。
如果在虚拟中心上启用 Internet 路由策略，则会将 0.0.0.0/0 默认路由播发到中心的所有连接（虚拟网络 ExpressRoute、站点到站点 VPN、点到站点 VPN、中心内 NVA 和 BGP 连接），其中“传播默认路由”或“启用 Internet 安全性”标志设置为 true。 对于不应学习默认路由的所有连接，可以将此标志设置为 false。
专用路由策略
使用专用路由策略配置虚拟中心时，虚拟 WAN 通过以下方式将路由播发到本地连接：
- 路由与从本地中心虚拟网络、ExpressRoute、站点到站点 VPN、点到站点 VPN、中心内 NVA 或 BGP 连接（与当前中心相连）中获知的前缀相对应。
- 路由与从远程中心虚拟网络、ExpressRoute、站点到站点 VPN、点到站点 VPN、中心内 NVA 或 BGP 连接（已配置专用路由策略）中获知的前缀相对应。
- 路由与从远程中心虚拟网络、ExpressRoute、站点到站点 VPN、点到站点 VPN、中心内 NVA 或 BGP 连接（其中未配置路由意向，并且远程连接传播到本地中心的 defaultRouteTable）中获知的前缀相对应。
- 除非已启用 Global Reach，否则从某条 ExpressRoute 线路中获知的前缀不会播发到其他 ExpressRoute 线路。 如果要通过中心部署的安全解决方案启用 ExpressRoute 到 ExpressRoute 的传输，请提交支持案例。 有关详细信息，请参阅启用跨 ExpressRoute 线路的连接。
关键路由方案
以下部分介绍在虚拟 WAN 中心上配置路由意向时的一些关键路由方案和路由行为。
使用路由意向在 ExpressRoute 线路之间进行传输连接
在虚拟 WAN 中，ExpressRoute 线路之间的传输连接是通过两个不同的配置实现的。 由于这两种配置不兼容，因此客户应选择一种配置选项来支持两个 ExpressRoute 线路之间的传输连接。
注意
要使用专用路由策略通过中心中的防火墙设备启用 ExpressRoute 到 ExpressRoute 传输连接，请向 Microsoft 支持部门提交支持案例。 此选项与 Global Reach 不兼容，并且需要禁用 Global Reach 以确保连接到虚拟 WAN 的所有 ExpressRoute 线路之间正确的传输路由。
- ExpressRoute Global Reach：ExpressRoute Global Reach 允许两个启用 Global Reach 的线路直接相互发送流量，而无需经过虚拟中心。
- 路由意图专用路由策略：配置专用路由策略允许两个 ExpressRoute 线路通过中心中部署的安全解决方案相互发送流量。
通过中心的防火墙设备与路由意向专用路由策略进行跨 ExpressRoute 线路的连接可在以下配置中使用：
- 两条 ExpressRoute 线路都已连接到同一个中心，并在该中心上配置了专用路由策略。
- ExpressRoute 线路连接到不同的中心，并在两个中心上配置专用路由策略。 因此，这两个中心都必须部署安全解决方案。
ExpressRoute 的路由注意事项
注意
以下路由注意事项适用于订阅中的所有虚拟中心，Microsoft 支持部门启用这些虚拟中心以允许 ExpressRoute 通过中心的安全设备连接到 ExpressRoute。
使用虚拟中心部署的防火墙设备启用跨 ExpressRoute 线路的传输连接后，在将路由播发到本地 ExpressRoute 的方式方面，可以预期以下行为更改：
- 虚拟 WAN 会自动将 RFC1918 聚合前缀（10.0.0.0/8、192.168.0.0/16、172.16.0.0/12）播发到本地连接的 ExpressRoute。 除了上一节所述的路由外，还会播发这些聚合路由。
- 虚拟 WAN 会自动将 defaultRouteTable 中的所有静态路由播发到本地连接的 ExpressRoute 线路。 这意味着虚拟 WAN 会将专用流量前缀文本框中指定的路由播发到本地。
由于这些路由播发更改，这意味着本地连接的 ExpressRoute 无法播发 RFC1918 聚合地址范围（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）的确切地址范围。 确保播发更具体的子网（在 RFC1918 范围内），而不是聚合超级网和“专用流量”文本框中的任何前缀。
此外，如果 ExpressRoute 线路向 Azure 播发非 RFC1918 前缀，请确保在专用流量前缀文本框中输入的地址范围比 ExpressRoute 播发的路由更具体。 例如，如果 ExpressRoute 线路从本地播发 40.0.0.0/24，请在“专用流量前缀”文本框中输入 /23 CIDR 或更大的 CIDR 范围（例如：40.0.0.0/23）。
通过中心部署的安全设备启用 ExpressRoute 到 ExpressRoute 传输连接不会影响到其他本地部署（站点到站点 VPN、点对站点 VPN、NVA）的路由播发。
加密 ExpressRoute
若要将加密 ExpressRoute（通过 ExpressRoute 线路运行的站点到站点 VPN 隧道）与路由意向专用路由策略结合使用，请将防火墙规则配置为允许虚拟 WAN 站点到站点 VPN 网关（源）的隧道专用 IP 地址和本地 VPN 设备（目标）之间的流量。 对于在防火墙设备上使用深度数据包检查的客户，建议从深度数据包检查中排除这些专用 IP 之间的流量。
可以通过下载 VPN 配置并查看 vpnSiteConnections -> gatewayConfiguration -> IPAddresses 来获取虚拟 WAN 站点到站点 VPN 网关的隧道专用 IP 地址。 IPAddresses 字段中列出的 IP 地址是分配给站点到站点 VPN 网关（用于通过 ExpressRoute 终止 VPN 隧道）的每个实例的专用 IP 地址。 在下面的示例中，网关上的隧道 IP 为 192.168.1.4 和 192.168.1.5。
"vpnSiteConnections": [
{
"hubConfiguration": {
"AddressSpace": "192.168.1.0/24",
"Region": "South Central US",
"ConnectedSubnets": [
"172.16.1.0/24",
"172.16.2.0/24",
"172.16.3.0/24",
"192.168.50.0/24",
"192.168.0.0/24"
]
},
"gatewayConfiguration": {
"IpAddresses": {
"Instance0": "192.168.1.4",
"Instance1": "192.168.1.5"
},
"BgpSetting": {
"Asn": 65515,
"BgpPeeringAddresses": {
"Instance0": "192.168.1.15",
"Instance1": "192.168.1.12"
},
"CustomBgpPeeringAddresses": {
"Instance0": [
"169.254.21.1"
],
"Instance1": [
"169.254.21.2"
]
},
"PeerWeight": 0
}
}
本地设备用于终止 VPN 的专用 IP 地址是指定为 VPN 站点链接连接一部分的 IP 地址。
使用上面的示例 VPN 配置和 VPN 站点，创建防火墙规则以允许以下流量。 VPN 网关 IP 必须是源 IP，本地 VPN 设备必须是已配置规则中的目标 IP。
| 规则参数 | 值 |
|---|---|
| 源 IP | 192.168.1.4 和 192.168.1.5 |
| Source Port | * |
| 目标 IP | 10.100.0.4 |
| Destination Port | * |
| 协议 | ANY |
加密 ExpressRoute 的性能
使用加密 ExpressRoute 配置专用路由策略通过中心中部署的下一个跃点安全设备路由 VPN ESP 数据包。 因此，可以预期加密 ExpressRoute 最大 VPN 隧道吞吐量在两个方向（从本地入站和从 Azure 出站）上都为 1 Gbps。 若要实现最大 VPN 隧道吞吐量，请考虑以下部署优化：
- 部署 Azure 防火墙高级版，而不是 Azure 防火墙标准版或 Azure 防火墙基本版。
- 使允许流量在 VPN 隧道终结点（在上例中为 192.168.1.4 和 192.168.1.5）之间流动的规则在 Azure 防火墙策略中具有最高优先级，确保 Azure 防火墙先处理该规则。 有关 Azure 防火墙规则处理逻辑的详细信息，请参阅 Azure 防火墙规则处理逻辑。
- 关闭 VPN 隧道终结点之间的流量的深层数据包。 有关如何配置 Azure 防火墙以从深度数据包检查中排除流量的信息，请参阅 IDPS 绕过列表文档。
- 将 VPN 设备配置为对 IPSEC 加密和完整性使用 GCMAES256，以最大限度地提高性能。
直接路由到 NVA 实例，实现双角色连接和防火墙 NVA
注意
在虚拟 WAN 中使用专用路由策略的双角色 NVA 的直接路由仅适用于虚拟网络之间的流量以及通过 BGP 从部署在虚拟 WAN 中心的 NVA 学到的路由。 与本地 NVA 连接的 ExpressRoute 和 VPN 传输连接不会直接路由到 NVA 实例，而会通过双角色 NVA 的负载均衡器进行路由。
某些网络虚拟设备可以在同一设备上同时具有连接性 (SD-WAN) 和安全性 (NGFW) 功能。 这些 NVA 被视为双角色 NVA。 检查 NVA 在 NVA 合作伙伴下是否为双角色 NVA。
为双角色 NVA 配置专用路由策略时，虚拟 WAN 会自动播发从该虚拟 WAN 中心的 NVA 设备到直接连接的（本地）虚拟网络以及虚拟 WAN 中的其他虚拟中心，并将下一跃点作为 NVA 实例而不是 NVA 内部负载均衡器播发。
对于主动-被动 NVA 配置，其中只有一个 NVA 实例会将特定前缀的路由播发到虚拟 WAN（或从其中一个实例中学习的路由 AS-PATH 长度始终为最短），虚拟 WAN 可确保从 Azure 虚拟网络的出站流量始终路由到活动（或首选）NVA 实例。
对于主动-主动 NVA 配置（多个 NVA 实例播发具有相同 AS-PATH 长度的相同前缀），Azure 会自动执行 ECMP 以将流量从 Azure 路由到本地。 Azure 软件定义的网络平台不能保证流级对称性，这意味着从 Azure 到 Azure 的入站流和来自 Azure 的出站流可以登陆到 NVA 的不同实例。 这会导致出现由有状态防火墙检查丢弃的非对称路由。 因此，不建议使用主动-主动连接模式，其中 NVA 的行为是双重角色 NVA，除非 NVA 可以支持非对称转发或支持会话共享/同步。 有关 NVA 是否支持非对称转发或会话状态共享/同步的详细信息，请联系 NVA 提供商。
通过 Azure 门户配置路由意向
可以使用 Azure 防火墙管理器或虚拟 WAN 门户通过 Azure 门户配置路由意向和路由策略。 借助 Azure 防火墙管理器门户，可以使用下一个跃点资源 Azure 防火墙配置路由策略。 借助虚拟 WAN 门户，可以使用下一个跃点资源 Azure 防火墙、部署在虚拟中心内的网络虚拟设备，或 SaaS 解决方案来配置路由策略。
在虚拟 WAN 安全中心使用 Azure 防火墙的客户可以将 Azure 防火墙管理器的“启用中心之间”设置设为“已启用”，以使用路由意向，或使用虚拟 WAN 门户直接将 Azure 防火墙配置为路由意向和策略的下一个跃点资源。 任一门户体验中的配置都是等效的，Azure 防火墙管理器中的更改会自动反映在虚拟 WAN 门户中，反之亦然。
通过 Azure 防火墙管理器配置路由意向和策略
以下步骤介绍如何使用 Azure 防火墙管理器在虚拟中心上配置路由意向和路由策略。 Azure 防火墙管理器仅支持 Azure 防火墙类型的下一个跃点资源。
导航到要在其上配置路由策略的虚拟 WAN 中心。
在“安全性”下，选择“安全虚拟中心设置”，然后选择“在 Azure 防火墙管理器中管理此安全虚拟中心的安全提供程序和路由设置”。
从菜单中选择要配置路由策略的中心。
在“设置”下，选择“安全配置”
如果要配置 Internet 流量路由策略，请从“Internet 流量”的下拉列表中选择“Azure 防火墙”或相关的 Internet 安全提供程序。 否则，请选择“无”
如果要通过 Azure 防火墙配置专用流量路由策略（针对分支和虚拟网络流量），请从“专用流量”的下拉列表中选择“Azure 防火墙”。 否则，请选择“绕过 Azure 防火墙”。
如果要配置专用流量路由策略，并让分支或虚拟网络播发非 IANA RFC1918 前缀，请选择“专用流量前缀”，并在随即显示的文本框中指定非 IANA RFC1918 前缀范围。 选择“完成”。
将“中心间”设置为“已启用”。 启用此选项可确保路由策略应用于此虚拟 WAN 中心的路由意向。
选择“保存”。
对要配置路由策略的其他安全虚拟 WAN 中心重复步骤 2-8。
此时，你已准备好发送测试流量。 请确保正确配置防火墙策略以根据所需的安全配置来允许/拒绝流量。
通过虚拟 WAN 门户配置路由意向和策略
以下步骤介绍如何使用虚拟 WAN 门户在虚拟中心上配置路由意向和路由策略。
从“先决条件”部分的步骤 3 的确认电子邮件中提供的自定义门户链接，导航到要配置路由策略的虚拟 WAN 中心。
在“路由”下方，选择“路由策略”。
如果要为分支和虚拟网络流量配置专用流量路由策略，请在“专用流量”下选择“Azure 防火墙”、“网络虚拟设备”或“SaaS 解决方案”。 在“下一个跃点资源”下，选择相关的下一个跃点资源。
如果要配置专用流量路由策略，并让分支或虚拟网络使用非 IANA RFC1918 前缀，请选择“其他前缀”，并在随即显示的文本框中指定非 IANA RFC1918 前缀范围。 选择“完成”。 请确保将相同的前缀添加到配置了专用路由策略的所有虚拟中心的“专用流量前缀”文本框中，以确保将正确的路由播发到所有中心。
如果要配置 Internet 流量路由策略，请选择“Azure 防火墙”、“网络虚拟设备”或“SaaS 解决方案”。 在“下一个跃点资源”下，选择相关的下一个跃点资源。
如果要应用路由意向和路由策略配置，请单击“保存”。
对要为其配置路由策略的所有中心重复此操作。
此时，你已准备好发送测试流量。 请确保正确配置防火墙策略以根据所需的安全配置来允许/拒绝流量。
使用 BICEP 模板配置路由意向
有关模板和步骤的信息，请参阅 BICEP 模板。
疑难解答
以下部分介绍在虚拟 WAN 中心上配置路由意向和策略时进行故障排除的常用方法。
有效路由
注意
只有专用路由策略中指定的下一个跃点资源才支持在虚拟 WAN 路由意图下一个跃点资源上应用有效路由。 如果同时使用专用和 Internet 路由策略，请检查专用路由策略中指定的下一个跃点资源上的有效路由，了解 Internet 路由策略下一个跃点资源上有效的路由虚拟 WAN 程序。 如果仅使用 Internet 路由策略，请检查 defaultRouteTable 上的有效路由，以查看在 Internet 路由策略下一个跃点资源上编程的路由。
在虚拟中心上配置专用路由策略时，虚拟中心内的 Azure 防火墙、网络虚拟设备或 SaaS 解决方案将检查本地与虚拟网络之间的所有流量。
因此，defaultRouteTable 的有效路由将显示下一个跃点为 Azure 防火墙或网络虚拟设备的 RFC1918 聚合前缀（10.0.0.0/8、192.168.0.0/16、172.16.0.0/12）。 这反映出虚拟网络和分支之间的所有流量都路由到中心内的 Azure 防火墙、NVA 或 SaaS 解决方案进行检查。
在防火墙检查数据包（并且根据防火墙规则配置允许数据包）后，虚拟 WAN 会将该数据包转发到其最终目标。 若要查看虚拟 WAN 使用哪些路由转发检查的数据包，请查看防火墙或网络虚拟设备的有效路由表。
防火墙有效路由表有助于缩小问题范围和隔离网络中的问题，例如配置错误或某些分支和虚拟网络的问题。
排查配置问题
如果要排查配置问题，请考虑以下事项：
- 请确保下一个跃点为虚拟网络连接的 defaultRouteTable 中没有自定义路由表或静态路由。
- 如果部署不符合上述要求，则 Azure 门户中用于配置路由意向的选项将灰显。
- 如果使用 CLI、PowerShell 或 REST，则路由意向创建操作将失败。 删除失败的路由意向，删除自定义路由表和静态路由，然后尝试重新创建。
- 如果使用 Azure 防火墙管理器，请确保 defaultRouteTable 中的现有路由命名为 private_traffic、internet_traffic 或 all_traffic。 如果路由命名不同，则用于配置路由意向（启用中心间）的选项将灰显。
- 在中心上配置路由意向后，请确保更新现有连接或创建与中心的新连接，并将可选的关联和传播路由表字段设置为空。 对于通过 Azure 门户执行的所有操作，系统会自动将可选的关联和传播设置为空。
排查数据路径问题
假设你已查看“已知限制”部分，下面是排查数据路径和连接问题的一些方法：
- 有效路由疑难解答：
- 如果配置了专用路由策略，则应该会在 RFC1918 聚合（10.0.0.0/8、192.168.0.0/16、172.16.0.0/12）的 defaultRouteTable 的有效路由中看到下一个跃点为防火墙的路由，以及在专用流量文本框中指定的任何前缀。 确保所有虚拟网络和本地前缀都是 defaultRouteTable 中静态路由中的子网。 如果本地或虚拟网络使用的地址空间不是 defaultRouteTable 中有效路由中的子网，请将前缀添加到“专用流量”文本框中。
- 如果配置了 Internet 流量路由策略，则应该会在 defaultRouteTable 的有效路由中看到默认 (0.0.0.0/0) 路由。
- 在确认 defaultRouteTable 的有效路由具有正确前缀后，请查看网络虚拟设备或 Azure 防火墙的有效路由。 防火墙上的有效路由显示虚拟 WAN 选择了哪些路由，并确定防火墙可以将数据包转发到哪些目标。 查明哪些前缀缺失或处于错误状态有助于缩小数据路径问题的范围，并指向正确的 VPN、ExpressRoute、NVA 或 BGP 连接进行故障排除。
- 特定于场景的疑难解答：
- 如果虚拟 WAN 中有一个非安全中心（没有 Azure 防火墙或 NVA 的中心），请确保与该非安全中心的连接将传播到已配置路由意向的中心的 defaultRouteTable。 如果未将传播设置为 defaultRouteTable，则与安全中心的连接无法将数据包发送到非安全中心。
- 如果配置了 Internet 路由策略，请确保应获知 0.0.0.0/0 默认路由的所有连接的“传播默认路由”或“启用 Internet 安全性”设置均设置为“true”。 即使配置了 Internet 路由策略，设置为“false”的连接也无法获知 0.0.0.0/0 路由。
- 如果使用在与虚拟中心相连的虚拟网络中部署的专用终结点，则从本地发往专用终结点（在与虚拟 WAN 中心相连的虚拟网络中部署）的流量将默认绕过路由意向的下一个跃点 Azure 防火墙、NVA 或 SaaS。 但是，这会导致非对称路由（这可能导致本地和专用终结点之间的连接丢失），因为辐射虚拟网络中的专用终结点将本地流量转发到防火墙。 若要确保路由对称，请在部署专用终结点的子网上为专用终结点启用路由表网络策略。 在中心上配置专用路由策略时，在“专用流量”文本框中配置与专用终结点专用 IP 地址对应的 /32 路由将不能确保流量对称。
- 如果将加密 ExpressRoute 与专用路由策略结合使用，请确保防火墙设备的规则已配置为允许虚拟 WAN 站点到站点 VPN 网关专用 IP 隧道终结点与本地 VPN 设备之间的流量。 ESP（加密外部）数据包应记录在 Azure 防火墙日志中。 有关采用路由意向的加密 ExpressRoute 的详细信息，请参阅加密 ExpressRoute 文档。
排查 Azure 防火墙路由问题
- 在尝试配置路由意向之前，请确保 Azure 防火墙的预配状态为成功。
- 如果在分支/虚拟网络中使用非 IANA RFC1918 前缀，请确保已在“专用前缀”文本框中指定这些前缀。 配置的“专用前缀”不会自动传播到配置了路由意向的虚拟 WAN 中的其他中心。 若要确保连接性，请将这些前缀添加到每个具有路由意向的中心的“专用前缀”文本框中。
- 如果在防火墙管理器的“专用流量前缀”文本框中指定了非 RFC1918 地址，你可能需要在防火墙上配置 SNAT 策略，以便对非 RFC1918 专用流量禁用 SNAT。 有关详细信息，请参阅 Azure 防火墙 SNAT 范围。
- 考虑和查看 Azure 防火墙日志，以帮助对网络流量进行故障排除和分析。 有关如何设置 Azure 防火墙监视的详细信息，请参阅 Azure 防火墙诊断。 有关不同类型的防火墙日志的概述，请参阅 Azure 防火墙日志和指标。
- 有关 Azure 防火墙的详细信息，请查看 Azure 防火墙文档。
对网络虚拟设备进行排除故障
- 在尝试配置路由意向之前，请确保网络虚拟设备的预配状态为成功。
- 如果在本地连接或虚拟网络中使用非 IANA RFC1918 前缀，请确保已在“专用前缀”文本框中指定这些前缀。 配置的“专用前缀”不会自动传播到配置了路由意向的虚拟 WAN 中的其他中心。 若要确保连接性，请将这些前缀添加到每个具有路由意向的中心的“专用前缀”文本框中。
- 如果在“专用流量前缀”文本框中指定了非 RFC1918 地址，你可能需要在 NVA 上配置 SNAT 策略，以便对某些非 RFC1918 专用流量禁用 SNAT。
- 检查 NVA 防火墙日志，查看防火墙规则是正在放弃还是拒绝流量。
- 请联系 NVA 提供商，以获取有关故障排除的更多支持和指导。
排查软件即服务问题
- 在尝试配置路由意向之前，请确保 SaaS 解决方案的预配状态为成功。
- 有关更多故障排除提示，请参阅虚拟 WAN 文档中的故障排除部分，或参阅 Palo Alto Networks Cloud NGFW 文档。