【後編】AWS Gateway Load Balancer(GWLB)をアプライアンス抜きでリージョン間動作確認してみた

AWS
Network

2022.11.09

この記事を書いたメンバー：

榊原慶太

【後編】AWS Gateway Load Balancer(GWLB)をアプライアンス抜きでリージョン間動作確認してみた

初めまして。10月よりBeeXにジョインした榊原と申します。
本記事は先日上げた記事の後編です。まだご覧になっていない方はこちらからどうぞ。
なお、本記事では前の記事に引き続き以下のような略称を用いています。
Gateway Load Balancer→GWLB
Gateway Load Balancer Endpoint→GWLBE

◆構成図

今回の構成図は以下の通りです。S3は送信先のインスタンスに必要なパッケージソフトが入ったAWS提供のバケットです。今回インスタンスに接続する際にセッションマネージャを用いましたが、構成図からは省いております。

◆検証手順

4. GWLBEサービスの作成

セキュリティアカウント側で、VPCコンソール画面から「エンドポイントサービス」、「エンドポイントサービスを作成」をクリックします。

名前は自由。（下図①）
ロードバランサーのタイプは「ゲートウェイ」を選択。（下図➁）
使用可能なロードバランサーから作成したGWLBを選択。（下図➂）
エンドポイントの承諾のチェックは外しておく。（下図➂）
上記操作の後、作成を押す。（下図④）

GWLBEサービス作成後、サービス名をメモ帳等に保存する。（下図①）
その後アクションから「プリンシパルを許可」を選択。（下図➁）
ARNにはセキュリティアカウント側のIDとシステムアカウント側IDを基にした値を二つ入力する。具体的には以下の数値を入力し、プリンシパルを追加を押す。X部分は各アカウントIDでに置き換える。（下図➂④）
arn:aws:iam::XXXXXXXXXXXX:root

5. GWLBEの作成と有効化

システムアカウント側でVPCコンソール画面のエンドポイントから、「エンドポイントを作成」を選択。

名前タグは自由。
サービスカテゴリから「その他のエンドポイントサービス」を選択。

サービス名は先ほどメモしておいたGWLBEのサービス名を入力して「サービスの検証」を選択。
VPCではシステムアカウントのVPCを選択。
サブネットはGWLBEを配置するサブネットを選択。
「エンドポイントを作成」を選択。

しばらくするとエンドポイントが有効になる。

6. ルートテーブルの編集

以下赤字部分のルートテーブルを編集する。

7. 送信先インスタンスの設定

Session Managerや踏み台インスタンス等（構成図からは省略）を用いて、送信先インスタンスにアクセスして以下のコマンドを順に打ち込む。これらのコードを打つことで、セキュリティアプライアンスをEC2インスタンスに乗せずともGWLBの動作確認が可能となります。参考元から一部コードを変更しています。参考元ページはこちらからどうぞ。（GWLBのBlackbeltでも紹介されています。）

sudo su -
# 送信先インスタンスのプライベートIPを<x.x.x.x>に入力
export instance_ip=<x.x.x.x>
# 送信先インスタンスが所属するサブネット内に作成されたGWLBエンドポイント(ENI)のプライベートIPアドレス<y.y.y.y>に入力する。
export gwlb_ip=<y.y.y.y>

# Enable IP Forwarding and persist across reboot
# Enabling using sysctl -w net.ipv4.ip_forward=1, won't persist across reboot.
# 参照元ページにはシンボリックリンクは"/etc/sysctl.d/00-defaults.conf"と指定されているが、書き込みが許可されていない可能性があるため"/etc/sysctl.d/99-sysctl.conf"に書き換えている。
sudo echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/99-sysctl.conf
sudo sysctl -p /etc/sysctl.d/99-sysctl.conf

# ターゲットグループのヘルスチェック(TCP 80)を通すためにApacheをインストール
sudo yum update
sudo yum install httpd
sudo systemctl start httpd.service

#以降は参照元ページのまま。
# Install iptables-services:
sudo yum install iptables-services -y;

# Start and configure iptables:
sudo systemctl enable iptables;
sudo systemctl start iptables;

# Configuration below allows allows all traffic:
# Set the default policies for each of the built-in chains to ACCEPT:
sudo iptables -P INPUT ACCEPT;
sudo iptables -P FORWARD ACCEPT;
sudo iptables -P OUTPUT ACCEPT;

# Flush the nat and mangle tables, flush all chains (-F), and delete all non-default chains (-X):
sudo iptables -t nat -F;
sudo iptables -t mangle -F;
sudo iptables -F;
sudo iptables -X;

# Configure nat table to hairpin traffic back to GWLB:
sudo iptables -t nat -A PREROUTING -p udp -s $gwlb_ip -d $instance_ip -i eth0 -j DNAT --to-destination $gwlb_ip:6081;
sudo iptables -t nat -A POSTROUTING -p udp --dport 6081 -s $gwlb_ip -d $gwlb_ip -o eth0 -j MASQUERADE;

8. 動作確認

準備が整いました。いよいよ動作確認テストです。手順は以下の通りです。
私は送信先インスタンスにはTera Termで、送信元インスタンスにはコンソールからセッションマネージャでアクセスして動作確認を行いました。

①送信先インスタンスにアクセスして以下のコードを入力する。GENEVEプロトコルを用いている6081番ポートの様子を確認するためのコードです。

sudo tcpdump port 6081

　【出力結果例】

➁送信元インスタンスから以下のコードを入力して、送信先へpingをとばす。Xの部分には送信先インスタンスのプライベートIPを入力してください。

ping XXX.XXX.XXX.XXX

➂送信先インスタンスでの出力結果を確認する

　【出力結果例】

　上記の例でいくと送信元インスタンスのドメイン（ip-192-168-0-137.ap-northeast-1.compute.internal.60787）から送信先インスタンスのドメイン（ip-192-168-20-139.ap-northeast-1.compute.internal.6081）への通信がインスペクションされていることが確認できます。

以上、GWLBの動作確認をセキュリティアプライアンス抜きで行う方法でした。BeeXにジョイン後初めての案件かつ比較的新しめのサービスだったので、かなり手間取ってしまいましたがとてもいい勉強になりました。同じチームの皆様、AWSサポートの方々にはこの場を借りてお礼申し上げます。本当にありがとうございました。それでは、また次の記事でお会いしましょう！