Site-to-Site VPN 备份 Direct Connect 方案

在《AWS Direct Connect 高可用路由设计》一文中，笔者叙述了两条 AWS Direct Connect（以下简称 DX）连接场景下的混合云组网最佳实践和选路规则。然而，考虑到 DX 的成本相对较高，对于价格敏感型的用户，使用 AWS Site-to-Site VPN 对 DX 进行冗余备份是一种性价比更高的方案。本文首先会介绍 AWS Site-to-Site VPN 的冗余性技术原理，然后分别描述六种不同的 VPN 备份 DX 方案的使用场景及其优劣势。

AWS Site-to-Site VPN

AWS Site-to-Site VPN 是一项完全托管的服务，它使用 IPSec 加密隧道在 AWS 与本地数据中心之间建立安全的连接。AWS Virtual Private Gateway（以下简称 VGW）和 Transit Gateway（以下简称 TGW）提供了 Site-to-Site VPN 服务，每个 VPN 连接使用两条 VPN 隧道（VPN tunnel）保证冗余性。在路由协议方面，有 BGP 动态路由和静态路由可供选择。如果本地网关设备支持 BGP 动态路由，建议使用动态路由协议配置 Site-to-Site VPN 连接。

VGW VPN

当 VGW 启用了 Site-to-Site VPN 服务后，其所关联的 VPC 就能和本地网络互连互通。每一个 VPN 连接会产生两条 VPN tunnel，tunnel 1 和 tunnel 2。如果采用 BGP 动态路由，并且两条 tunnel 的状态都是 up，默认情况下 AWS 会随机选择一条 tunnel（比如 tunnel 1）向本地网络发送流量。此时，AWS 会在 tunnel 1 的 BGP peer 上设置 MED 的值为 100，在 tunnel 2 上设置 MED 的值为 200。这样本地网关设备的入云流量会选择 MED 更小的 tunnel 1，确保了路由的对称性。当 tunnel 1 对应的 AWS VPN 终端节点进行维护时，AWS 会在 tunnel 2 上设置一个更小的 MED 值，从而达到平滑切换的目的。

如果采用静态路由，并且两条 tunnel 的状态都是 up，AWS 会随机选择一条 tunnel 向本地网络发送流量。当其中一条 VPN tunnel 发生中断时，AWS 会自动切换至另一条状态是 up 的 VPN tunnel，本地网关设备根据 ICMP 探测结果切换至另一条 VPN tunnel 上。在这种情况下，本地网关设备必须在虚拟 tunnel 接口上支持非对称路由。

TGW VPN

TGW 是 AWS 托管的路由服务，它可以创建 Site-to-Site VPN 连接 VPC 和本地网络。如果采用 BGP 动态路由，在不启用 ECMP 的条件下，AWS 会随机选择一条 tunnel 向本地网络发送流量。AWS 会在 tunnel 1 和 tunnel 2 的 BGP peer 上设置 MED 的值为 100。这里，不建议在本地网关设备上修改任何包括 MED 在内的 BGP 属性。因为当其中一个 AWS VPN 终端节点进行维护时，AWS 会在另一条 VPN tunnel 上设置一个更小的 MED 值，从而达到平滑切换的目的。在这种情况下，本地网关设备必须在虚拟 tunnel 接口上支持非对称路由。

在 TGW 和本地网关设备都开启 BGP ECMP 的条件下，VPN 带宽可从单 tunnel 的 1.25Gbps 扩展至跨多条 tunnel 的 50Gbps。

如果采用静态路由，TGW 和本地设备的两条 VPN tunnel 的主备选择和切换与 VGW VPN 静态路由的行为一致。

第三方 VPN

由于北京和宁夏区域不支持 AWS Site-to-Site VPN，用户须在 EC2 实例上运行开源或者 AWS Marketplace 上提供的商业化虚拟 VPN 软件构建混合云。与 AWS 托管 VPN 服务不同的是，自建第三方 VPN 连接的可靠性、性能，以及 EC2 操作系统的安全维护等多方面因素需要由用户自己考虑。

Site-to-Site VPN 备份 Direct Connect 方案

