将 S2S VPN 用作 ExpressRoute 私有对等互联的备份

在标题为使用 ExpressRoute 专用对等互连设计灾难恢复的文章中，我们讨论了在使用 ExpressRoute 专用对等互连时，为什么需要备用连接解决方案。我们还讨论了如何使用异地冗余 ExpressRoute 线路实现高可用性。本文介绍如何使用和维护站点到站点（S2S） VPN 作为 ExpressRoute 专用对等互连的备份。

注释

在处理延迟敏感、任务关键或带宽密集型工作负载时，不建议将站点到站点 VPN 用作 ExpressRoute 连接的备份解决方案。在这种情况下，建议使用 ExpressRoute 多站点复原功能设计灾难恢复，以确保最大可用性。

与异地冗余 ExpressRoute 线路不同，只能在主动-被动设置中使用 ExpressRoute 和 VPN 灾难恢复组合。在被动模式下使用任何备份网络连接的主要挑战是，被动连接通常与主连接一起失败。被动连接故障的常见原因是缺少主动维护。因此，本文的重点在于如何验证和积极维护一个用于备份 ExpressRoute 私有对等连接的 S2S VPN 连接。

注释

通过 ExpressRoute 和 VPN 公布给定路由时，Azure 更倾向于通过 ExpressRoute 进行路由选择。

本文还介绍如何从 Azure 角度和本地网络边缘端验证连接。能够从任一端进行验证，无论您是否管理与 Azure 网络实体对等互连的本地网络设备，这种能力是帮助验证的关键。

示例拓扑

在我们的设置中，我们有一个通过 ExpressRoute 线路和 S2S VPN 连接连接到 Azure 中心虚拟网络的本地网络。如下图所示，Azure 中枢虚拟网络又与分支虚拟网络对等互连。

正在考虑的拓扑关系图。

在设置中，ExpressRoute 线路在本地一对客户边缘（CE）路由器上终止。本地 LAN 连接到 CE 路由器，其中包含一对防火墙，这些防火墙在领先者模式下运行。 S2S VPN 直接在防火墙上终止。

下表列出了拓扑的关键 IP 前缀：

实体	前缀
内部局域网	10.1.11.0/25
Azure 中心虚拟网络	10.17.11.0/25
Azure 辐射虚拟网络	10.17.11.128/26
本地测试服务器	10.1.11.10
辐射虚拟网络测试 VM	10.17.11.132
ExpressRoute 主要连接 P2P 子网	192.168.11.16/30
ExpressRoute 辅助连接 P2P 子网	192.168.11.20/30
VPN 网关主要 BGP 对等体 IP地址	10.17.11.76
VPN 网关辅助 BGP 对等 IP	10.17.11.77
本地防火墙 VPN BGP 对等 IP	192.168.11.88
主要 CE 路由器 i/f 面向防火墙 IP	192.168.11.0/31
指向主要 CE 路由器 IP 的防火墙接口	192.168.11.1/31
面向防火墙 IP 的辅助 CE 路由器 i/f	192.168.11.2/31
面向辅助 CE 路由器 IP 的防火墙接口	192.168.11.3/31

下表列出了拓扑的 ASN 列表：

自治系统	ASN
本地	65020
Microsoft Enterprise Edge	12076
虚拟网络 GW （ExR）	65515
虚拟网络 GW （VPN）	65515

无不对称性的高可用性

配置高可用性

本文配置 ExpressRoute 和站点到站点共存连接介绍了如何设置共存的 ExpressRoute 和 S2S VPN 连接。正如我们在设计 ExpressRoute 的高可用性时提到的，我们的设置可确保网络冗余，以消除到终结点的任何单一故障点，从而提高 ExpressRoute 高可用性。此外，ExpressRoute 线路的主连接和辅助连接处于活动状态，并通过两个连接以相同的方式播发本地前缀。

通过 ExpressRoute 电路的主连接播发主 CE 路由器的本地路由公告如下所示（Junos 命令）：

user@SEA-MX03-01> show route advertising-protocol bgp 192.168.11.18 

Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

通过 ExpressRoute 线路的辅助连接，辅助 CE 路由器的本地路由公告如下所示（Junos 命令）：

user@SEA-MX03-02> show route advertising-protocol bgp 192.168.11.22 

Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

为了提高备份连接的高可用性，S2S VPN 也在主动-主动模式下进行配置。 Azure VPN 网关配置如下所示。请注意，作为 VPN 配置的一部分，网关的 BGP 对等 IP 地址—10.17.11.76 和 10.17.11.77—也被列出。

