サードパーティ アプライアンスのための内部 TCP / UDP 負荷分散の設定

このガイドでは、サンプルを示しながら、Google Cloud Platform の内部 TCP / UDP ロードバランサをネクストホップとして構成する方法を説明します。このガイドに進む前に、次の内容を理解しておいてください。

権限

このガイドを使用する前に、インスタンスを作成し、プロジェクト内のネットワークを変更しておく必要があります。そのためにはプロジェクトの所有者または編集者であるか、または次の Compute Engine IAM の役割をすべて持っている必要があります。

タスク 必要な役割
ネットワーク、サブネット、負荷分散コンポーネントの作成 ネットワーク管理者
ファイアウォール ルールの追加と削除 セキュリティ管理者
インスタンスの作成 インスタンス管理者

設定

このガイドでは、拡張静的ルートのネクストホップとして内部 TCP / UDP ロードバランサを使用して、スケールアウトされた仮想アプライアンスを統合する方法について説明します。

このガイドで説明するソリューションには仮想アプライアンスが統合されています。仮想アプライアンスにトラフィックを送信するために、クライアントを明示的に再構成する必要はありません。この設定ガイドの例では、負荷分散された一連のファイアウォール仮想アプライアンスを介してすべての East-West トラフィックを送信します。

このセクションでは、次のリソースの構成方法について説明します。

  • サンプルの VPC ネットワークとカスタム サブネット
  • バックエンド VM への受信接続を許可する GCP ファイアウォール ルール
  • カスタム静的ルート
  • 接続のテストに使用する 1 台のクライアント VM
  • 内部 TCP / UDP ロードバランサの次のコンポーネント:
    • マネージド インスタンス グループのバックエンド VM
    • バックエンド VM アプライアンスのヘルスチェック
    • us-west1 リージョンの内部バックエンド サービス。バックエンド VM 間の接続分散を管理します。
    • ロードバランサのフロントエンドの内部転送ルールと内部 IP アドレス

トポロジの概要は次のとおりです。

内部 TCP / UDP 負荷分散の East-West ネスクトホップの例（クリックして拡大）
内部 TCP / UDP 負荷分散の East-West ネスクトホップの例（クリックして拡大）

