Gateway Load Balancer + Firewall 多 AZ 极简设计

很多客户使用 Gateway Load Balancer（简称 GWLB）在亚马逊云科技上部署防火墙功能，为了降低部署成本并保证高可用性，通常采用双 AZ 部署。本文介绍一个 GWLB + Firewall 多 AZ 极简设计解决方案，帮助客户在亚马逊云科技上用最低的成本部署最高冗余级别的防火墙系统，并通过 Demo 来展示它是如何工作的。

1. GWLB 网络架构简介

我们先从全局开看一下 GWLB 在网络中的作用，GWLB 将透明的网络网关（即所有流量都使用单个入口和出口点）与负载均衡器相结合，该负载均衡器可分发流量，并根据需求扩展虚拟设备。您可以通过在 VPC 路由表中进行简单的配置将流量发送到 GWLB，借助 GWLB，客户可以在一组虚拟防火墙设备之间实现流量负载均衡，从而弹性扩展其虚拟防火墙设备。GWLB 通过在正常运行的虚拟安全设备之间路由数据流来提高可用性，并在虚拟安全设备运行状况不佳时重新路由流量到健康的虚拟安全设备。

2. GWLB 多 AZ 极简设计架构

2.1 GWLB ENI 介绍

GWLB 会在子网中创建一个网络接口（network interface），一般命名为 gateway_load_balancer，同时也会为其分配一个 IP 地址，GWLB 会用这个 IP 地址和防火墙设备建立 Geneve 隧道，通过该隧道转发流量和进行健康检查，我们可以在 EC2 的 network interface 下搜索 Description 为 ELB gwy/gwlblab-gwlb-firewall/xxx，如图所示，红色框标出的就是 GWLB 使用的 IP 地址，注意，每个启用的 AZ 的 GWLB ENI 都会有一个对应的 IP 地址。

2.2 GWLB 多 AZ 极简设计架构

如上图所示，我们建议部署一个 GWLB 并在两个 AZ 各分别开启一个 GWLB ENI 并各部署一台虚拟防火墙：一个 GWLB 保证成本最低，两个 AZ 分别部署防火墙是为了保证整个方案有 AZ 级别冗余能力；此方案同时要求每个 GWLB ENI 和防火墙接口全互联，并开启 GWLB 的 cross AZ 负载功能。下面我们来介绍一下此方案的工作原理。

3. 极简设计架构健康检查原理

GWLB 会使用配置的子网所有的 ENI 进行健康检查，但是健康检查的方式和结果判断标准和 Cross-zone load balancing 参数是否打开有关。当我们打开了Cross-zone load balancing，每一个 ENI 都会给所有的注册的 instance（同 AZ 和不同 AZ）发送健康检查请求，如下图所示，健康检查会有四条路径，每个实例会收到两个 ENI 发送的健康检查请求。只有当两个健康检查都失败后，实例才会被认定为不健康。

作为对比如果我们关闭 Cross-zone load balancing，每一个 ENI 只会给相同 AZ 的实例发送健康检查请求，如下图所示，健康检查只有有两条路径：

4. 极简设计架构 GWLB 流量转发原理和详解

我们了解健康检查原理后，再来看一下实际流量是如何工作的：

当我们打开 Cross-zone load balancing 设置以后，我们必须要确保的是 GWLB 每一个 ENI 都可以和 EC2 建立 Genevce 隧道，这一点容易被忽略，因为正如我们前面所说，Target Group 的健康检查的结果是以 EC2 所在子网 ENI 的结果为准。如果健康检查结果都是好的，那么如图所示，流量会按照绿色线路平均按照 flow 分配到两个不同 AZ 的 EC2 上。当一个 AZ 的 EC2 安全实例故障后，流量可以切换到另外一个 AZ 的安全实例上，如下图黄线所示（当然，如果整个 AZ 故障后，流量会通过 TGW 将流量全部切换到另外一个 AZ 中）。

如果我们关闭了 Cross-zone load balancing 功能，那么 GLWB 不会去对另一个 AZ 的 EC2 进行健康检查，我们业务的流量经过 TGW 送到 GWLB，注意，TGW 默认会选择和流量转发到相同 AZ，当一个 AZ 的 EC2 安全实例故障后，因为没有全互联架构，GWLB 也不会把流量送到另外一个可用区，因此会造成业务中断（当然，如果整个 AZ 故障后，流量会通过 TGW 将流量全部切换到另外一个 AZ 中，此拓扑依旧能做 AZ 级别冗余保护，但是无法做到安全实例级别冗余保护）。

5. Demo

我们复用 GWLB 的 workshop 来设置我们的 Demo 环境

https://catalog.workshops.aws/gwlb-networking/en-US/50-opensource-suricata/51-suricata-configuration/54-configuring-suricata

选择执行 Lab1 和 Lab2A，我们使用开源的 Suricata 来实现一个自建的防火墙，使用 Geneve 隧道和 GWLB 连通。

我们使用 10.2.2.10 的 EC2 来验证，在该 EC2 上运行如下脚本，可以实现每五秒钟向 8.8.8.8 发送 10 个 ping 包，这样的脚本可以确保定时产生不同的数据流可以使 GWLB 进行负载均衡。

#!/bin/bash
while true; do
    for i in {1..10}; do
        ping -c 1 8.8.8.8 &> /dev/null
        if [ $? -ne 0 ]; then
            echo "Ping failed at attempt $i"
        fi
    done
    echo "Sleeping for 5 seconds..."
    sleep 5
done

打开 Cross-Zone load balancing，我们会看到如下结果，流量均匀分布到两台 EC2 上：

我们通过更改安全组的方式（只留下 Geneve 端口）来模拟其中一台 EC2 出问题：

我们看到 GWLB 会只把流量只送给另一台 EC2，注意，此时 Geneve 的端口 6081 实际上是工作的，但是 GWLB 只会遵循健康检查的结果。

我们再验证关闭 Cross-Zone load balancing 情况：

我们在 GWLB 后两台 EC2 上分别运行命令 sudo tcpdump host 10.0.4.35 | grep 10.2.2.10 | grep -i icmp ，该命令通过 tcpdump 抓取全部流量，同时过滤出 Geneve 数据包中的 GWLB 的 ENI IP（10.0.4.35）和源 EC2 的 IP（10.2.2.10）以及 ICMP（ping 包），我们会看到如下结果，流量只会送给 10.0.4.55 的 EC2。因此如果 10.0.4.55 的 EC2 出现问题，流量就会中断。

6. 总结

我们在使用 GWLB 作为负载均衡器部署防火墙保护应用时，既要考虑低成本，也要考虑高可用的方案，我们使用多 AZ 全互联的架构，且打开 Cross-zone load balancing，那么每一个 AZ 我们可以最少部署 1 台安全设备，当一台安全设备故障时，我们可以通过同一个 GWLB ENI 转发至另一台安全设备上；即使整个 AZ 出现故障，TGW 也会把流量分配给另外一个AZ（请注意：1. 此拓扑 TGW 不要打开 appliance mode；2. 如果打开了 Cross-zone load balancing，会有额外的跨 AZ 的流量费用）。

亚马逊AWS官方博客