すべてのプロダクト
Search

このプロダクト

    Server Load Balancer:GWLB によるインターネットファイアウォールの構築

    ドキュメントセンター

    Server Load Balancer:GWLB によるインターネットファイアウォールの構築

    最終更新日:Jun 21, 2026

    クラウド環境では、パブリックアクセスポイントの散在やセキュリティポリシーの不統一によって生じる、管理の複雑化やセキュリティリスクといった課題に対応するため、Gateway Load Balancer (GWLB) と IPv4 ゲートウェイを統合してインターネット境界ファイアウォールを構築できます。このソリューションでは、IPv4 ゲートウェイを使用して VPC に出入りするすべてのパブリックトラフィックを一元的に制御し、ディープインスペクションとフィルタリングを行うために、GWLB を経由してネットワーク仮想アプライアンスにルーティングします。これにより、セキュリティポリシーを一元的に適用できるようになり、セキュリティリスクを低減し、ネットワーク管理の効率を向上できます。

    Gateway Load Balancer (GWLB) と IPv4 ゲートウェイの統合ソリューションの概要

    従来のパブリックサービスのデプロイメントでは、VPC 内のリソースはパブリック IP アドレスをバインドすることで、インターネットと直接通信します。この方法には、次のようなセキュリティ上の問題があります：

    • 攻撃対象領域の拡大：バインドされた各パブリック IP アドレスは、インターネットに直接公開されるポイントとして機能します。このような IP がリソースごとに増えると、企業のネットワークセキュリティ境界が分断され、トラフィックの統合監視とポリシー適用が困難になります。

    • ポリシー管理の複雑化：セキュリティポリシー (セキュリティグループなど) は、パブリック IP を持つリソースごとに個別に設定し、維持する必要があります。これにより、運用オーバーヘッドと時間コストが増加し、セキュリティを損なう設定ミスのリスクも高まります。

    • ディープインスペクションの欠如：セキュリティグループとネットワーク ACL は、主にレイヤー 4 (IP アドレスとポートに基づく) でアクセス制御を実施します。そのため、ディープパケットインスペクション (DPI)、侵入防止、その他のレイヤー 7 のセキュリティ保護を実行できません。

    IPv4 ゲートウェイを GWLB と併せてデプロイすることで、一元化された、透過的でスケーラブルなインターネット境界ファイアウォールを構築できます。IPv4 ゲートウェイは、VPC からの送受信パブリックトラフィックをすべて一元管理します。次に、このトラフィックは Gateway Load Balancer エンドポイント (GWLBe) を介してバックエンドのネットワーク仮想アプライアンス (ファイアウォールなど) にルーティングされ、ディープパケットインスペクションを実施します。検査後、トラフィックは対応する GWLBe を経由して戻され、最後にアプリケーションサーバーへ転送されます。

    主な機能

    • IPv4 ゲートウェイ

      • パブリックトラフィックの一元管理：IPv4 ゲートウェイをルートテーブルなどのコンポーネントと組み合わせることで、すべてのパブリックトラフィックが IPv4 ゲートウェイを通過するようにできます。これにより、セキュリティポリシーの統一的な適用と監査が簡素化され、分散したアクセスに起因するセキュリティリスクを効果的に低減できます。

    • GWLB

      • 透過的なトラフィック検査：GWLB はレイヤー 3 のネットワークゲートウェイとして動作します。ネットワーク仮想アプライアンスによる検査中も、トラフィックは元の送信元 IP アドレスと宛先 IP アドレスを維持するため、クライアントやバックエンドサービスの変更は不要です。

      • スケーラブルなネットワーク仮想アプライアンス：サービスのトラフィックの変化に応じて、GWLB の背後にあるネットワーク仮想アプライアンスをいつでも追加または削除できます。

      • クロスゾーン高可用性デプロイメント：GWLB とそのバックエンドのネットワーク仮想アプライアンスは、複数のゾーンにまたがってデプロイできます。1 つのゾーンでネットワーク仮想アプライアンスまたは GWLBe に障害が発生した場合、トラフィックは他のゾーンの正常なノードへ自動的に切り替わり、セキュリティサービスの高可用性を確保します。

    シナリオ

    • セキュリティコンプライアンス監査の一元化：金融や政府など、厳格なコンプライアンス要件がある業界向けに、セキュリティアプライアンスの統合クラスターを提供し、パブリックトラフィックログとセキュリティポリシーの一貫した監査、監視、イベント追跡を可能にします。

    • パブリックサービス向けの高度なセキュリティ保護：インターネットに公開される Web サイト、API、またはアプリケーションに対して、コンテンツのディープインスペクションを提供し、Web 攻撃、悪意のあるスキャン、ウイルス侵入などの高度な脅威から効果的に防御します。

    • VPC リソースの安全なアウトバウンドアクセス：インターネットへ能動的にアクセスする VPC リソース (パッチ更新や外部 API 呼び出しなど) のために、安全なエグレスチャネルを提供します。これにより、悪意のあるサイトへのアクセスやデータ漏えいを防止します。

    制限

    • GWLB の背後では、少なくとも 1 つのネットワーク仮想アプライアンスを稼働させる必要があります。

    • GWLB バックエンドサーバーのアクセス制御ポリシー (セキュリティグループルールなど) では、ポート 6081 (Geneve プロトコルのポート) の UDP トラフィックを許可する必要があります。

    • エンドポイントサービスを作成する際は、PrivateLink と GWLB インスタンスの両方をサポートするリージョンとゾーンを選択する必要があります。PrivateLink と GWLB インスタンスをサポートするリージョンとゾーンの詳細については、「Regions and zones that support PrivateLink」および「Regions and zones that support GWLB」をご参照ください。

    • 接続を確立するには、GWLBe をデプロイするゾーンは、エンドポイントサービスリソース (GWLB) をデプロイするゾーンのサブセットである必要があります。

    シナリオ例

    ある企業の基幹業務システムは、Alibaba Cloud の China (Ulanqab) リージョンにある VPC で稼働しています。高可用性を確保するため、アプリケーションサーバーの Elastic Compute Service (ECS) インスタンスは 2 つのゾーン (Ulanqab Zone B と Ulanqab Zone C) に分散して配置され、Elastic IP アドレス (EIP) を直接バインドして外部トラフィックを処理しています。事業の拡大に伴い、このデプロイメントモデルでは、パブリックエントリポイントが分散しているため、セキュリティポリシーと監査を統一して適用することが難しく、セキュリティを一元的に管理したいという高まる需要に応えられません。また、このモデルにはディープトラフィックインスペクションの機能がないため、高度化するサイバー攻撃に対して効果的ではありません。

    これらの問題を解決するために、企業は GWLB と IPv4 ゲートウェイ を併せてデプロイし、高可用性のインターネット境界ファイアウォールを構築できます。この構成により、トラフィックの検査と管理を一元化し、セキュリティリスクを大幅に低減し、一貫したセキュリティ保護ポリシーを適用できます。

    image

    前提条件

    • ビジネス VPC とセキュリティ VPC を作成し、ビジネス VPC のゾーン B とゾーン C にビジネスサブネットと GWLBe サブネットを設定し、セキュリティ VPC のゾーン B とゾーン C にセキュリティサブネットを設定しておきます。 詳細については、「Virtual Private Cloud と vSwitch」をご参照ください。

    • ビジネス VPC にアプリケーションサーバーの ECS インスタンスを作成し、そのインスタンスにアプリケーションサービスをデプロイしておきます。 ECS インスタンスがパブリックネットワーク通信を必要とする場合は、パブリック IP アドレスを割り当てます。

    • ビジネス VPC 用に IPv4 ゲートウェイを作成してアクティブ化しておきます。

    • IPv4 ゲートウェイルートテーブル、ビジネスサブネットルートテーブル、GWLBe サブネットルートテーブルなど、必要なルートテーブルを作成しておきます。

    • セキュリティ VPC に、ネットワーク仮想アプライアンスをシミュレートするために、少なくとも 2 つの ECS インスタンスを作成しておきます。

      重要

      セキュリティ VPC の ECS インスタンスタイプがジャンボフレームをサポートしていることを確認してください。 Geneve カプセル化によって元のパケットに 68 バイトが追加され、1500 バイトを超える可能性があるためです。 詳細については、「ネットワークの最大伝送単位」および「ジャンボフレームをサポートするインスタンスファミリー」をご参照ください。

    • ビジネス VPC とセキュリティ VPC の両方にあるすべての ECS インスタンス用に、セキュリティグループを作成しておきます。 セキュリティ VPC の ECS インスタンスのセキュリティグループで、ポート 6081 の UDP トラフィック、およびヘルスチェックに必要なポートとプロトコルが許可されていることを確認してください。

    参考例： CIDR ブロックの計画

    VPC

    ゾーン

    CIDR ブロックとリソース

    ビジネス VPC

    プライマリ CIDR ブロック： 192.168.0.0/16

    ゾーン B

    • GWLBe_01 サブネット B： 192.168.101.0/24

    • ビジネスサブネット B： 192.168.1.0/24

    • アプリケーションサーバー ECS_B_01 (EIP にバインド済み)： 192.168.1.153

      参考例： ECS_B_01 にテストサービスをデプロイ (Alibaba Cloud Linux 3 を使用)

      yum install -y nginx
