前言

Gateway Load Balancer(以下简称GWLB)在re:Invent 2020前推出,并在3月陆续在AWS Global及亚马逊云科技中国区域上线,AWS国内国外的官方博客推出了一系列博客文章来介绍。

1. https://aws.amazon.com/cn/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/

文章集中介绍了GWLB的多种架构类型,可以做为架构设计的参考指南。

2. https://github.com/aws-samples/aws-gateway-load-balancer-code-samples

Repo提供了两个复杂的GWLB场景,分别对应

Scaling network traffic inspection using AWS Gateway Load Balancer

https://aws.amazon.com/cn/blogs/networking-and-content-delivery/scaling-network-traffic-inspection-using-aws-gateway-load-balancer/

Centralized inspection architecture with AWS Gateway Load Balancer and AWS Transit Gateway

https://aws.amazon.com/cn/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/

3. 以上两个Case在国内也有三篇文章落地

3.1 通过 AWS Network Firewall 实现南北向资源和服务的有效防护

https://aws.amazon.com/cn/blogs/china/effective-protection-of-ns-resources-and-services-through-aws-network-firewall/

3.2 通过 AWS Network Firewall 实现东西向资源和服务的有效防护

https://aws.amazon.com/cn/blogs/china/through-aws-network-firewall-to-achieve-effective-protection-of-ew-resources-and-services/

3.3 通过 AWS Network Firewall 实现混合云环境下资源和服务的有效防护

https://aws.amazon.com/cn/blogs/china/effective-protection-of-resources-and-services-in-mixed-cloud-environment-through-aws-network-firewall/

4. 使用Gateway Load Balancer实现集中的网络流量深度监测

https://aws.amazon.com/cn/blogs/china/gateway-load-balanceruse-implement-centralized-network-traffic-depth-detection/

5. DESIGN - AWS Gateway Load-Balancer with PAN Firewalls for Inbound, Outbound and East-West Security

https://www.youtube.com/watch?v=h8h0NOnMhx0

针对于文章1,其中针对有NAT GW参与的内网子网流量监测,有以下的架构参考:

(需要指出此图下面这个IGW Edge Route Table第二条规则应为10.0.2/24)

可以了解到,由于之前AWS并不提供更精细的路由(即不能创建比VPC CIDR更精细的路由),导致如果将流量监测设置到NAT GW,则VPC内的私有子网的网络流量无法被监测到。

这个场景其实就是文章4的架构,如下

即文章4所设计的架构,就是文章1中,不支持的一种部署模式,这是因为在文章1中,这种架构虽然可以检测请求流量,但是无法覆盖响应流量,是一种不完整的监测,所以文章1认为这种架构是不完整的,文章4并没有告知读者有这个问题。

本文会先就文章4做一个简化架构,来说明在没有精细路由的情况下,流量监测的不完整,然后结合8月30日在所有商业区域上线的精细路由来完善这个私有子网网络流量监测的场景。

架构

整体架构如文章4,简化了虚拟安全设备的结构。

关于Gateway Load Balancer的创建配置部分,也请参考文章4。以下是部分截图。

子网的部分如下:

公有子网部署了NAT网关,其路由表如下

应用子网通过GWLBe访问公网,路由表如下

GWLBe子网通过NAT网关访问公网,路由表如下

验证

由于我们进行的是网络层面的调试,为了降低噪音,我们采用EC2 Serial Console来连接Application实例,这样即使网络不通,我们仍然可以通过串口控制台在实例上执行命令。

可以看到在以上路由表设置下,PING可以正常返回。

这个结论就是文章4的结论,但是文章4并没有说明,此时安全设备只针对了单向的流量做了监测。可以看到下图中只有ICMP echo request,并没有返回。

这是显而易见的,Application实例请求google.com时,会走App路由表,它会通过GWLBe来访问互联网。但是这个请求的响应是通过NAT网关的路由表来返回的。NAT网关的路由表清晰的指明了,它返回响应时,是直接通过local来传递给Application实例,并没有通过GWLBe。

这时我们可以给NAT网关路由表来添加一条精细路由,来指定响应流量也要通过GWLBe来返回。

这时我们再返回到虚拟安全设备上来看抓包结果。

可以清楚的看到,此时ICMP echo request以及ICMP echo reply都被监测了。

总结

在2021年8月30日之前,VPC路由表的路由是不能比VPC CIDR更具体的,如果你尝试创建就会得到以下这种报错。

这导致了VPC内的流量,以及有NAT网关参与的私有子网访问互联网流量无法被有效完整的监测到。

随着精细路由的上线,AWS自身的Network Firewall,以及其他第三方设备对流量的完整监测已经变为可能,但是也要注意这可能会带来更复杂的路由设计,建议使用IaC来对基础设施做版本管理。

注:

1. GWLBe需要分AZ创建;

2. 2019年上线的VPC Ingress Routing只与IGW有关,无法应用到NAT网关设备上。