上文主要阐述了 AWS Site-to-Site VPN 两条隧道的主备选择和切换的技术原理。鉴于用户混合云组网的多样性，本文总结了六种常见的 VPN 备份 DX 的方案。每种方案会介绍出云（流量从 AWS 至本地网络）和入云（流量从本地网络至 AWS）方向的选路规则，以及各个方案的使用场景和优劣势。

方案一：DX/VGW 为主线，VPN/VGW 为备线

该方案将 DX 和 VPN 都终结在 VGW 上，由 VGW 控制路由的主备选择和切换。如果 VGW VPN 使用动态路由，VGW 会从 DX 和 VPN 同时接收到相同的路由前缀 192.168.52.0/24。此时，VGW 会默认选择 DX 作为出云方向的主线路。对于入云方向，设置本地网关设备 DX 的 Local preference 为 200，让 DX 成为主线路。在本地网关的 DX 接口上配置 BFD，使得 DX 自动切换至 VPN 的时间降低至秒级。

如果 VGW VPN 使用静态路由，在 VGW 上配置和从 DX 传播过来相同的静态路由前缀 192.168.52.0/24。此时，VGW 会默认选择 DX 作为出云方向的主线路。对于入云方向，调整静态路由的掩码长度或者其管理距离（DX 所用的 EBGP 管理距离为 20），让本地网关优先选择 DX 作为主线路。在本地网关的 DX 接口上配置 BFD，使得 DX 自动切换至 VPN 的时间降低至秒级。

使用 VGW 终结 VPN 连接的局限性在于 VGW 和 VPC 有一一对应的关系。该方案适用于网络架构为一个或少量 VPC 的环境。如果是多 VPC 环境，则需要建立和维护多条 VPN 连接。此外，VGW VPN 带宽最大为 1.25Gbps。如果 DX 的流量大于 1.25Gbps，切换后的 VPN 连接将会发生超载。

方案二：DX/VGW 为主线，第三方 VPN 为备线

该方案使用 VGW 终结 DX，利用第三方 VPN 软件（vCPE）完成 Site-to-Site VPN 功能。在 VPC 路由表中开启 VGW 的路由传播功能，并设置一条掩码更短的 192.168.0.0/16 静态路由指向 vCPE 的 ENI 网卡。此时，VPC 路由表会根据最长掩码匹配原则优先选择 DX 作为出云方向的主线路。对于入云方向，使用相同的方法设置一条掩码更短的 10.42.0.0/16 静态路由指向 VPN tunnel 接口，或者调整静态路由的管理距离（DX 所用的 EBGP 管理距离为 20），让本地网关优先选择 DX 作为主线路。在本地网关的 DX 接口上配置 BFD，使得 DX 自动切换至 VPN 的时间降低至秒级。

该方案适用于原生不支持 Site-to-Site VPN 的 AWS 北京和宁夏区域，且网络架构为一个或少量 VPC 的环境。如果是多 VPC 环境，则需要创建和维护多台 vCPE 及其 VPN 连接。

方案三：DX/TGW 为主线，VPN/TGW 为备线

该方案将 DX 和 VPN 都终结在 TGW 上，由 TGW 控制路由的主备选择和切换。如果 TGW VPN 使用动态路由，TGW 会从 DX 和 VPN 同时接收到相同的路由前缀 192.168.52.0/24。此时，TGW 会默认选择 DX 作为出云方向的主线路。对于入云方向，设置本地网关设备 DX 的 Local preference 为 200，让 DX 成为主线路。

如果 TGW VPN 使用静态路由，在 TGW 上配置掩码更短的 192.168.0.0/16 静态路由指向 TGW VPN 附件。此时，TGW 根据最长掩码匹配原则优先选择 DX 作为出云方向的主线路。对于入云方向，以同样方式调整静态路由的掩码或者其管理距离（DX 所用的 EBGP 管理距离为 20），让本地网关选择 DX 作为主线路。

TGW 建立在 AWS Hyperplane 之上，这是一种高可靠且水平可扩展的分布式交换结构。在路由收敛方面，TGW 相比传统路由器需要更长的收敛时间。从 DX 切换至 VPN 的端到端时间在 20 至 30 秒之间。如果要求更短的切换时间，建议使用两条 DX 的方案或者下文的方案六。

