利用 Direct Connect Gateway 和 Transit Gateway 打造跨国企业网络环境

接触过 AWS 的朋友都知道，我们可以使用 AWS Direct Connect 服务来创建专线连接到 AWS 的区域，并且我们可以通过 Direct Connect Gateway 打通一个本地机房到多个 AWS 的区域。但是如果我们要做比较复杂的云上路由交换功能的话，还需要用到 Transit Gateway 这个服务。

如果我们的最终客户来自全球不同的国家和地区，我们可能需要将不同的基础设施和服务部署到位于不同地理位置的 AWS Region 中，以便客户能够以最快的速度访问到自己需要的内容。因此，在企业级的网络中，我们需要打通不同的本地机房和不同的 AWS 区域。

AWS Transit Gateway 可以理解为云上的路由器，它能够打通不同的 VPC，VPN连接，Direct Connect Gateway 等，集中化地控制云上云下的不同流量走向。新建立的 VPC 只需要直接连接到 Transit Gateway 上，就可以对此 VPC 的所有路由进行控制，而不需要像以前那样管理非常多 VPC 和 VPC 之间， 本地和 VPC 之间的复杂 Peering 关系。

而且，更令人兴奋的是，在2019年12月份的时候，AWS 宣布 Transit Gateway 可以支持跨区域的 Peering。因此，我们只需要在每一个 AWS Region 中创建一个 Transit Gateway，然后就可以将它们通通 Peering 起来，做成一个完全由自己控制的全球网络了。截至发稿时，这个新功能还只支持 US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt) 和 Europe (Ireland) 区域，更多区域还尽请期待。

本篇文章的设计适用于以下这些场景：

• 本地数据中心/办公室通过 Direct Connect 线路或 VPN 上云，并且云上涉及多个不同的 AWS 区域
• 目前在使用多个 AWS 区域的多个 VPC，希望不同 VPC 之间能通信，或部分能通信
• 目前在使用复杂的 VPC Peering 功能或者 Transit VPC 功能，希望减轻管理负担

架构图

在不使用 Transit Gateway 的情况下，如果我们要做4个 VPC 的全连接，我们需要这么设计拓扑图：

每一个 VPC 都需要单独建立一个 VPC Peering 到另一个 VPC，同时 Direct Connect Gateway 和 VPN 都需要单独建一个连接到每一个 VGW 上，非常复杂，管理起来也很混乱。

当然我们也可以做一个 Transit VPC，来减少一定的拓扑复杂度，但是我们一样需要考虑 Transit VPC 中软路由的性能，高可用问题。

如果有了 TGW 和 TGW 跨区域的 Peering 之后，我们可以将架构图简化为以下这样：

从架构图可以看到，我们本地机房通过一条 Direct Connect 专线接入到 AWS，并且使用 Direct Connect Gateway (后面将会简称为 DXGW) 到达两个不同的 Transit Gateway （后面会简称 TGW），TGW 之间做了 Peering。这样设计之后，所有的 VPC 和本地数据中心都能做到两两互通。

我们还在 DX 专线作为主线路的基础上，还分别搭建了2条到 TGW 的备用线路（基于 Internet 的 IPSec VPN），并且所有这些线路都是会根据 BGP 动态进行选路和切换的。如果 Direct Connect 线路出现故障，流量会自动流向备用线路。

后面将会把图中的不同 VPC 分别标注为 VPC1，VPC2，VPC3 和 VPC4，方便解释。

前置工作和注意事项

• 首先我们需要确保所有的 VPC 和子网都正确设置完毕，并且子网之间的网段是不重合的，每一个 VPC 都有关联一个 Virtual Private Gateway。
• 接着，我们需要保证自己购买的 Direct Connect 线路有 1G 或者 10G 的带宽，否则创建不了后面需要的 Transit VIF，当然我们也有应变方法解决这个限制。详情可以查看文章 Integrating sub-1 Gbps hosted connections with AWS Transit Gateway。
• 目前 TGW 跨区域 Peering 只能支持5个区域，所以不在这5个区域范围内的话目前还不能支持。
• 确保安全组和网络 ACL 没有封禁 ICMP 的流量。

配置 Transit Gateway

Transit Gateway 是一个区域级的服务，所以我们每一个区域创建一个就可以了。我们先到 VPC 的界面，点击 Transit Gateway，在第一个区域（佛吉尼亚州）创建一个 TGW，输入名字，保持其他的配置默认，点击创建 Transit Gateway。

在第二个区域（俄亥俄州），同样创建另一个 TGW。

在弗吉尼亚区域， VPC 界面中找到 Transit Gateway Attachments ，创建一个 TGW 的对等连接，选择另一端 TGW 所在的区域和 ID，然后点击创建按钮。

然后我们去到俄亥俄区域，找到相应的位置，选择接受这个 TGW 。至此，两个 TGW 就 Peering成功了，它们之间配置了路由表之后，就可以直接通信了。

接着，我们还需要把每个区域的 VPC 都附加到相应的 TGW 中，这样 TGW 才能接管 VPC 的流量，帮 VPC 做路由转发。

我们需要把架构图中的4个 VPC 都做类似的关联操作（此处省略具体操作），关联到对应的 TGW 上。

配置 Direct Connect Gateway

进入 Direct Connect 的页面，创建一个 Direct Connect Gateway，输入名字和相应的 BGP ASN 号码。