systemctl start nginx.service
cd /usr/share/nginx/html/
echo "Hello World ! This is ECS_B_01." > index.html

    ゾーン C

    • GWLBe_02 サブネット C： 192.168.102.0/24

    • ビジネスサブネット C： 192.168.2.0/24

    • アプリケーションサーバー ECS_C_01 (EIP にバインド済み)： 192.168.2.151

      参考例： ECS_C_01 にテストサービスをデプロイ (Alibaba Cloud Linux 3 を使用)

      yum install -y nginx
systemctl start nginx.service
cd /usr/share/nginx/html/
echo "Hello World ! This is ECS_C_01." > index.html

    セキュリティ VPC

    CIDR ブロック： 10.0.0.0/16

    ゾーン B

    • セキュリティサブネット B： 10.0.1.0/24

    • ネットワーク仮想アプライアンス ECS_01： 10.0.1.40

    ゾーン C

    • セキュリティサブネット C： 10.0.2.0/24

    • ネットワーク仮想アプライアンス ECS_02： 10.0.2.170

    操作手順

    ステップ 1：Gateway Load Balancer の設定

    GWLB インスタンスの作成

    インスタンスは、ロードバランシングサービスの実体です。まず GWLB インスタンスを作成します。

    1. Gateway Load Balancer (GWLB) コンソールのトップメニューバーで、GWLB インスタンスをデプロイするリージョンを選択します。

    2. インスタンス ページで、作成 をクリックします。

    3. Gateway Load Balancer 購入ページで、GWLB インスタンスを設定し、今すぐ購入 をクリックして、コンソールのプロンプトに従ってインスタンスのアクティベーションを完了します。

      このシナリオでは、[リージョンとゾーン] を 中国 (ウランチャブ) に、VPC を作成したセキュリティ VPC に、ゾーン を ウランチャブ ゾーン B および ウランチャブ ゾーン C に設定します。 各ゾーンの対応するセキュリティサブネットの vSwitch ID を選択します。 ここに記載されていない他の GWLB インスタンス設定については、デフォルト値を使用するか、必要に応じて調整します。

    4. インスタンス ページに戻り、適切なリージョンを選択すると、新しいインスタンスを表示できます。

    バックエンドサーバーグループの作成

    サーバーグループを作成し、GWLB によって転送されるクライアントリクエストを受信するためのバックエンドサーバーを追加します。

    1. 左側のナビゲーションペインで、GWLB > サーバーグループ を選択します。

    2. サーバーグループ ページで、サーバーグループの作成 をクリックします。

    3. サーバーグループの作成 ダイアログボックスでサーバーグループのパラメーターを設定し、作成済み をクリックします。

      このシナリオでは、タイプ を サーバータイプ に、[VPC] を作成したセキュリティ VPC (GWLB インスタンスと同じ VPC) に設定し、ここに記載されていない他のサーバーグループ設定については、デフォルト値を使用するか、必要に応じて調整してください。

    4. サーバーグループが作成されました ダイアログボックスで、バックエンドサーバーの追加 をクリックします。

    5. バックエンドサーバーの追加 パネルで、作成した ECS_01 と ECS_02 のインスタンスを選択し、OK をクリックします。

    リスナーの設定

    インスタンスのリスナーを設定し、バックエンドサーバーグループに関連付けて、Geneve プロトコルを使用してすべてのポートのトラフィックをバックエンドサーバーに転送します。

    1. 左側のナビゲーションペインで、GWLB を選択し、インスタンス ID をクリックします。

    2. リスナー タブをクリックし、IP リスナーの作成 をクリックします。

    3. IP リスナーの作成 設定ページで、タイプ に作成したサーバーグループを選択し、OK をクリックします。

      ここに記載されていないその他の IP リスナー設定については、デフォルト値を使用するか、必要に応じて調整してください。

    ステップ 2：ネットワーク仮想アプライアンスの設定

    GWLB は OSI モデルのレイヤー 3 で透過モードで動作するため、その背後にデプロイされたネットワーク仮想アプライアンスを、Geneve でカプセル化されたトラフィックを正しく受信、処理、返送できるように適応させる必要があります。

    Alibaba Cloud GWLB は、サードパーティのネットワーク仮想アプライアンス (Fortinet や Hillstone など) をバックエンドサーバーグループに統合することをサポートしています。このトピックでは、iptables を使用してバックエンドネットワーク仮想アプライアンスをシミュレートします。実際の構成については、デバイスベンダーの指示に従ってください。

    参考例：ECS_01 で iptables を設定 (Alibaba Cloud Linux 3 を使用)

    # Step1: 構成スクリプトをファイルに保存