この例で作成するリソースは次のとおりです。

  • 内部の TCP / UDP ロードバランサの背後にあるアプリケーション インスタンス。ここでは、ファイアウォール アプライアンス ソフトウェアを実行している VM です（この例では fr-ilb です）。アプリケーション インスタンスには内部（RFC 1918）の IP アドレスのみが設定されています。
  • 各アプリケーション インスタンスで [can-ip-forward](/vpc/docs/using-routes#canipforward) フラグが有効になっています。デフォルトでは、Compute Engine VM は VM 自身が送信したパケットのみを送信します。つまり、パケットの送信元 IP アドレスが VM の IP アドレスのいずれかと一致します。can-ip-forward を使用すると、アプリケーション インスタンスは別のノードから送信されたパケットを転送できるようになります。
  • ロードバランサの転送ルール fr-ilb に宛先 10.50.1.0/24 とネクストホップが設定されたカスタム静的ルート。

トラフィック フローは次の図のようになります。

  • プロビジョニング トラフィックがサブネットに送信されます。本番環境の VPC ネットワークのプライマリ IP 範囲として 10.50.1.0/24 が使用されます。トラフィックはロードバランサ経由でルーティングされます。
  • 設定されたセッション アフィニティに基づいて、ロードバランサがいずれかのアプリケーション インスタンスにトラフィックを転送します（セッション アフィニティは TCP トラフィックにのみに適用されます）。
  • production VPC ネットワークのインスタンス グループにパケットを配信するため、アプリケーション インスタンスがソース ネットワーク アドレス変換（SNAT）を実行します。戻りトラフィックに対しては、transit VPC ネットワークのクライアント インスタンスにパケットを配信するため、宛先ネットワーク アドレス変換（DNAT）を実行します。

追加のユースケースについては、ネクストホップとしての内部 TCP / UDP ロードバランサのコンセプトをご覧ください。

次の図に、負荷分散リソースとネットワーク トポロジの詳細を示します。

内部 TCP / UDP 負荷分散の East-West ネスクトホップの例（クリックして拡大）
内部 TCP / UDP 負荷分散の East-West ネスクトホップの例（クリックして拡大）

ネットワーク、リージョン、サブネットの構成

この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。

  • ネットワーク: この例では、少なくとも 2 つのネットワークが必要です。それぞれに 1 つ以上のサブネットが必要です。各バックエンド サードパーティ アプライアンス VM には、VPC ネットワークごとに 1 つずつ、少なくとも 2 つのネットワーク インターフェースが必要です。この例のネットワークでは、transit と production というカスタムモードの VPC ネットワークがあります。この例の transit ネットワークに、クライアントとロードバランサがあります。production ネットワークには、宛先のターゲット VM が存在します。

  • リージョン: サブネットは us-west1 リージョンにあります。VM インスタンスはゾーンリソースであるため、サブネットは同じリージョン内に存在する必要があります。

  • サブネット: サブネット transit-subnet と production-subnet は、それぞれ 10.30.1.0/24 と 10.50.1.0/24 のプライマリ IP アドレス範囲を使用します。

ネットワークとサブネットを作成する手順は次のとおりです。

Console

transit ネットワークと transit-subnet を作成します。

  1. Google Cloud Platform Console で [VPC ネットワーク] ページに移動します。
    [VPC ネットワーク] ページに移動
  2. [VPC ネットワークを作成] をクリックします。
  3. [名前] に「transit」と入力します。
  4. [サブネット] セクションで次の設定を行います。
    • [サブネット作成モード] を [カスタム] に設定します。
    • [新しいサブネット] セクションに、次の情報を入力します。
      • 名前: transit-subnet
      • リージョン: us-west1
      • IP アドレス範囲: 10.30.1.0/24
      • [完了] をクリックします。
  5. [作成] をクリックします。

production ネットワークと production-subnet を作成します。

  1. Google Cloud Platform Console で [VPC ネットワーク] ページに移動します。
    [VPC ネットワーク] ページに移動
  2. [VPC ネットワークを作成] をクリックします。
  3. [名前] に「production」と入力します。
  4. [サブネット] セクションで次の設定を行います。
    • [サブネット作成モード] を [カスタム] に設定します。
    • [新しいサブネット] セクションに、次の情報を入力します。
      • 名前: production-subnet
      • リージョン: us-west1
      • IP アドレス範囲: 10.50.1.0/24
      • [完了] をクリックします。
  5. [作成] をクリックします。

gcloud

  1. カスタム VPC ネットワークを作成します。

    gcloud compute networks create transit --subnet-mode=custom

    gcloud compute networks create production --subnet-mode=custom

  2. us-west1 リージョンの transit ネットワークと production ネットワークにサブネットを作成します。

    gcloud compute networks subnets create transit-subnet \
    --network=transit \
    --range=10.30.1.0/24 \
    --region=us-west1

    gcloud compute networks subnets create production-subnet \
    --network=production \
    --range=10.50.1.0/24 \
    --region=us-west1

ファイアウォール ルールの構成

この例では、次のファイアウォール ルールを使用します。

  • fw-allow-transit-subnet: transit ネットワークのすべてのターゲットに適用される上りルール。10.30.1.0/24 範囲の送信元からのトラフィックを許可します。このルールにより、transit-subnet 内のクライアントとサードパーティ VM アプライアンスの通信が可能になります。

  • fw-allow-production-subnet: production ネットワークのすべてのターゲットに適用される上りルール。10.50.1.0/24 範囲の送信元からのトラフィックを許可します。このルールにより、production-subnet 内のサードパーティ VM アプライアンスと宛先のターゲット VM の通信が可能になります。

  • fw-allow-transit-ssh: 負荷分散されているインスタンスに適用される上りルール。TCP ポート 22 で任意のアドレスからの SSH 接続を受信できます。このルールには、送信元の IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、allow-ssh というターゲットタグを使用して、ファイアウォール ルールが適用される VM を識別します。

  • fw-allow-health-check: 負荷分散されたサードパーティ VM アプライアンスに適用される上りルール。GCP ヘルスチェック システム（130.211.0.0/22 と 35.191.0.0/16 からのトラフィックを許可します。この例では、allow-health-check というターゲットタグを使用して、適用するインスタンスを識別します。

これらのファイアウォール ルールを使用しないと、デフォルトの上り拒否ルールが適用され、バックエンド インスタンスへの受信トラフィックがブロックされます。GCP プローブ システムの IP 範囲からのヘルスチェックを許可するには、ファイアウォール ルールを作成する必要があります。詳細については、プローブの IP 範囲をご覧ください。

Console

  1. Google Cloud Platform Console で [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールを作成] クリックして次の情報を入力し、サブネット トラフィックを許可するルールを作成します。
    • 名前: fw-allow-transit-subnet
    • ネットワーク: transit
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: ネットワーク内のすべてのインスタンス
    • ソースフィルタ: IP ranges
    • ソース IP の範囲: 10.30.1.0/24
    • プロトコルとポート: すべて許可
  3. [作成] をクリックします。
  4. [ファイアウォール ルールを作成] クリックして次の情報を入力し、サブネット トラフィックを許可するルールを作成します。
    • 名前: fw-allow-production-subnet
    • ネットワーク: production
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: ネットワーク内のすべてのインスタンス
    • ソースフィルタ: IP ranges
    • ソース IP の範囲: 10.50.1.0/24
    • プロトコルとポート: すべて許可
  5. [作成] をクリックします。
  6. [ファイアウォール ルールを作成] を再度クリックして、SSH 接続の受信を許可するルールを作成します。
    • 名前: fw-allow-transit-ssh
    • ネットワーク: transit
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: allow-ssh
    • ソースフィルタ: IP ranges
    • ソース IP の範囲: 0.0.0.0/0
    • プロトコルとポート: 指定されたプロトコルとポートを選択して、「tcp:22」と入力します。
  7. [作成] をクリックします。
  8. [ファイアウォール ルールを作成] をもう一度クリックして、GCP ヘルスチェックを許可するルールを作成します。
    • 名前: fw-allow-health-check
    • ネットワーク: transit
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: allow-health-check
    • ソースフィルタ: IP ranges
    • ソース IP の範囲: 130.211.0.0/22 と 35.191.0.0/16
    • プロトコルとポート: すべて許可
  9. [作成] をクリックします。

gcloud

  1. fw-allow-transit-subnet ファイアウォール ルールを作成して、サブネットとの通信を許可します。

    gcloud compute firewall-rules create fw-allow-transit-subnet \
    --network=transit \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24 \
    --rules=tcp,udp,icmp

  2. fw-allow-production-subnet ファイアウォール ルールを作成して、サブネットとの通信を許可します。

    gcloud compute firewall-rules create fw-allow-production-subnet \
    --network=production \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.50.1.0/24 \
    --rules=tcp,udp,icmp

  3. fw-allow-transit-ssh ファイアウォール ルールを作成して、ネットワーク タグ allow-ssh を指定し、VM への SSH 接続を許可します。source-ranges を省略すると、GCP は任意の送信元としてルールを解釈します。

    gcloud compute firewall-rules create fw-allow-transit-ssh \
    --network=transit \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  4. fw-allow-health-check ルールを作成して、transit ネットワークのサードパーティ アプライアンス VM に対する GCP ヘルスチェックを許可します。

    gcloud compute firewall-rules create fw-allow-transit-health-check \
    --network=transit \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp,udp,icmp

宛先インスタンスの作成

次に、production VPC ネットワークの production-subnet（10.50.1.0/24）に IP アドレス 10.50.1.2 の宛先インスタンスを作成します。

Console

  1. Google Cloud Platform Console の [VM インスタンス] ページに移動します。
    [VM インスタンス] ページに移動
  2. VM の名前として「destination-instance」と入力します。
  3. リージョンに us-west1 を選択し、ゾーンに us-west1-a を選択します。
  4. [ブートディスク] セクションで、選択したイメージが Debian GNU/Linux 9 Stretch であることを確認します。イメージを変更するには、[選択] をクリックします。

  5. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックし、次の変更を行います。

    • [ネットワーク] をクリックして、次のネットワーク タグ allow-ssh を追加します。
    • [ネットワーク インターフェース] にある編集ボタンをクリックして、次の変更を行い、[完了] をクリックします。
      • ネットワーク: production
      • サブネット: production-subnet
      • プライマリ内部 IP: エフェメラル（カスタム）
      • カスタムのエフェメラル IP アドレス: 10.50.1.2
      • 外部 IP: エフェメラル

    • [管理] をクリックします。[起動スクリプト] フィールドに、次のスクリプトの内容をコピーして貼り付けます。スクリプトの内容は 4 つの VM ですべて同じです。

      #! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2

  6. [作成] をクリックします。

gcloud

  1. 次のコマンドを実行して、VM を作成します。

    gcloud compute instances create destination-instance \
    --zone=us-west1-a \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=production-subnet \
    --private-network-ip 10.50.1.2 \
    --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

サードパーティ仮想アプライアンスの作成

次に、iptables ソフトウェアをサードパーティの仮想アプライアンスとして使用して、インスタンス テンプレートとマネージド リージョン インスタンス グループを作成します。

Console

複数のネットワーク インターフェースを含むインスタンス テンプレートを作成する必要があるため、このステップでは gcloud を使用します。GCP Console では、複数のネットワーク インターフェースを含むインスタンス テンプレートを作成できません。

gcloud

  1. サードパーティ仮想アプライアンスのインスタンス テンプレートを作成します。インスタンス テンプレートに --can-ip-forward フラグを追加します。これにより、テンプレートから作成された VM インスタンスが transit ネットワークと production ネットワークの他のインスタンスからパケットを転送できるようになります。

    gcloud compute instance-templates create third-party-template \
    --region=us-west1 \
    --network-interface subnet=transit-subnet,address="" \
    --network-interface subnet=production-subnet \
    --tags=allow-ssh,allow-health-check \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --can-ip-forward \
    --metadata=startup-script='#! /bin/bash
    # Enable IP forwarding:
    echo 1 > /proc/sys/net/ipv4/ip_forward
    echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
    # Read VM network configuration:
    md_vm="http://169.254.169.254/computeMetadata/v1/instance/"
    md_net="$md_vm/network-interfaces"
    nic0_gw="$(curl -H "Metadata-Flavor:Google" $md_net/0/gateway)"
    nic0_mask="$(curl -H "Metadata-Flavor:Google" $md_net/0/subnetmask)"
    nic1_gw="$(curl -H "Metadata-Flavor:Google" $md_net/1/gateway)"
    nic1_mask="$(curl -H "Metadata-Flavor:Google" $md_net/1/subnetmask)"
    nic1_addr="$(curl -H "Metadata-Flavor:Google" $md_net/1/ip)"
    # Start iptables:
    /sbin/iptables -t nat -F
    /sbin/iptables -t nat -A POSTROUTING \
    -s "$nic0_gw/$nic0_mask" \
    -d "$nic1_gw/$nic1_mask" \
    -o eth1 \
    -j SNAT \
    --to-source "$nic1_addr"
    /sbin/iptables-save
    # Use a web server to pass the health check for this example.
    # You should use a more complete test in production.
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    echo "Example web page to pass health check" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

  2. サードパーティ仮想アプライアンスのマネージド インスタンス グループを作成します。このコマンドは、us-west1 内でリージョン マネージド インスタンス グループを作成し、自動的にスケーリングします。

    gcloud compute instance-groups managed create third-party-instance-group \
    --region us-west1 \
    --template=third-party-template \
    --size=3

負荷分散リソースの作成

この手順では、ヘルスチェックとバックエンド サービス、フロントエンド コンポーネントなどの内部 TCP / UDP ロードバランサ コンポーネントを構成します。

  • ヘルスチェック: この例では、HTTP ヘルスチェックで HTTP 200（OK）レスポンスを確認します。詳細については、内部 TCP / UDP 負荷分散の概要のヘルスチェックのセクションをご覧ください。

  • バックエンド サービス: この例のバックエンド サービスは TCP プロトコルを指定しますが、ロードバランサがルートのネクストホップの場合、TCP トラフィックと UDP トラフィックの両方がロードバランサのバックエンドに送信されます。

  • 転送ルール: TCP ポート 80 が指定されていても、ロードバランサがルートのネクストホップの場合、TCP ポートまたは UDP ポートのトラフィックがロードバランサのバックエンドに送信されます。

  • 内部 IP アドレス: この例では、転送ルールに内部 IP アドレス 10.30.1.99 を指定します。

Console

ロードバランサの作成とバックエンド サービスの構成

  1. Google Cloud Platform Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. [ロードバランサを作成] をクリックします。
  3. [TCP 負荷分散] で [設定を開始] をクリックします。
  4. [インターネット接続または内部専用] で [VM 間のみ] を選択します。
  5. [続行] をクリックします。
  6. 名前を be-ilb に設定します。
  7. [バックエンドの設定] をクリックして、次の変更を行います。
    1. リージョン: us-west1
    2. ネットワーク: transit
    3. [バックエンド] の [新しいアイテム] セクションで、third-party-instance-group インスタンス グループを選択し、[完了] をクリックします。
    4. [ヘルスチェック] で [別のヘルスチェックを作成] を選択し、次の情報を入力して [保存して次へ] をクリックします。
      • 名前: hc-http-80
      • プロトコル: HTTP
      • ポート: 80
      • プロキシ プロトコル: NONE
      • リクエストパス: /
    5. 続行する前に、[バックエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
  8. [フロントエンドの設定] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
    1. 名前: fr-ilb
    2. サブネットワーク: transit-subnet
    3. [内部 IP] から、[静的内部 IP アドレスの予約] を選択し、以下の情報を入力して [予約] をクリックします。
      • 名前: ip-ilb
      • 静的 IP アドレス: 選択を許可
      • カスタム IP アドレス: 10.30.1.99
    4. ポート: [単一] を選択して、ポート番号に「80」を入力します。ロードバランサに選択したプロトコルとポートにより、ロードバランサがルートのネクストホップの場合に使用されるプロトコルやポートが制限されることはありません。
    5. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
  9. [確認と完了] をクリックします。設定を再度確認します。
  10. [作成] をクリックします。

gcloud

  1. 新しい HTTP ヘルスチェックを作成して、ポート 80 で VM との TCP 接続をテストします。

    gcloud compute health-checks create http hc-http-80 \
    --port=80

  2. us-west1 リージョンに内部バックエンド サービスを作成します。

    gcloud compute backend-services create be-ilb \
    --load-balancing-scheme=internal \
    --region=us-west1 \
    --health-checks=hc-http-80

  3. サードパーティ仮想アプライアンスを含むインスタンス グループをバックエンドとしてバックエンド サービスに追加します。

    gcloud compute backend-services add-backend be-ilb \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

  4. 内部転送ルールを作成し、バックエンド サービスに接続してロードバランサの設定を完了します。内部ロードバランサのプロトコル（TCP）とポート（80）によって、ロードバランサがルートのネクストホップとして使用される場合にバックエンド インスタンス（サードパーティ仮想アプライアンス）に転送されるポートとプロトコルが制限されることはありません。

    gcloud compute forwarding-rules create fr-ilb \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=transit \
    --subnet=transit-subnet \
    --region=us-west1 \
    --backend-service=be-ilb \
    --address=10.30.1.99

ネクストホップとしてロードバランサを定義する静的ルートの作成

静的ルートを作成する場合、next-hop-address を使用してロードバランサの転送ルールの IP アドレスを参照することはできません。next-hop-address を使用すると、GCP はその IP アドレスに割り当てられた VM インスタンスにトラフィックを転送しますが、ロードバランサは VM インスタンスではありません。ロードバランサをネクストホップとして指定する場合は、この例で示すように next-hop-ilb フラグを使用する必要があります。

Console

  1. Google Cloud Platform Console で [ルート] ページに移動します。
    [ルート] ページに移動
  2. [ルートを作成] をクリックします。
  3. ルートの名前として「ilb-nhop-default」と入力します。
  4. transit ネットワークを選択します。
  5. [宛先 IP の範囲] に「10.50.1.0/24」と入力します。
  6. この機能ではタグはサポートされていません。タグは指定しないでください。
  7. ルートのネクストホップで、[内部 TCP/UDP ロードバランサの転送ルールを指定する] を選択します。
  8. ネクストホップ リージョンに us-west1 を選択します。
  9. 転送ルール名に fr-ilb を選択します。
  10. [作成] をクリックします。

gcloud

ネストホップにロードバランサの転送ルールを設定し、宛先範囲をルート 10.50.1.0/24 に設定して、高度なルートを作成します。

gcloud beta compute routes create ilb-nhop-default \
    --network=transit \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=fr-ilb \
    --next-hop-ilb-region=us-west1

クライアント VM の作成

この例では、transit VPC ネットワーク内のロードバランサと同じリージョンにクライアント VM（vm-client）を作成します。このクライアントは、ネクストホップの仕組みを説明するために使用します。

Console

  1. Google Cloud Platform Console の [VM インスタンス] ページに移動します。
    [VM インスタンス] ページに移動
  2. [インスタンスを作成] をクリックします。
  3. 名前を vm-client に設定します。
  4. ゾーンを us-west1-a に設定します。
  5. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックし、次の変更を行います。
    • [ネットワーク] をクリックして、ネットワーク タグに allow-ssh を設定します。
    • [ネットワーク インターフェース] にある編集ボタンをクリックして、次の変更を行い、[完了] をクリックします。
      • ネットワーク: transit
      • サブネット: transit-subnet
      • プライマリ内部 IP: エフェメラル（自動）
      • 外部 IP: エフェメラル
  6. [作成] をクリックします。

gcloud

クライアント VM はロードバランサと同じリージョンの任意のゾーン内にあり、そのリージョン内の任意のサブネットを使用できます。この例では、クライアントは us-west1-a ゾーンにあり、プライマリ VM とバックアップ VM が使用するサブネットと同じサブネットを使用します。

gcloud compute instances create vm-client \
    --zone=us-west1-a \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=transit-subnet

テスト

このテストでは、transit VPC ネットワークのクライアント VM から production VPC ネットワークのサンプル VM に接続します。ロードバランサは、ロードバランサの IP アドレスに送信するのではなく、ロードバランサ経由でパケットを宛先 10.50.1.2 に送信するため、ネクストホップとしても使用されます。

この例では、ロードバランサの正常なバックエンド アプライアンス VM の iptables ソフトウェアがパケットの NAT を処理します。

  1. クライアント VM インスタンスに接続します。

    gcloud compute ssh vm-client --zone=us-west1-a

  2. curl を使用して、宛先インスタンスのウェブサーバー ソフトウェアにウェブ リクエストを送信します。予想される出力は、宛先インスタンスのインデックス ページの内容です（Page served from: destination-instance）。

    curl http://10.50.1.2

次のステップ

このページは役立ちましたか？評価をお願いいたします。

フィードバックを送信...

このページ
ドキュメントのフィードバック
負荷分散
サービスのフィードバック