AWS Gateway Load Balancer (GWLB) in single VPC Quickstart

GWLB in single VPC Quickstart CloudFormation Template

一、架构说明

1、GWLB简介

关于AWS GWLB，之前构建过一个结合Transit Gateway的多VPC的GWLB方案，也就是所谓的集中式。集中式是指应用系统所在的VPC是没有GWLB Endpoint的，流量是通过Transit Gateway汇集到一个统一的VPC做流量检查。

本次构建的quickstart则是一个分布式检测架构。所谓分布式，是指整个架构不包含Transit Gateway，而应用系统VPC本身是包含GWLB Endpoint。未来增加第二个、第三个VPC时候，每个VPC都带有自己的GWLB Endpoint。所以这个架构，在只有一个VPC时候，看起来是Single VPC。如果有多个VPC，就是分布式流量检查架构。

本模版是针对是特定场景下的需求，如果是全新设计，建议按照GWLB最佳实践的架构进行组网。

本方案构建一个单VPC的网络检测方案。本文代码参考Github这里。

主要组件如下：

  • Virtual Appliance：GWLB需要搭配Marketplaces上启动的第三方商用防火墙（NGFW），需要防火墙支持Geneve协议。本Quickstart中，使用EC2运行Geneve proxy程序模拟防火墙；
  • GWLB Endpoint：VPC的流量入口，作为路由表的下一跳接受流量；
  • GWLB：将流量分发给Target Group，目标组中每个EC2是接受Geneve协议封装后发送过来的原始流量，拆包检查；
  • NAT Gateway：本架构中所有对外流量的统一出口，所有VPC访问外部互联网访问均汇集到此后统一出口；
  • ELB：本架构中所有外部进入流量的统一入口；
  • VPC：单个VPC运行所有组件。

2、单一VPC和独立VPC的架构选择

本CloudFormation包含两套模版，第一套模版在single-vpc目录中，即应用系统和GWLB共用同一个VPC。第二套模版在separated-vpc目录，应用系统和GWLB Endpoint在第一个VPC，GWLB和Virtual Appliance在第二个VPC。

根据场景需要二选一即可。二者架构图如下。

如下为架构图1（对应目录single-vpc内的模版）：

总体架构图和路由表说明

如下为架构图2（对应目录separated-vpc内的模版）：

总体架构图和路由表说明

二、启动模版使用说明

1、前提

确认如下：

  • 本账号的EIP Limit大于5，新的NAT Gateway和堡垒机都将绑定EIP
  • 中国区已经通过了ICP备案，可以测试从外网互联网发起的对ELB的80端口发起访问
  • 本模版里边的IAM Role是按照AWS中国区编写的，如果在Global启动，请将模版Nested-SSMRole.yml其中的aws-cn替换为aws即可在Global区域使用

2、使用S3托管所有CloudFormation模版

  • 下载所有模版下载到自己的AWS账户内的S3存储桶中，包含主模版和所有Nested嵌套模版
  • 将所有模版文件设置为Public可访问，包含主模版和所有Nested嵌套模版
  • 获取每一个模版文件可以从S3上公开访问的完整URL
  • 编辑主模版 CN-GWLB.yml 文件，将其中嵌套调用各Nested模版的URL网址，修改为上一步生成的网址
  • 最后，将修改过的主模版也上传到S3存储桶，并获取其Public访问地址

3、启动CloudFormation模版

进入Cloudformation界面，选择输入模版的S3地址，填入主模版 CN-GWLB.yml 的S3上公开的地址，然后启动继续配置模版。有三个参数必须设置，分别是：

  • 模版名称
  • EC2 Keypair
  • 跳板机允许登陆的IP地址范围需要替换为当前上网地点的出口的公网IP（也可以后期修改）
  • 其他参数不需要修改，默认参数即可启动

至此创建完成。

4、其他Post-configuration

本模版已经完成了GWLB和GWLB Endpoint的创建，并修改了对应子网的路由表，以确保出向去往互联网和入站流量放行。由此就不需要额外做Post-configuration了，实现了开箱即用。

注意：在中国区运行CloudFormation时候，因为CloudFormation中包含去Github下载代码，可能存在网络访问失败。如果遇到失败，着可以按照下文的说明排错，手工的从Github上下载代码，重新运行。

三、测试GWLB工作正常

1、内网经过GWLB向外访问

以下方法二选一：

（1）通过堡垒机的RDP远程桌面使用SSH登陆EC2访问

使用以下流程验证出向流量正常：

  • 在CloudFormation模版界面找到堡垒机的EIP
  • 使用RDP登陆到堡垒机上
  • 从堡垒机上使用ssh或者putty登陆到内网的EC2
  • 从内网EC2上执行ping命令访问外部互联网资源