cat > setup_gwlb_multi_iptables.sh <<'EOF'
#!/bin/bash
# setup_gwlb_multi_iptables.sh
# マルチゾーン GWLB デプロイメント用に、IP 転送、iptables、およびヘアピン NAT ルールを自動的に構成します
# ---- 1. 構成パラメータ (必要に応じて変更) ----
instance_ip="10.0.1.40" # この ECS インスタンスのプライベート IP、例: Ulanqab Zone B の ECS_01
gwlb_ip1="10.0.1.41"   # Ulanqab Zone B の GWLB のプライベート IP
gwlb_ip2="10.0.2.171"  # Ulanqab Zone C の GWLB のプライベート IP
# ---- 2. IPv4 転送を有効化 ----
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/00-defaults.conf
sysctl -p /etc/sysctl.d/00-defaults.conf
# ---- 3. iptables サービスをインストール ----
yum install iptables-services -y
# ---- 4. iptables サービスを有効化して起動 ----
systemctl enable iptables
systemctl start iptables
# ---- 5. 基本的な iptables ポリシーをすべてのトラフィックを許可するように設定 (テスト/POC のみ。本番環境では必要に応じて制限してください) ----
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
# ---- 6. すべての iptables テーブルとルールをクリア ----
iptables -t nat -F
iptables -t mangle -F
iptables -F
iptables -X
# ---- 7. マルチゾーン GWLB 用のヘアピン NAT ルールを構成 ----
iptables -t nat -A PREROUTING -p udp -s $gwlb_ip1 -d $instance_ip -i eth0 -j DNAT --to-destination $gwlb_ip1:6081
iptables -t nat -A POSTROUTING -p udp --dport 6081 -s $gwlb_ip1 -d $gwlb_ip1 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -p udp -s $gwlb_ip2 -d $instance_ip -i eth0 -j DNAT --to-destination $gwlb_ip2:6081
iptables -t nat -A POSTROUTING -p udp --dport 6081 -s $gwlb_ip2 -d $gwlb_ip2 -o eth0 -j MASQUERADE
# ---- 8. iptables ルールを保存 ----
service iptables save
echo "【完了】ECS $instance_ip にマルチゾーン GWLB 用の NAT と転送ルールが適用されました!"
EOF
# Step2: スクリプトを実行可能にする
chmod +x setup_gwlb_multi_iptables.sh
# Step3: すぐに実行
sudo ./setup_gwlb_multi_iptables.sh

    ステップ 3：PrivateLink の設定

    エンドポイントサービスの設定

    GWLB インスタンスをエンドポイントサービスのサービスリソースとして公開し、ビジネス VPC からアクセスできるようにします。

    1. エンドポイントサービス ページで、エンドポイントサービスの作成 をクリックします。

    2. エンドポイントサービスの作成 ページで、エンドポイントサービスの設定を行い、OK をクリックします。

      このシナリオでは、リージョン に 中国 (ウランチャブ) を、サービスリソースタイプ に GWLB を、サービスリソースの選択 に ウランチャブ ゾーン B および ウランチャブ ゾーン C を設定し、作成した GWLB インスタンスをサービスリソースとして選択して、エンドポイント接続を自動で許可 を はい に設定します。ここに記載されていないその他のエンドポイントサービス設定については、デフォルト値を使用するか、必要に応じて調整します。

    Gateway Load Balancer エンドポイントの設定

    サービス利用者として、GWLBe インスタンスを作成してエンドポイントサービスに接続します。

    1. エンドポイント ページで、GWLB タブをクリックし、次に エンドポイントの作成 をクリックします。

    2. エンドポイントの作成 ページで、GWLBe_01 の設定を行い、OK をクリックします。

      このシナリオの設定は次のとおりです。ここに記載されていないその他のエンドポイント設定については、デフォルト値を使用するか、必要に応じて調整してください。

      パラメーター

      説明

      [リージョン]

      ここでは [China (Ulanqab)] を選択します。

      [エンドポイント名]

      エンドポイントのカスタム名を入力します。

      [タイプ]

      エンドポイントのノードタイプを選択します。このトピックでは GWLB を選択します。

      [タイプ]

      このトピックでは、利用可能なサービスの選択 を選択し、作成したエンドポイントサービスを選択します。

      [VPC]

      エンドポイントの VPC を選択します。ここでは、ビジネス VPC ID を選択します。

      [ゾーン | vSwitch]

      エンドポイントサービスに対応するゾーンを選択し、そのゾーンの vSwitch を選択します。システムは、この vSwitch の下にエンドポイント Elastic Network Interface (ENI) を自動的に作成します。

      ここでは、[Ulanqab Zone B] と Zone B の GWLBe サブネットの vSwitch ID を選択します。

    3. 作成手順を繰り返して GWLBe_02 を作成します。[Ulanqab Zone C] と Zone C の GWLBe サブネットの vSwitch ID を選択します。

      説明

      エンドポイント接続ステータスが「接続済み」と表示されていることを確認してください。

    ステップ 4：ルーティングの設定

    トラフィックを GWLBe に転送するようにルートを設定します。

    1. ルートテーブル ページのトップメニューバーで、ルートテーブルのリージョンを選択します。

      このシナリオでは、[China (Ulanqab)] を選択します。

    2. 以下の手順に従って、対象の各ルートテーブルの ID をクリックし、ルートテーブルの詳細ページでルートを設定します。

      説明

      ルートテーブル詳細ページの ルートエントリ > システムルート タブで、システムルートエントリを表示できます。

      システムは、カスタムルートテーブルに、次のシステムルート (VPC 内の vSwitch CIDR ブロックと一致する宛先 CIDR ブロックを持つルート) を自動的に追加します。これにより、それらの vSwitch 内のクラウドリソース間の通信が可能になります。

      • IPv4 ゲートウェイルートテーブル： IPv4 ゲートウェイルートテーブルには、アプリケーションサーバー宛てのトラフィックを GWLBe にルーティングするエントリが含まれている必要があります。

        ルートテーブル詳細ページの ルートエントリ > システムルート タブで目的のシステムルートエントリを見つけ、操作 列の 変更 をクリックします。ルートエントリの編集 ダイアログボックスで次のように設定し、OK をクリックします。

        設定後、これらのルートエントリはカスタムルート タブに表示されます。

        設定

        宛先 CIDR ブロック 192.168.1.0/24 のシステムルートエントリ

        宛先 CIDR ブロック 192.168.2.0/24 のシステムルートエントリ

        [ネクストホップの種類]

        GWLB エンドポイント を選択します。

        [GWLB エンドポイント]

        Zone B の既存の GWLBe_01 を選択します。

        Zone C の既存の GWLBe_02 を選択します。

      • ビジネスサブネットルートテーブル： ビジネスサブネットルートテーブルには、アプリケーションサーバーからのすべてのトラフィックを GWLBe にルーティングするエントリが含まれている必要があります。

        ウランチャブ ゾーン B および ゾーン C のビジネスサブネットのルートテーブル詳細ページで、ルートエントリ > カスタムルート タブに移動し、ルートエントリの追加 をクリックします。ルートエントリの追加 ダイアログボックスで、次のように設定し、OK をクリックします。

        設定

        ビジネスサブネット B ルートテーブル

        ビジネスサブネット C ルートテーブル

        [ターゲット CIDR]

        0.0.0.0/0

        [ネクストホップの種類]

        GWLB エンドポイント を選択します。

        [GWLB エンドポイント]

        Zone B の GWLBe_01 を選択します。

        Ulanqab Zone C で作成した GWLBe_02 を選択します。

      • GWLBe サブネットルートテーブル： GWLBe サブネットルートテーブルは、検査済みの戻りトラフィックを最終的な宛先にルーティングする必要があります。インターネットから発信されたトラフィックの場合、ローカルルートによってアプリケーションサーバーへの配信が保証されます。アプリケーションサーバーからのトラフィックの場合、すべてのトラフィックを IPv4 ゲートウェイに送信するルートを追加します。

        ウランチャブゾーン B およびゾーン C の GWLBe サブネットのルートテーブル詳細ページで、ルートエントリ > カスタムルート タブに移動して ルートエントリの追加 をクリックし、ルートエントリの追加 ダイアログボックスで次のように設定してから、OK をクリックします。

        設定

        GWLBe サブネットルートテーブル

        [ターゲット CIDR]

        0.0.0.0/0

        [ネクストホップの種類]

        IPv4 Gateway を選択します。

        [IPv4ゲートウェイ]

        作成した IPv4 ゲートウェイを選択します。

    ルーティング設定の参考：IPv4 ゲートウェイルートテーブル、ビジネスサブネットルートテーブル、および GWLBe サブネットルートテーブルのルートエントリ (カスタムルートエントリのみ表示)

    • IPv4 ゲートウェイルートテーブルの設定

      [ターゲット CIDR]

      ネクストホップ

      ルートエントリタイプ

      192.168.1.0/24

      Gateway Load Balancer エンドポイント (GWLBe_01)

      カスタムルートエントリ

      192.168.2.0/24

      Gateway Load Balancer エンドポイント (GWLBe_02)

      カスタムルートエントリ

    • ビジネスサブネットルートテーブルの設定

      サブネットタイプ

      [ターゲット CIDR]

      ネクストホップ

      ルートエントリタイプ

      ビジネスサブネット B

      0.0.0.0/0

      Gateway Load Balancer エンドポイント (GWLBe_01)

      カスタムルートエントリ

      ビジネスサブネット C

      0.0.0.0/0

      Gateway Load Balancer エンドポイント (GWLBe_02)

      カスタムルートエントリ

    • GWLBe サブネットルートテーブルの設定

      サブネットタイプ

      [ターゲット CIDR]

      ネクストホップ

      ルートエントリタイプ

      GWLBe サブネット B

      0.0.0.0/0

      IPv4 ゲートウェイ

      カスタムルートエントリ

      GWLBe サブネット C

      0.0.0.0/0

      IPv4 ゲートウェイ

      カスタムルートエントリ

    ステップ 5：検証テスト

    セキュリティアプライアンスサーバーにログオンし、次のコマンドを実行してポート 6081 のすべてのパケットをキャプチャします。

    tcpdump -i any port 6081

    出力には、アプリケーションサーバー ECS インスタンスからのリクエストパケットとレスポンスパケットが表示され、GWLB がセキュリティ検査のためにトラフィックをネットワーク仮想アプライアンスに正常にルーティングしていることが確認できます。

    インバウンドトラフィック接続のテスト

    1. インターネットにアクセスできる任意のクライアントから、curl http://<アプリケーションサーバー ECS_B_01 にバインドされた EIP> と curl http://<アプリケーションサーバー ECS_C_01 にバインドされた EIP> を実行して、アプリケーションへの正常なアクセスを確認します。

      C:\Users\Administrator>curl http://8.xxx.56/