VPN 网关配置的屏幕截图。

本地路由由防火墙播发到 VPN 网关的主和辅助 BGP 对等方。路由通告（Junos）如下所示：

user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.76 

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

{primary:node0}
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.77    

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

注释

在主动-主动模式下配置 S2S VPN 不仅为灾难恢复备份网络连接提供高可用性，而且还为备份连接提供更高的吞吐量。因此，建议在主动-主动模式下配置 S2S VPN，因为它将创建多个基础隧道。

配置对称流量

我们注意到，当通过 ExpressRoute 和 S2S VPN 播发给定的本地路由时，Azure 更喜欢 ExpressRoute 路径。若要强制 Azure 更喜欢 S2S VPN 路径而不是共存的 ExpressRoute，需要通过 VPN 连接播发更具体的路由（具有更大子网掩码的前缀）。我们的目标是仅将 VPN 连接用作备份。因此，Azure 的默认路径选择行为符合我们的目标。

我们有责任确保从本地发往 Azure 的流量优先选择 ExpressRoute 路径，而非站点对站点 VPN。本地设置中 CE 路由器和防火墙的默认本地首选项为 100。因此，通过将通过 ExpressRoute 私有对等连接接收到的路由的本地优先级配置为大于 100，我们可以使流向 Azure 的流量优先选择 ExpressRoute 线路。

终止 ExpressRoute 线路的主要连接的主 CE 路由器的 BGP 配置如下所示。请注意，通过 iBGP 会话播发的路由的本地首选项的值配置为 150。同样，我们需要确保终止 ExpressRoute 线路辅助连接的辅助 CE 路由器的本地首选项也配置为 150。

user@SEA-MX03-01> show configuration routing-instances Cust11
description "Customer 11 VRF";
instance-type virtual-router;
interface xe-0/0/0:0.110;
interface ae0.11;
protocols {
  bgp {
    group ibgp {
        type internal;
        local-preference 150;
        neighbor 192.168.11.1;
    }
    group ebgp {
        peer-as 12076;
        bfd-liveness-detection {
            minimum-interval 300;
            multiplier 3;
        }
        neighbor 192.168.11.18;
    }
  }
}

本地防火墙的路由表确认，对于发往 Azure 的内部流量，在正常运行状态下首选路径是通过 ExpressRoute。