（2）使用Session Manager登陆EC2访问

  • 进入EC2控制台，选中位于内网的EC2
  • 点击连接，点击Session Manager
  • 从内网EC2上执行ping命令访问外部互联网资源

2、测试外网经过ELB和GWLB向内访问

从CloudFormation的输出界面找到ELB的外网Endpoint入口地址，将其复制下来，从VPC之外的的网络如办公室环境，使用浏览器或者curl访问。

反复刷新页面，如果交替显示web server 1和web server 2表示访问成功。

3、验证流量经过GWLB

通过EC2控制台上的连接按钮，使用Session Manager功能，连接到Virtual Appliance EC2上。然后执行如下命令即可：

tcpdump -nvv 'port 6081'

然后即可看到Linux Console上打出的转发的数据包，包括了在应用VPC的（10.1.x.x的源地址和目标地址），也可能看到GLWB封装后提交给Virtual Applianc虚拟设备的数据包（192.168.x.x）。

由此表示GLWB转发流量正常。

四、故障排除

1、Virtual Appliance上geneve-proxy未能正常部署/启动的排查

如果部署后遇到以下故障：

  • （1）从控制台上无法使用Session Manager连接位于内网的WebApp1/WebApp2虚拟机
  • （2）从跳板机上无法连接位于内网的WebApp虚拟机
  • （3）外网ALB入口报告502/504错误，无法打开应用服务器
  • （4）外网ALB的Target Group目标组里边显示的EC2状态不健康

如果遇到以上错误，直接原因是：Virtual Appliance上负责模拟防火墙转发流量的Geneve Proxy没有正常运行。

根本原因可能是：

  • CloudFormation脚本中从github下载Geneve Proxy代码到Virtual Appliance的过程中，下载超时，未能正确下载代码，未能下载代码也就无法运行；因此需要重新下载代码；
  • 代码已经从Github下载成功，也被正常运行，也过了一段时间python程序异常退出，需要手工重启python程序。

如果以上两个步骤的任意一个失效，则以上各种网络流量不正常。请按如下两个步骤检查和部署。

2、检查Virtual Appliance是否有Geneve proxy程序在运行并手工重启之

通过EC2控制台上的连接按钮，使用Session Manager功能，连接到Virtual Appliance EC2上。然后执行如下命令检查geneve python脚本是否在运行：

ps awuxf | grep python

如果返回结果是类似如下这样，表示geneve proxy运行正常。

[root@ip-192-168-102-23 ~]# ps awuxf | grep python
root       813  0.4  0.6 127304 13796 ?        S    05:14   0:07 /bin/python3 main.py
root      3276  0.0  0.0 112896   484 pts/0    S+   05:42   0:00                      \_ grep --color=auto python
[root@ip-192-168-102-23 ~]#

如果这个进程不存在，则表示可能程序异常退出。

此时需要先检查下/root/geneve-proxy/目录是否存在。如果目录已经存在，则执行如下命令重启：

cd /root/geneve-proxy/
nohup /bin/python3 main.py &

即可重新启动geneve proxy。网络流量也将转发正常。

如果/root/geneve-proxy/目录不存在，则表示在CloudFormation部署中，因为网络超时的关系，未能从github下载到geneve proxy源代码。那么请参考下边一个章节重新部署geneve proxy脚本。

3、如何手工部署Geneve Proxy

有些时候，自动部署的CloudFormation模版中从github下载Geneve Proxy可能因为跨境网络的关系访问失败，这时候本机上将不存在geneve proxy脚本，也自然无法自动启动脚本了。

此时需要手工的下载脚本。通过EC2控制台上的连接按钮，使用Session Manager功能，连接到Virtual Appliance EC2上。然后执行如下命令即可：

git clone https://github.com/sentialabs/geneve-proxy.git
mv geneve-proxy /root/
mv /root/geneve-proxy/config.yaml /root/geneve-proxy/config-orig.yaml
wget -O /root/geneve-proxy/config.yaml http://blogimg.bitipcman.com/workshop/GWLB/GWLB-in-single-VPC-Quickstart-config.yaml
echo "cd /root/geneve-proxy/" >> /etc/rc.local
echo "nohup /bin/python3 main.py &" >> /etc/rc.local
chmod +x /etc/rc.local
reboot

以上命令部署完毕后会重启Virtual Appliance EC2。重启后，再次用Session manager登陆Virtual Appliance，通过如下命令检查geneve python脚本是否在运行：

ps awuxf | grep python

为了观察流量，可以使用如下命令查看GWLB发来的流量：

tcpdump -nvv 'port 6081'

手工配置Geneve Proxy也可以参考这个视频演示（本视频有解说注意播放音量）。

本文完。