用户可以利用 TGW 构建集中式网络拓扑（Hub-and-Spoke），即关联在同一个 TGW 上的所有 VPC 都可以复用同一对集中式部署的 DX 和 VPN 访问本地网络。使用 TGW 组网的优势适用于下文的方案四、五、六。此外，TGW VPN 可以启用全球加速功能，加速的 VPN 连接使用 AWS Global Accelerator 将流量从本地网络路由到离用户网关设备最近的 AWS 边缘站点，避免在互联网上可能发生的网络中断。

方案四：DX/TGW 为主线，VPN/TGW Connect 为备线

考虑到北京和宁夏区域不支持 Site-to-Site VPN，需要由第三方 VPN 软件（vCPE）部署 Site-to-Site VPN。该方案中，TGW 和 vCPE 之间通过 GRE 隧道交换 BGP 路由信息，即 TGW Connect 方案。如果 TGW 分别从 DX 和 TGW Connect 接收到相同的路由前缀 192.168.52.0/24，TGW 会默认选择 DX 作为出云方向的主线路。对于入云方向，本地网关设备也会默认优选 DX，因为其 AS_Path 比 VPN 更短。

正如方案三所描述，DX 切换至 VPN 的端到端时间在 20 至 30 秒之间。如果要求更短的切换时间，建议使用两条 DX 的方案或者下文的方案六。有关 TGW Connect 的部署和详细配置请参考《Transit Gateway Connect 连接类型集成 FortiGate 安全服务》和《基于 TGW 和思科云业务路由器的企业混合云网络互联》。

方案五：DX/TGW 为主线，第三方 VPN 为备线

该方案由 TGW 关联 DX，由第三方 VPN 软件（vCPE）部署 Site-to-Site VPN。与方案四不同的是，由于一些开源 VPN 软件不支持 GRE 和 BGP 协议，此方案中的 TGW 和 vCPE 之间采用静态路由。在 TGW 路由表里设置一条掩码更短的 192.168.0.0/16 静态路由指向 vCPE 所在的 VPN VPC 附件，然后在 VPN VPC 中 TGW ENI 所在的子网路由里设置 192.168.0.0/16 静态路由指向 vCPE ENI 网卡。 vCPE 需要设置 VPC 回程路由指向 TGW。TGW 会根据最长掩码匹配原则优先选择 DX 作为出云方向的主线路。对于入云方向，使用相同的方式设置一条掩码更短的 10.42.0.0/16 静态路由指向 VPN tunnel 接口，或者调整静态路由的管理距离（DX所用的 EBGP 管理距离为 20），让本地网关优先选择 DX 作为主线路。正如方案三所描述，DX 切换至 VPN 的端到端时间在 20 至 30 秒之间。如果要求更短的切换时间，建议使用两条 DX 的方案或者下文的方案六。

方案六：第三方 SDWAN 方案

该方案把 DX 和 VPN 作为 underlay，云上 vCPE 和云下 CPE 之间采用 SDWAN overlay 的方式互连。出云和入云方向的路径选择均由 SDWAN 策略来控制。为了确保高可用，云上至少部署两台 vCPE，TGW 和两台 vCPE 之间通过 GRE 隧道交换 BGP 路由信息，即 TGW Connect 方案。采用 SDWAN 是优势在于触发切换的条件可以是链路质量，即不满足网络丢包、延迟和抖动的 SLA 时，就能发生切换。由于 BFD 的支持，该方案的切换时间在秒级。

总结

本文首先讲述了基于 VGW 和 TGW 的 VPN 两条 tunnel 的主备选择，然后介绍了 VPN 备份 DX 的六种常见组网方案。在每一种方案中分析了如何利用动态和静态路由协议控制 DX 为主线，VPN 为备线，以及各自的使用场景和优劣势。六种 Site-to-Site VPN 备份 Direct Connect 方案的对比总结如下：

参考文档

[1] AWS Direct Connect 冗余性建议

[2] 如何将我的 Site-to-Site VPN 连接配置为首选隧道 A 而不是隧道 B？

[3] Site-to-Site VPN 路由设置选项

[4] 如何解决在中转网关中创建 VPN 作为 Direct Connect 的备份时出现的非对称路由问题？

本篇作者