Hello World ! This is ECS_C_01.
C:\Users\Administrator>curl http://8.xxx.130/
Hello World ! This is ECS_B_01.

    2. GWLB の任意のバックエンド ECS インスタンスで、コマンドラインウィンドウを開き、tcpdump -i any port 6081 を実行して、ポート 6081 のすべてのパケットをキャプチャします。

      出力に Geneve でカプセル化されたトラフィックが表示され、内部パケットが IP <クライアントパブリック IP>.xxxxx > <アプリケーション ECS プライベート IP>.http ... のように表示されている場合、GWLB は外部トラフィックを処理のためにセキュリティアプライアンスに正しく配信しています。

      10:24:36.525075 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [SEW], seq 2485172945, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:24:36.525098 IP iZ0jlgsxxx.56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [SEW], seq 2485172945, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:24:36.526547 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [S,E], seq 3488689686, ack 2485172946, win 59220, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:24:36.526549 IP iZ0jlgxxx.56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [S,E], seq 3488689686, ack 2485172946, win 59220, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:24:36.572545 IP 10.0.1.41.56736 > iZ0jlgxxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [.], ack 1, win 255, length 0
10:24:36.572551 IP iZ0jlgs4u5xxx.56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [.], ack 1, win 255, length 0
10:24:36.572552 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [P.], seq 1:77, ack 1, win 255, length 76: HTTP: GET / HTTP/1.1
10:24:36.572554 IP iZ0xxx.56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [P.], seq 1:77, ack 1, win 255, length 76: HTTP: GET / HTTP/1.1
10:24:36.622282 IP 10.0.1.41.56736 > iZ0jlgsxxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [F.], seq 77, ack 269, win 254, length 0
10:24:36.622288 IP iZ0jlgs4uxxx.56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [F.], seq 77, ack 269, win 254, length 0
10:24:36.623401 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [F.], seq 269, ack 78, win 463, length 0
10:24:36.623481 IP iZ0jlgs4uxxx.56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [F.], seq 269, ack 78, win 463, length 0

    アウトバウンドトラフィック接続のテスト

    1. 任意のアプリケーションサーバーにログオンし、ping www.aliyun.com を実行して、インターネットへの正常なアクセスを確認します。

      [root@iZ0jl xxx xxx ~]# ping www.aliyun.com
