亚马逊AWS官方博客
利用 Transit Gateway 和 Fortigate 实现企业东西向和南北向流量安全控制
方案概述
大量企业客户在数据中心都有安全设备来实现流量管控和应用的访问控制。那在 AWS 上部署应用的时候也会延续相同的安全策略,在 VPC 之间的流量、VPC 和本地机房以及 VPC 与公网之间流量都希望能够实现统一的安全控制。在 Transit Gateway 产品发布之前,比较推荐用户采用的实现方式是 Transit VPC 方案,随着 Transit Gateway 在各个 AWS 区域的落地,可以通过 Transit Gateway 的路由表来实现流量的集中化安全管控。本文就这两类方案做一个简单的回顾和总结,并基于 Transit Gateway 的非 VPN 方案具体实现提供自动化脚本和详细的配置说明,供大家进行实验和实际部署的参考。本文主要基于合作伙伴 Fortinet 的产品进行配置示例。
Transit VPC 方案
该方案从2016年推出,在实际生产环境中已有大量客户采用,具体方案细节见如下链接:https://thinkwithwp.com/cn/blogs/aws/aws-solution-transit-vpc/, 以 FortiGate 方案为例,典型拓扑如下:
- 在 Fortinet Transit VPC 解决方案中,Spoke VPC 的 VGW 与 Transit VPC 中的两台 FortiGate 分别建立 BGP over IPsec 的连接,Spoke VPC 会将本 VPC 的网段通过 BGP 通告给 Transit VPC 中的 FortiGate;
- Spoke VPC 的所有非本 VPC 的流量都会通过 VGW 发送到Transit VPC的 FortiGate 上,流量经过过滤后,被允许的流量会通过 IPsec 发送到目的 Spoke VPC 中,通过这样可以达到企业级客户统一控制访问规则的效果。如果用户数据中心也是用 Fortinet 产品的话,配置和使用的方法是一样的。
- 目前合作伙伴的解决方案都已经深度整合 AWS 平台,创建过程可以通过 CloudFormation 脚本自动实现,当需要扩展 Spoke VPC 时,只要给新的 Spoke VPC 的 VGW 打上对应的 Tag,VGW Poller 的 Lambda 就会从 VGW 上把配置拉到 S3 存储桶,再通过 FortiGate VPN configurator 的 Lambda 转换后自动配置到 Transit VPC 中的两台 FortiGate 上,这样可以最大程度的减少配置复杂度和用户使用难度;
Transit Gateway VPN 方案
客户使用 Transit VPC 的方案时,VPC 与 VPC 之间使用 VPN 来连接,VPN 的性能目前不能超过1.25Gbps,同时 FortiGate instance 也会带来额外的资源消耗,这限制了其使用场景。
在2018年 AWS 发布了新的服务 Transit Gateway,它解决了多个 VPC 之间要建立大量对等连接的问题,同时性能很高,可以到50Gbps。利用 Transit Gateway 的 VPN 功能对接安全 VPC,可以显著提高性能,而配置和之前 Transit VPC的配置方式一样简单,只需要将路由指向Transit Gateway,即可实现 VPC 的互联互通。
Transit Gateway 支持通过第三方厂商来同时实现 VPC 与 VPC 之间的东西向流量控制、Spoke VPC 到 Internet 之间的南北向流量控制,拓扑如下图:
在该解决方案中用到了 Transit Gateway 的新特性,即支持 VPN 的 ECMP 功能,使用 VGW与多个 FortiGate 建立 IPsec VPN,防火墙在做好安全过滤与应用层检测后再将源地址 SNAT 后送到目标 VPC 或 Internet,SNAT 保障了数据包的源进源出,Transit Gateway VPN ECMP 配置如下图所示,在建立时勾选即可用支持,FortiGate 在该场景下支持 Autoscaling 自动扩展功能,满足业务流量突发需求;
上述解决方案解决了 Transit VPC 中 FortiGate 的性能瓶颈,可以通过 Autoscaling 来自动扩展,该解决方案与 Transit VPC 的区别是由于 Transit Gateway ECMP 的支持,且防火墙的源路由检查机制,在防火墙实例上必须启用 SNAT 保证数据包源进源出,这样目标服务器看不到访问的源地址,这对于一些需要看到源地址的应用带来挑战。
Tansit Gateway 主备方案
如果需要看到源地址就必须要关闭 SNAT 功能,此时可以通过 VPC 内子网路由控制的方式来实现防火墙主备工作,具体方案架构如下图所示:
- VPC1、VPC2 和防火墙所在 VPC 都 attach 到同一个 Transit Gateway 上,所有 Spoke VPC 都关联同一张路由表,将所有流量都发送到防火墙所在的 attachment。同时在 VPC 内的路由表中将默认路由或者是需要经过安全设备的流量出口指向 Transit Gateway。
- Transit Gateway 发送给安全设备 VPC 的流量会先经过图中的“TGW interface Route Table”路由表,将所有流量发送到 FortiGate-Master 的内网接口。以内网流量为例,FortiGate 查路由表发现 Spoke1/2 也要从相同内网接口发出去,内网接口在 Private subnet 中,就会查询图中的“Private Subnet Route Table”,将流量再发送给 Transit Gateway 的“TGW Route Table2”,从而再转发给流量目标的 VPC。
- 当主设备发生故障时,Lambda 会切换路由表,将“TGW interface Route Table”中的默认路由指向 FortiGate-Slave 的内网接口 ENI。
- 本方案不需配置 VPN,无额外性能消耗,FortiGate 默认支持 C5 及 C5N 的Instance 类型可以充分利用 FortiGate Instance 的性能来配置相应安全功能。
Transit Gateway 主备方案配置演示
本配置示例中的脚本支持在 ap-northeast-1,ap-northeast-2,ap-south-1,ap-southeast-1,ap-southeast-2,ca-central-1,eu-central-1,eu-west-1,eu-west-2,eu-west-3,sa-east-1,us-east-1,us-east-2,us-west-1,us-west-2 这些区域部署。示例脚本链接:https://github.com/lifeisgift/TGW-Fortigate-Workshop
本配置演示的主要环境基本通过自动化来实现,让用户可以快速上手进行试验,通过第一个 CloudFormation 脚本实现三个 VPC 及相应路由表的创建,该流程用户也可以通过手工方式来部署,相应的配置参考如下:
VPC 创建:https://docs.thinkwithwp.com/zh_cn/vpc/latest/userguide/vpc-getting-started.html
TGW 配置:https://thinkwithwp.com/cn/blogs/china/build-transit-gateway-easily-use-complex-network-structure/。
第一个脚本运行完成后生成的基础环境如下,在选择的区域中新增3个 VPC,注意每个帐号在每个区域默认可以创建5个 VPC, 您可能需要通过支持中心创建案例提高该限制:
- 基础环境包含3个 VPC,在两个 spoke VPC 中分别创建了一个较小机型的测试用实例,在 Hub VPC 中分别在两个 AZ 中创建私有和公有子网。完成 Transit Gateway 的创建和3个 VPC 的 attach,同时脚本完成 VPC 中子网路由表和 TGW 路由表的配置。
- 每个 VPC 向 TGW 进行 attach 时需要选择一个子网,如上图放置 ENI 网卡的子网,在Hub VPC 中的这两个子网并不需要特意去配置路由表,在安装 FortiGate 的 VPC 中,关联 TGW 的连个子网路由表会在第二个脚本中生成。
- 本示例是实验环境,Spoke VPC 中只创建了一个 subnet,实际使用中请利用多个 AZ 实现高可用部署。
在运行 CloudFormation 脚本前,先创建秘钥对,详情可以参考帮助文档:https://docs.thinkwithwp.com/zh_cn/AWSEC2/latest/UserGuide/ec2-key-pairs.html#having-ec2-create-your-key-pair
进入 CloudFormation 页面,选择下载到本地的脚本后点击“下一步”
为堆栈输入一个名字,在 KeyPairName 中选择已经创建好的秘钥对,TGW 的 ASN 可以选用默认的也可以自行设置。
然后直接跳过第三步,在第四步选择“创建堆栈”,等待几分钟后状态变为完成。
注意 AWS MarketPlace 中的产品需要先 subscribe 后才能使用:
第二个 CloudFormation 脚本完成后生成的环境如下
- 在 Hub VPC 的两个 AZ 中分别创建一个 FortiGate 设备,以 HA 方式工作
- 创建路由表,将 Hub VPC attach TGW 的两个 subnet 关联,并将默认路由指向主用FortiGate 的第二张网卡 eth1,即在中间层的 private subnet。该条路由在发生倒换时,Lambda 函数会自动切换 target 到备用的 FortiGate 网卡,无需人工干预。
- FortiGate的第一张网卡eth0 创建在公有子网中,实现 FortiGate 设备管理以及南北向流量转发。
在参数选择中按照如下的匹配关系进行选择
示例在新加坡区域,按顺序选择 AZ。
示例为 BYOL 的方式来使用 FortiGate 产品,需要选择存放 license 文件的存储桶位置和文件名。用户也可以选择 PAYG 直接在 AWS Marketplace 中注册并使用,启动脚本参考如下链接:https://github.com/fortinet/aws-cloudformation-templates/tree/master/LambdaAP-EIP%2BRouteFailover/6.0
剩下参数使用默认配置,最后的邮箱可以输入自己的邮箱,可以获取 FortiGate 发生倒换的相关通知。在最后一步中确认 CloudFormation 获得相应运行权限。
等待几分钟后确认堆栈创建成功
在 console 中先查看 ForitGate1 的私有 subnet 中网卡的 IP(eth1):
FortiGate2的内网ENI:
确认路由表,可以看到 HUB VPC 关联到 TGW的子网路由表中,默认路由已经为FortiGate1 内网接口的ENI ID。
登录两台 FortiGate 进行配置
首次登录需要更改密码,完成后利用新密码登录:
确认防火墙回执路由已自动加上:
防火墙内到内的 IPv4 策略已经加上:
在 Spoke VPC1 中的 EC2 发起 ping 测试,验证 Spoke VPC2 中的 EC2 的连通性
测试倒换,从命令行或者 console 中重启 FortiGate1 设备,发生自动到换:
由上图可以看到总共丢了15个 ICMP 报文,业务中断时间在15s左右。
在 CloudWatch 中查看 Lambda 监控日志,记录了该倒换动作,及路由表所做更新:
在 AWS console 中也可以查看路由表,确认 target 已经切换为 FortiGate2 的私网 ENI ID。
注册的邮箱中也会收到通知邮件:
实验结束后,删除两个 CloudFormation 脚本即可清除所有使用资源。
总结:
在 AWS 上实现东西向和南北向流量的安全控制手段越来越丰富,利用传统的 BGP 和IPSec 的方式能满足部分业务场景,也具有较高的灵活性。TGW 服务的发布则带来了更高的性能和更强的路由域划分,用户可以根据自己的实际业务需要选择相应方案,通过本文提供的实验脚本来进行学习和练手。