user@SEA-SRX42-01> show route table Cust11.inet.0 10.17.11.0/24

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.17.11.0/25      *[BGP/170] 2d 00:34:04, localpref 150
                      AS path: 12076 I, validation-state: unverified
                    > to 192.168.11.0 via reth1.11
                      to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 00:34:01, localpref 150
                      AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
                       AS path: 65515 I, validation-state: unverified
                    > via st0.118
                    [BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
                       AS path: 65515 I, validation-state: unverified
                     > via st0.119
10.17.11.76/32     *[Static/5] 2d 21:12:16
                     > via st0.118
10.17.11.77/32     *[Static/5] 2d 00:41:56
                    > via st0.119
10.17.11.128/26    *[BGP/170] 2d 00:34:04, localpref 150
                       AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.0 via reth1.11
                       to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 00:34:01, localpref 150
                      AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
                       AS path: 65515 I, validation-state: unverified
                    > via st0.118
                     [BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
                       AS path: 65515 I, validation-state: unverified
                     > via st0.119

在上面的路由表中，对于中心辐射虚拟网络路由--10.17.11.0/25 和 10.17.11.128/26-我们看到 ExpressRoute 线路优先于 VPN 连接。 192.168.11.0 和 192.168.11.2 是针对 CE 路由器的防火墙接口上的 IP。

通过 S2S VPN 验证路由交换

本文前面部分已验证防火墙的本地路由播发到 VPN 网关的主和辅助 BGP 对等方。此外，让我们确认防火墙从 VPN 网关的主和辅助 BGP 对等方收到的 Azure 路由。

user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.76 table Cust11.inet.0 

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  10.17.11.0/25           10.17.11.76                             65515 I
  10.17.11.128/26         10.17.11.76                             65515 I

{primary:node0}
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.77 table Cust11.inet.0    

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  10.17.11.0/25           10.17.11.77                             65515 I
  10.17.11.128/26         10.17.11.77                             65515 I

同样，让我们验证 Azure VPN 网关收到的本地网络路由前缀。

PS C:\Users\user> Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | where {$_.Network -eq "10.1.11.0/25"} | select Network, NextHop, AsPath, Weight

Network      NextHop       AsPath      Weight
-------      -------       ------      ------
10.1.11.0/25 192.168.11.88 65020        32768
10.1.11.0/25 10.17.11.76   65020        32768
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 192.168.11.88 65020        32768
10.1.11.0/25 10.17.11.77   65020        32768
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 10.17.11.69   12076-65020  32769

如前所述，VPN 网关的路由由 VPN 网关的主和辅助 BGP 对等方接收。它还可以监控通过主 ExpressRoute 和辅助 ExpressRoute 连接接收到的路由（即那些 AS 路径前面带有 12076 的路由）。若要确认通过 VPN 连接收到的路由，我们需要知道连接的本地 BGP 对等 IP。在正在考虑的设置中，IP 为 192.168.11.88，我们可以看到从中接收的路由。

接下来，让我们验证 Azure VPN 网关播发到本地防火墙 BGP 对等方（192.168.11.88）的路由。

PS C:\Users\user> Get-AzVirtualNetworkGatewayAdvertisedRoute -Peer 192.168.11.88 -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn |  select Network, NextHop, AsPath, Weight

Network         NextHop     AsPath Weight
-------         -------     ------ ------
10.17.11.0/25   10.17.11.76 65515       0
10.17.11.128/26 10.17.11.76 65515       0
10.17.11.0/25   10.17.11.77 65515       0
10.17.11.128/26 10.17.11.77 65515       0

未能看到路由交换表示连接失败。请参阅故障排除：Azure 站点到站点 VPN 连接无法连接并停止工作，以帮助排查 VPN 连接问题。

测试故障转移

现在，我们已确认通过 VPN 连接（控制平面）成功交换路由，接下来我们将从 ExpressRoute 连接切换到 VPN 连接中的流量（数据平面）。

注释

在生产环境中，故障转移测试必须在计划的网络维护工作时段内完成，因为它可能会造成服务中断。

在进行流量切换之前，让我们对我们的设置中，从内部测试服务器到分支虚拟网络中的测试 VM 的当前路径进行路径追踪。

C:\Users\PathLabUser>tracert 10.17.11.132

Tracing route to 10.17.11.132 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.1.11.1
  2    <1 ms    <1 ms    11 ms  192.168.11.0
  3    <1 ms    <1 ms    <1 ms  192.168.11.18
  4     *        *        *     Request timed out.
  5     6 ms     6 ms     5 ms  10.17.11.132

Trace complete.

我们设置的主要和辅助 ExpressRoute 点到点连接子网分别是 192.168.11.16/30 和 192.168.11.20/30。在上面的跟踪路由中，在步骤 3 中，我们看到我们命中了 192.168.11.18，这是主要 MSEE 的接口 IP。 MSEE 接口的存在确认我们的当前路径是通过 ExpressRoute 的，如预期一样。

如重置 ExpressRoute 线路对等互连中所述，让我们使用以下 PowerShell 命令来禁用 ExpressRoute 线路的主对等互连和辅助对等互连。

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

故障转移切换的时间取决于 BGP 的收敛时间。在我们的系统配置中，故障转移开关需要几秒钟（小于 10 秒）。切换后，跟踪路由重复会显示以下路径：

C:\Users\PathLabUser>tracert 10.17.11.132

Tracing route to 10.17.11.132 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.1.11.1
  2     *        *        *     Request timed out.
  3     6 ms     7 ms     9 ms  10.17.11.132

Trace complete.

跟踪路由结果确认通过 S2S VPN 的备份连接处于活动状态，如果主连接和辅助 ExpressRoute 连接都失败，则可以提供服务连续性。若要完成故障转移测试，让我们使用以下一组命令重新启用 ExpressRoute 连接并恢复正常的流量流向。

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

若要确认流量已切换回 ExpressRoute，请重复跟踪路由并确保它通过 ExpressRoute 专用对等互连。

后续步骤

ExpressRoute 专为高可用性而设计，在 Azure 网络中没有单一故障点。 ExpressRoute 线路仍局限于单个地理区域和服务提供商。 S2S VPN 可以是 ExpressRoute 线路的良好灾难恢复被动备份解决方案。对于可靠的被动备份连接解决方案，定期维护被动配置和定期验证连接非常重要。必须不让 VPN 配置过时，并定期（例如每个季度）重复本文在维护时段内所述的验证和故障转移测试步骤。

若要基于 VPN 网关指标启用监视和警报，请参阅有关 VPN 网关指标的设置警报。

在 ExpressRoute 发生故障后，为加快 BGP 收敛，请在 ExpressRoute 上配置 BFD。

Last updated on 2026-03-19

Compartir a través de