PING www.aliyun.com.w.cdngslb.com (124.238.xxx.xxx) 56(84) bytes of data.
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=1 ttl=51 time=17.3 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=2 ttl=51 time=15.1 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=3 ttl=51 time=15.1 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=4 ttl=51 time=14.5 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=5 ttl=51 time=14.4 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=6 ttl=51 time=14.4 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=7 ttl=51 time=14.4 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=8 ttl=51 time=14.4 ms

    2. GWLB の任意のバックエンド ECS インスタンスで、コマンドラインウィンドウを開き、tcpdump -i any port 6081 を実行して、ポート 6081 のすべてのパケットをキャプチャします。

      出力には、アプリケーションサーバー ECS インスタンスからのリクエストパケットとレスポンスパケットが表示され、アプリケーションサーバーからのアウトバウンドトラフィックが GWLB バックエンドネットワーク仮想アプライアンスを通過して検査およびパススルーされていることが確認できます。

      10:15:18.247012 IP 10.0.1.41.32236 > iZ0jlgsxxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo request, id 9, seq 8, length 64
10:15:18.247028 IP iZ0jlgsxxx > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo request, id 9, seq 8, length 64
10:15:18.261183 IP 10.0.1.41.32236 > iZ0jlgsxxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo reply, id 9, seq 8, length 64
10:15:18.261192 IP iZ0jlgsxxx.32236 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo reply, id 9, seq 8, length 64
10:15:19.248397 IP 10.0.1.41.32236 > iZ0jlgsxxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo request, id 9, seq 9, length 64
10:15:19.248419 IP iZ0jlgxxx.32236 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo request, id 9, seq 9, length 64
10:15:19.262605 IP 10.0.1.41.32236 > iZ0jlgxxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo reply, id 9, seq 9, length 64
10:15:19.262613 IP iZ0jlgxxx.32236 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo reply, id 9, seq 9, length 64

    関連ドキュメント

    • GWLB 課金概要：GWLB は従量課金です。費用には GWLB インスタンス料金と LCU 料金が含まれます。

    • PrivateLink 課金：GWLB はサービス提供に GWLBe が必要です。GWLBe の料金は、PrivateLink サービスによって個別に設定され、課金されます。

    • GWLB をデプロイする際は、次の機能を有効にしてください：

      • GWLB ヘルスチェック：バックエンドネットワーク仮想アプライアンスの可用性を検出します。デバイスに障害が発生した場合、新しいリクエストは正常なバックエンドデバイスに自動的にルーティングされます。

      • 接続ドレイン：バックエンドネットワーク仮想アプライアンスを削除する際に、既存の接続をスムーズに処理します。

      • 既存トラフィックのリバランス：バックエンドネットワーク仮想アプライアンスに障害が発生、または削除された場合、GWLB は既存トラフィックを正常なバックエンドデバイスに再ルーティングし、サービス中断を防止します。

    • PrivateLink と IPv4 ゲートウェイの詳細については、以下をご参照ください：