我们如果有一个 1G/10G 的 Direct Connect 线路，就可以创建一个 Transit Vif 了（或者我们也可以直接找 APN Partner 合作伙伴申请一个 Transit VIF）。在创建的过程中，需要关联到之前创建的 Direct Connect Gateway，如果一切配置正常，那么这个 VIF 的状态会变成可用的，BGP 状态也是 UP的。

在 Direct Connect 的页面，点击 Direct Connect Gateways，选择刚才创建的网关，然后选择 Gateway Associations 标签，进入如下界面。选择要关联的 TGW，输入需要从这个 TGW 导入的路由前缀，点击关联网关按钮。

注意：此处可以填写明细路由 10.1.1.0/24（VPC1 的网段） 和 10.1.2.0/24（VPC2 的网段），我们也可以对这两个网段进行聚合，聚合成 10.1.0.0/16，从而减少客户端路由器收到的路由条目数。

重复以上操作，将另一个区域的 TGW 也关联上来，路由前缀填写 10.2.0.0/16。

至此，Direct Connect Gateway 就和2个 TGW 关联在一起了。

路由表设置

TGW 的路由表

我们可以利用Transit Gateway 来精细化地控制流量的走向，在 TGW 里面有几个比较关键的概念，分别是 Association 和 Propagations。详细的解释可以看官网页面。

简单来说，我们可以在 TGW 上创建多个路由表，通过 Association 来控制这个路由表谁来用，通过 Propagations 来自动从哪些地方学 BGP 路由。最后通过学过来的路由和静态路由的设置来控制具体的路由走向。

如下图所示，是佛吉尼亚区域的 TGW 的默认路由表条目，红色框框的部分是从其他地方（VPC 和本地网络）自动学过来的。然后这里我还手动添加了一条静态路由（10.1.0.0/16），针对俄亥俄区域的流量走 TGW Peering。

除了默认路由表，我们还可以创建更多的路由表，每个路由表关联不同的 Attachment，来精细化控制每一个 Attachment 的路由走向。

VPC 的路由表

我们需要到所有 VPC 的所有子网路由表中，添加一个条目，将默认路由（0.0.0.0/0）的下一跳填写为该区域的 TGW，这样所有默认的流量 VPC 才会转发到 TGW 中，然后由 TGW 来决定继续怎么走。

注意：如果这个子网恰好是公有子网，已经有一条默认路由指到了 Internet Gateway，那么我们这里填写一个汇聚的内网网段就可以了，比如10.0.0.0/8，192.168.0.0/16等。

检查连通性

当以上都配置完成后，我们可以检测下两两的连通性。

从本地网络（客户端路由器）查看路由表信息：

可以看到本地网络已经通过 BGP 从 AWS 两个不同的区域都学到了所有的路由，并且可以直接连通到图上的4个不通区域。

从 VPC1 到本地网络（东京办公室）：

从 VPC1 到 VPC3 （跨区域）：

Direct Connect 为主，VPN为备用线路

如果需要高可用，我们还可以在使用 Direct Connect 的前提下，再建立单独的 Site-to-Site VPN 连接到不同的 Transit Gateway 上。

1. 我们需要先创建一个 Customer Gateway，写入本地路由器的公网地址，并且选择动态路由协议。
2. 创建 Transit Gateway Attachment，类型选择 VPN，选择刚才创建的 Customer Gateway和动态路由协议。并建议开启 Enable Acceleration 选项，这个也是2019年底出的新功能，能利用 AWS 骨干网和边缘节点让本地路由器更快接入到 AWS 内网中，详情可查看 Accelerated Site-to-Site VPN Connections。

    

3. 其他配置可以保持默认
4. 创建完成后，下载本地路由器的配置文件，然后根据配置文件配置本地的路由器。
5. 每一个 VPN 连接都会包含2个 Tunnel，配置正确后两个 Tunnel 的状态应该都是up的。

关于Site to Site VPN 配置指南，可以查看官网教程。

Network Manager

我们还可以利用刚发布的 Network Manager 服务来查看不同的 Transit Gateway 之间以及和本地网络之间的流量数据和状态，比如网络吞吐，丢包率等等信息。

我们还能添加本地设备到这个拓扑图中（比如图中东京的这个路由器）。

总结

本文主要讲解了如何利用 AWS Direct Connect Gateway，将本地网络接入到 AWS 的区域，并且借助 Transit Gateway 接入到不同的 AWS 区域的不同 VPC。不仅有效解决南北流量（本地数据中心到云上）的通行，也解决了东西流量（不同区域的不同 VPC 之间）的通行，真正地让我们整个网络都完全打通了，而不需要像以前那样需要做很多 Peering，需要管理很多点对点的连接，很大程度上减少了管理的复杂度。

另外在 Transit Gateway 上我们可以创建不同路由表，这个类似 VRF (Virtual Route Forwarding) 的概念，我们可以创建不同的路由区域，让 A 区域可以访问 B 区域，但是 C 区域能访问 A 区域却不能访问 B区域等。在一些网络设计中我们可能需要对这些流量进行精细化控制，比如所有的 VPC 之间都不能互相访问，但是所有 VPC 都能访问一个共享服务 （Share Service）的 VPC。

Transit Gateway 是云上的路由器，而且目前已经能支持跨区域的 Peering 了，给我们做路由控制和流量控制带来了很大的方便。它本身也是高可用的，并且也能承载非常高的流量，我们不用再担心给这个路由器升级，打补丁，扩容的问题了！

我们还可以巧妙利用 Transit Gateway 和 AWS 的全球骨干网来减少企业网的全球网络部署成本，减少目前我们在 MPLS 上的线路支出，具体请期待下一篇相关文章！
 

本篇作者