プロキシ ネットワーク ロードバランサを IPv6 に変換する

このドキュメントでは、プロキシ ネットワーク ロードバランサのリソースとバックエンドを IPv4 のみ（シングルスタック）から IPv4 と IPv6（デュアルスタック）に移行する方法について説明します。IPv6 を使用する主な利点は、はるかに大きな IP アドレスプールをロードバランサに割り振ることができることです。インバウンド IPv6 トラフィックを終端し、必要に応じて IPv4 または IPv6 接続を介してこのトラフィックをバックエンドに送信するようにロードバランサを構成できます。詳細については、アプリケーション ロードバランサとプロキシ ネットワーク ロードバランサの IPv6 をご覧ください。

このドキュメントでは、IPv4 のみ（シングルスタック）は IPv4 アドレスのみを使用するリソースを指し、IPv4 と IPv6（デュアルスタック）は IPv4 アドレスと IPv6 アドレスの両方を使用するリソースを指します。

このドキュメントの手順は、TCP と SSL の両方のプロキシ ネットワーク ロードバランサに適用されます。

始める前に

変換プロセスを開始する前に、次の条件に注意してください。

  • 次のいずれかのタイプのプロキシ ネットワーク ロードバランサを使用している必要があります。

    • グローバル外部プロキシ ネットワーク ロードバランサ
    • リージョン外部プロキシ ネットワーク ロードバランサ
    • クロスリージョン内部プロキシ ネットワーク ロードバランサ
    • リージョン内部プロキシ ネットワーク ロードバランサ

    従来のプロキシ ネットワーク ロードバランサは、デュアルスタック バックエンドまたはサブネットをサポートしていません。IPv6 サポートの詳細については、アプリケーション ロードバランサとプロキシ ネットワーク ロードバランサの IPv6 をご覧ください。

  • ロードバランサは、VM インスタンス グループ バックエンドまたは GCE_VM_IP_PORT エンドポイントを含むゾーン ネットワーク エンドポイント グループ（NEG）を使用しています。他のバックエンド タイプはデュアルスタックをサポートしていません。

また、変換プロセスはロードバランサのタイプによって異なります。

  • グローバル外部プロキシ ネットワーク ロードバランサの場合、バックエンドをデュアルスタックに変換し、受信 IPv6 トラフィックを処理できる IPv6 転送ルールを作成します。

  • クロスリージョン内部プロキシ ネットワーク ロードバランサ、リージョン外部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサの場合は、バックエンドをデュアルスタックに変換するだけです。これらのロードバランサでは、IPv6 転送ルールはサポートされていません。

グローバル外部プロキシ ネットワーク ロードバランサの設定方法については、次のドキュメントをご覧ください。

変換するリソースを特定する

ロードバランサが関連付けられているリソースの名前をメモします。これらの名前は後で指定する必要があります。

  1. すべてのサブネットを一覧取得するには、gcloud compute networks subnets list コマンドを使用します。

    gcloud compute networks subnets list

    デュアルスタックに変換する IPv4 のみのスタックを持つサブネットの名前をメモします。以下では、この名前を SUBNET で表します。以下では、この VPC ネットワークを NETWORK で表します。

  2. すべてのバックエンド サービスを一覧取得するには、gcloud compute backend-services list コマンドを使用します。

    gcloud compute backend-services list

    デュアルスタックに変換するバックエンド サービスの名前をメモします。以下では、この名前を BACKEND_SERVICE で表します。

  3. ロードバランサがすでにある場合は、バックエンドの IP スタックタイプを確認するために、gcloud compute instances list コマンドを使用します。

    gcloud compute instances list \
    --format= \
    "table(
    name,
    zone.basename(),
    networkInterfaces[].stackType.notnull().list(),
    networkInterfaces[].ipv6AccessConfigs[0].externalIpv6.notnull().list():label=EXTERNAL_IPV6,
    networkInterfaces[].ipv6Address.notnull().list():label=INTERNAL_IPV6)"

  4. すべての VM インスタンスとインスタンス テンプレートを一覧取得するには、gcloud compute instances list コマンドと gcloud compute instance-templates list コマンドを使用します。

    gcloud compute instances list

    gcloud compute instance-templates list

    デュアルスタックに変換するインスタンスとインスタンス テンプレートの名前をメモします。以下では、これらの名前をそれぞれ VM_INSTANCE、INSTANCE_TEMPLATES で表します。

  5. すべてのインスタンス グループを一覧取得するには、gcloud compute instance-groups list コマンドを使用します。

    gcloud compute instance-groups list

    デュアルスタックに移行するネットワーク エンドポイント グループの名前をメモします。以下では、この名前を INSTANCE_GROUP で表します。

  6. すべてのゾーン NEG を一覧取得するには、gcloud compute network-endpoint-groups list コマンドを使用します。

    gcloud compute network-endpoint-groups list

    デュアルスタックに移行するネットワーク エンドポイント グループの名前をメモします。以下では、この名前を ZONAL_NEG で表します。

  7. すべてのターゲット SSL プロキシを一覧取得するには、gcloud compute target-ssl-proxies list コマンドを使用します。

    gcloud compute target-ssl-proxies list

    ロードバランサに関連付けられているターゲット プロキシの名前をメモします。以下では、この名前を TARGET_PROXY で表します。

  8. すべてのターゲット TCP プロキシを一覧取得するには、gcloud compute target-tcp-proxies list コマンドを使用します。

    gcloud compute target-tcp-proxies list

    ロードバランサに関連付けられているターゲット プロキシの名前をメモします。以下では、この名前を TARGET_PROXY で表します。

シングルスタック バックエンドからデュアルスタック バックエンドに変換する

このセクションでは、IPv4 のみ（シングルスタック）アドレスを使用するロードバランサ リソースとバックエンドを IPv4 と IPv6（デュアルスタック）アドレスに変換する方法について説明します。

サブネットを更新する

デュアルスタック サブネットは、カスタムモード VPC ネットワークでのみサポートされます。自動モード VPC ネットワークや以前のネットワークではサポートされません。自動モードのネットワークは初期の試験運用には役立ちますが、ほとんどの本番環境にはカスタムモードの VPC が適しています。カスタムモードで VPC を使用することをおすすめします。

VPC の設定をデュアルスタックに更新する手順は次のとおりです。

  1. 自動モードの VPC ネットワークを使用している場合は、まず、自動モードの VPC ネットワークをカスタムモードに変換する必要があります。

    default ネットワークを使用している場合は、カスタムモードの VPC ネットワークに変換する必要があります。

  2. IPv6 を有効にする方法については、サブネットのスタックタイプをデュアルスタックに変更するをご覧ください。

    サブネットの IPv6 アクセスタイプが External に設定されていることを確認します。

  3. 省略可: このネットワークのサブネットで内部 IPv6 アドレス範囲を構成する場合は、次の手順を完了します。

    1. [VPC ネットワーク ULA の内部 IPv6 範囲] で、[有効] を選択します。

    2. [Allocate internal IPv6 range] で、[自動] または [手動] を選択します。

      [手動] を選択した場合は、fd20::/20 の範囲内の /48 の範囲を入力します。範囲が使用されている場合は、別の範囲を指定するように求めるプロンプトが表示されます。

プロキシ専用サブネットを更新する

Envoy ベースのロードバランサを使用している場合は、プロキシ専用サブネットのスタックタイプをデュアルスタックに変更することをおすすめします。プロキシ専用サブネットをサポートするロードバランサについては、サポートされているロードバランサをご覧ください。

プロキシ専用サブネットのスタックタイプをデュアルスタックに変更する手順は次のとおりです。

コンソール

  1. Google Cloud コンソールの [VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. [VPC ネットワークの詳細] ページを表示するには、ネットワークの名前をクリックします。

  3. [サブネット] タブをクリックします。

  4. [ロード バランシング用に予約されているプロキシ専用サブネット] セクションで、変更するプロキシ専用サブネットの名前をクリックします。

  5. [サブネットの詳細] ページで、[編集] をクリックします。

  6. [IP スタックタイプ] には、[IPv4 と IPv6（デュアルスタック）] を選択します。[IPv6 アクセスタイプ] を [内部] に設定します。

  7. [保存] をクリックします。

gcloud

subnets update コマンドを使用します。

gcloud compute networks subnets update PROXY_ONLY_SUBNET \
    --stack-type=IPV4_IPV6 \
    --ipv6-access-type=INTERNAL \
    --region=REGION

次のように置き換えます。

  • PROXY_ONLY_SUBNET: プロキシ専用サブネットの名前。
  • REGION: サブネットのリージョン。
  • IPv6_ACCESS_TYPE: サブネットの IPv6 アクセスタイプ（INTERNAL）。

VM インスタンスまたはテンプレートを更新する

VM が接続されているサブネットに IPv6 範囲が構成されている場合は、VM インスタンスに IPv6 アドレスを構成できます。IPv6 アドレスをサポートできるのは、次のバックエンドのみです。

  • インスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • ゾーン NEG: 1 つ以上の GCE_VM_IP_PORT のゾーン NEG。

VM インスタンスを更新する

マネージド インスタンス グループまたは非マネージド インスタンス グループに属する VM インスタンスは編集できません。VM インスタンスをデュアルスタックに更新する手順は次のとおりです。

  1. グループから特定のインスタンスを削除する
  2. デュアルスタック VM を作成する
  3. MIG に特定の名前のインスタンスを作成する

VM インスタンス テンプレートを更新する

既存のインスタンス テンプレートを更新することはできません。変更が必要な場合は、同様のプロパティを持つ別のテンプレートを作成します。VM インスタンス テンプレートをデュアルスタックに更新する手順は次のとおりです。

コンソール

  1. Google Cloud コンソールで、[インスタンス テンプレート] ページに移動します。

    [インスタンス テンプレート] に移動

    1. コピーして更新するインスタンス テンプレートをクリックします。
    2. [同様のものを作成] をクリックします。
    3. [詳細オプション] セクションを開きます。
    4. [ネットワーク タグ] に「allow-health-check-ipv6」と入力します。
    5. [ネットワーク インターフェース] セクションで、[ネットワーク インターフェースを追加] をクリックします。
    6. [ネットワーク] リストで、カスタムモードの VPC ネットワークを選択します。
    7. [サブネットワーク] リストで、SUBNET を選択します。
    8. [IP スタックタイプ] には、[IPv4 と IPv6（デュアルスタック）] を選択します。
    9. [作成] をクリックします。

  2. ロードバランサに関連付けられたマネージド インスタンス グループ MIG で基本のローリング アップデートを開始します。

ゾーン NEG を更新する

ゾーン NEG エンドポイントは編集できません。IPv4 エンドポイントを削除し、IPv4 アドレスと IPv6 アドレスの両方を持つ新しいデュアルスタック エンドポイントを作成する必要があります。

REGION_A リージョンにゾーン NEG（GCE_VM_IP_PORT タイプのエンドポイントを含む）を設定するには、まず GCP_NEG_ZONE ゾーンに VM を作成します。次に、VM ネットワーク エンドポイントをゾーン NEG に追加します。

VM を作成する

コンソール

  1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. [インスタンスを作成] をクリックします。

  3. [名前] を vm-a1 に設定します。

  4. [リージョン] に REGION_A を選択し、[ゾーン] フィールドに任意の値を選択します。この手順では、このサブネットを GCP_NEG_ZONE で表しています。

  5. [ブートディスク] セクションで、ブートディスク オプションとして Debian GNU/Linux 12 (bookworm) が選択されていることを確認します。必要に応じて [選択] をクリックし、イメージを変更します。

  6. [詳細オプション] セクションを開き、次の変更を行います。

    • [ネットワーキング] セクションを開きます。
    • [ネットワーク タグ] フィールドに「allow-health-check」と入力します。
    • [ネットワーク インターフェース] セクションで、次の変更を行います。
      • ネットワーク: NETWORK
      • サブネット: SUBNET
      • IP スタックタイプ: IPv4 と IPv6（デュアルスタック）
    • [完了] をクリックします。

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

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

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

  8. 以下の手順を繰り返し、次の名前とゾーンの組み合わせを使用して、2 つ目の VM を作成します。

    • 名前: vm-a2、ゾーン: GCP_NEG_ZONE

gcloud

VM とそのゾーンの名前にこれらの組み合わせを使用して、次のコマンドを 2 回実行して VM を作成します。スクリプトの内容は両方の VM で同じです。

  • vm-a1 の VM_NAME と任意の GCP_NEG_ZONE ゾーン。

  • vm-a2 の VM_NAME と同じ GCP_NEG_ZONE ゾーン。

    gcloud compute instances create VM_NAME \
    --zone=GCP_NEG_ZONE \
    --stack-type=IPV4_IPV6 \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-health-check \
    --subnet=SUBNET \
    --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://metadata.google.internal/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2'

ゾーン NEG にエンドポイントを追加する

コンソール

ゾーン NEG にエンドポイントを追加します。

  1. Google Cloud コンソールで、[ネットワーク エンドポイント グループ] ページに移動します。

    [ネットワーク エンドポイント グループ] に移動

  2. [名前] リストで、ネットワーク エンドポイント グループの名前（ZONAL_NEG）をクリックします。[ネットワーク エンドポイント グループの詳細] ページが表示されます。

  3. [このグループのネットワーク エンドポイント] セクションで、以前に作成した NEG エンドポイントを選択します。[エンドポイントを削除] をクリックします。

  4. [このグループのネットワーク エンドポイント] セクションで [ネットワーク エンドポイントを追加] をクリックします。

  5. VM インスタンスを選択します。

  6. [ネットワーク インターフェース] セクションに、VM の名前、ゾーン、サブネットが表示されます。

  7. [IPv4 アドレス] フィールドに、新しいネットワーク エンドポイントの IPv4 アドレスを入力します。

  8. [IPv6 アドレス] フィールドに、新しいネットワーク エンドポイントの IPv6 アドレスを入力します。

  9. ポートタイプを選択します。

    1. [デフォルト] を選択すると、エンドポイントはネットワーク エンドポイント グループのすべてのエンドポイントにデフォルト ポート 80 を使用します。この例では、Apache サーバーがポート 80 でリクエストを配信しているため、これで十分です。
    2. [カスタム] を選択した場合は、使用するエンドポイントのポート番号を入力します。

  10. 他のエンドポイントを追加するには、[ネットワーク エンドポイントを追加] をクリックし、前の手順を繰り返します。

  11. すべてのエンドポイントを追加したら、[作成] をクリックします。

gcloud

  1. エンドポイント（GCE_VM_IP_PORT エンドポイント）を ZONAL_NEG に追加します。

    gcloud compute network-endpoint-groups update ZONAL_NEG \
    --zone=GCP_NEG_ZONE \
    --add-endpoint='instance=vm-a1,ip=IPv4_ADDRESS, \
      ipv6=IPv6_ADDRESS,port=80' \
    --add-endpoint='instance=vm-a2,ip=IPv4_ADDRESS, \
      ipv6=IPv6_ADDRESS,port=80'

次のように置き換えます。

IPv4_ADDRESS: ネットワーク エンドポイントの IPv4 アドレス。この IPv4 は、Compute Engine の VM（プライマリ IP またはエイリアス IP 範囲の一部）に属している必要があります。IP アドレスが指定されていない場合は、ネットワーク エンドポイント グループが属するネットワーク内の VM インスタンスのプライマリ IP アドレスが使用されます。

IPv6_ADDRESS: ネットワーク エンドポイントの IPv6 アドレス。この IPv6 アドレスは、ネットワーク エンドポイント グループが属するネットワーク内の VM インスタンス（外部 IPv6 アドレス）に属している必要があります。

IPv6 ヘルスチェック プローブのファイアウォール ルールを作成する

Google Cloud プローブ システムの IP 範囲からのヘルスチェックを許可するには、ファイアウォール ルールを作成する必要があります。詳細については、プローブ IP 範囲をご覧ください。

上り（内向き）ルールが、ロードバランスされているインスタンスに適用され、 Google Cloud ヘルスチェック システムからのトラフィックを許可していることを確認します。この例では、ターゲットタグ allow-health-check-ipv6 を使用して、適用する VM インスタンスを識別します。

このファイアウォール ルールがない場合は、デフォルトの上り（内向き）拒否ルールによってバックエンド インスタンスへの受信 IPv6 トラフィックがブロックされます。

コンソール

  1. Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。

    [ファイアウォール ポリシー] に移動

  2. IPv6 サブネット トラフィックを許可するには、もう一度 [ファイアウォール ルールを作成] をクリックして、次の情報を入力します。

    • 名前: fw-allow-lb-access-ipv6
    • ネットワーク: NETWORK
    • 優先度: 1000
    • トラフィックの方向: 上り（内向き）
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: allow-health-check-ipv6
    • ソースフィルタ: IPv6 範囲

    • 送信元 IPv6 範囲

      • グローバル外部アプリケーション ロードバランサとグローバル外部プロキシ ネットワーク ロードバランサの場合は、「2600:2d00:1:b029::/64,2600:2d00:1:1::/64」を入力します。

      • クロスリージョン内部アプリケーション ロードバランサ、リージョン外部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサ、クロスリージョン内部プロキシ ネットワーク ロードバランサ、リージョン外部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサの場合は、「2600:2d00:1:b029::/64」を入力します。

    • プロトコルとポート: すべて許可

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

gcloud

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

    グローバル外部アプリケーション ロードバランサとグローバル外部プロキシ ネットワーク ロードバランサの場合は、次のコマンドを使用します。

    gcloud compute firewall-rules create fw-allow-lb-access-ipv6 \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check-ipv6 \
    --source-ranges=2600:2d00:1:b029::/64,2600:2d00:1:1::/64 \
    --rules=all

    クロスリージョン内部アプリケーション ロードバランサ、リージョン外部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサ、クロスリージョン内部プロキシ ネットワーク ロードバランサ、リージョン外部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサの場合は、次のコマンドを使用します。

    gcloud compute firewall-rules create fw-allow-lb-access-ipv6 \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check-ipv6 \
    --source-ranges=2600:2d00:1:b029::/64 \
    --rules=all

プロキシ専用サブネットのファイアウォール ルールを作成する

リージョン外部プロキシ ネットワーク ロードバランサまたは内部プロキシ ネットワーク ロードバランサを使用している場合は、上り（内向き）ファイアウォール ルール fw-allow-lb-access-ipv6 を更新して、プロキシ専用サブネットからバックエンドへのトラフィックを許可する必要があります。

プロキシ専用サブネットの IPv6 アドレス範囲を取得するには、次のコマンドを実行します。

gcloud compute networks subnets describe PROXY_ONLY_SUBNET \
    --region=REGION \
    --format="value(internalIpv6Prefix)"

内部 IPv6 アドレス範囲をメモします。以下では、これを IPV6_PROXY_ONLY_SUBNET_RANGE と表します。

プロキシ専用サブネットのファイアウォール ルール fw-allow-lb-access-ipv6 を更新するには、次の操作を行います。

コンソール

  1. Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。

    [ファイアウォール ポリシー] に移動

  2. [VPC ファイアウォール ルール] パネルで [fw-allow-lb-access-ipv6] をクリックします。

    • 送信元 IPv6 範囲: 2600:2d00:1:b029::/64, IPV6_PROXY_ONLY_SUBNET_RANGE

  3. [保存] をクリックします。

gcloud

  1. プロキシ専用サブネットとの通信を許可するように fw-allow-lb-access-ipv6 ファイアウォール ルールを更新します。

    gcloud compute firewall-rules update fw-allow-lb-access-ipv6 \
    --source-ranges=2600:2d00:1:b029::/64,IPV6_PROXY_ONLY_SUBNET_RANGE

バックエンド サービスを更新して IPv6 転送ルールを作成する

このセクションでは、デュアルスタック バックエンドを使用してバックエンド サービスを更新し、IPv6 転送ルールを作成する手順について説明します。

IPv6 転送ルールは、グローバル外部プロキシ ネットワーク ロードバランサでのみ作成できます。IPv6 転送ルールは、クロスリージョン内部プロキシ ネットワーク ロードバランサ、リージョン外部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサではサポートされていません。

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. ロードバランサの名前をクリックします。

  3. [編集] をクリックします。

IPv6 のバックエンド サービスを構成する

  1. [バックエンドの構成] をクリックします。
  2. [バックエンド タイプ] で [インターネット ネットワーク エンドポイント グループ] を選択します。
  3. [IP アドレス選択ポリシー] リストで、[IPv6 優先] を選択します。
  4. [プロトコル] フィールドで次の操作を行います。
    • TCP プロキシの場合は、[TCP] を選択します。
    • SSL プロキシの場合は、[SSL] を選択します。
  5. ゾーン NEG の場合:
    1. [バックエンド] セクションで、[バックエンドを追加] をクリックします。
    2. [新しいバックエンド] パネルで、次の操作を行います。
      • [ネットワーク エンドポイント グループ] リストで、ZONAL_NEG を選択します。
      • [最大接続数] フィールドに「10」と入力します。
  6. インスタンス グループの場合: VM インスタンスまたはテンプレートをデュアルスタックに更新している場合は、更新する必要はありません。
  7. [完了] をクリックします。
  8. [ヘルスチェック] リストで、HTTP ヘルスチェックを選択します。

IPv6 転送ルールを構成する

IPv6 転送ルールは、クロスリージョン内部プロキシ ネットワーク ロードバランサ、リージョン外部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサではサポートされていません。

  1. [フロントエンドの構成] をクリックします。
  2. [フロントエンド IP とポートの追加] をクリックします。
  3. [名前] フィールドに、転送ルールの名前を入力します。
  4. [プロトコル] フィールドで次の操作を行います。
    • TCP プロキシの場合は、[TCP] を選択します。
    • SSL プロキシの場合は、[SSL] を選択します。
  5. [IP バージョン] を IPv6 に設定します。
  6. SSL プロキシの場合は、[証明書] リストで証明書を選択します。
  7. [完了] をクリックします。
  8. [更新] をクリックします。

gcloud

  1. デュアルスタック ゾーン NEG をバックエンドとしてバックエンド サービスに追加します。

    グローバル

    グローバル外部プロキシ ネットワーク ロードバランサの場合は、次のコマンドを使用します。

     gcloud compute backend-services add-backend BACKEND_SERVICE \
     --network-endpoint-group=ZONAL_NEG \
     --max-rate-per-endpoint=10 \
     --global

    クロスリージョン

    クロスリージョン内部プロキシ ネットワーク ロードバランサの場合は、次のコマンドを使用します。

     gcloud compute backend-services add-backend BACKEND_SERVICE \
     --network-endpoint-group=ZONAL_NEG \
     --max-rate-per-endpoint=10 \
     --global

    リージョン

    リージョン外部プロキシ ネットワーク ロードバランサとリージョン内部プロキシ ネットワーク ロードバランサの場合は、次のコマンドを使用します。

     gcloud compute backend-services add-backend BACKEND_SERVICE \
     --network-endpoint-group=ZONAL_NEG \
     --max-rate-per-endpoint=10 \
     --region=REGION

  2. デュアルスタック インスタンス グループをバックエンドとしてバックエンド サービスに追加します。VM インスタンスまたはテンプレートをデュアルスタックに更新しているため、これ以上の対応は必要ありません。

  3. グローバル外部プロキシ ネットワーク ロードバランサのみの場合:ターゲット SSL プロキシを使用してグローバル外部プロキシ ネットワーク ロードバランサの IPv6 転送ルールを作成するには、次のコマンドを使用します。

    gcloud compute forwarding-rules create FORWARDING_RULE_IPV6 \
   --load-balancing-scheme=EXTERNAL_MANAGED \
   --network-tier=PREMIUM \
   --address=lb-ipv6-1 \
   --global \
   --target-ssl-proxy=TARGET_PROXY \
   --ports=80

    ターゲット TCP プロキシを使用してグローバル外部プロキシ ネットワーク ロードバランサの IPv6 転送ルールを作成するには、次のコマンドを使用します。

    gcloud compute forwarding-rules create FORWARDING_RULE_IPV6 \
   --load-balancing-scheme=EXTERNAL_MANAGED \
   --network-tier=PREMIUM \
   --global \
   --target-tcp-proxy=TARGET_PROXY \
   --ports=80

IP アドレス選択ポリシーを構成する

この手順は省略可能です。リソースとバックエンドをデュアルスタックに変換したら、IP アドレス選択ポリシーを使用して、バックエンド サービスからバックエンドに送信されるトラフィックの種類を指定します。

IP_ADDRESS_SELECTION_POLICY を次のいずれかの値に置き換えます。

IP アドレス選択ポリシー 説明
IPv4 のみ クライアントから GFE へのトラフィックに関係なく、バックエンド サービスのバックエンドに IPv4 トラフィックのみを送信します。バックエンドのヘルスチェックには、IPv4 ヘルスチェックのみが使用されます。
IPv6 優先

バックエンドで IPv4 接続よりも IPv6 接続を優先します（IPv6 アドレスを持つ正常なバックエンドがある場合）。

ヘルスチェックは、バックエンドの IPv6 接続と IPv4 接続を定期的にモニタリングします。GFE は最初に IPv6 接続を試みます。IPv6 接続が切断された場合や遅い場合、GFE は Happy Eyeballs を使用してフォールバックし、IPv4 に接続します。

IPv6 接続または IPv4 接続のいずれかが正常でない場合でも、バックエンドは正常と見なされ、GFE は両方の接続を試行できます。最終的に、使用する接続が Happy Eyeballs によって選択されます。
IPv6 のみ

クライアントからプロキシへのトラフィックに関係なく、バックエンド サービスのバックエンドに IPv6 トラフィックのみを送信します。バックエンドのヘルスチェックには、IPv6 ヘルスチェックのみが使用されます。

バックエンド トラフィック タイプが IP アドレス選択ポリシーと一致しているかどうかを確認するために特別な検証操作を行う必要はありません。たとえば、IPv4 のみのバックエンドがあり、IP アドレス選択ポリシーとして Only IPv6 を選択した場合、トラフィックがバックエンドに到達せず、HTTP 503 レスポンス コードがクライアントに返されるため、バックエンドが異常な状態になります。

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. ロードバランサの名前をクリックします。

  3. [編集] をクリックします。

  4. [バックエンドの構成] をクリックします。

  5. [バックエンド サービス] フィールドで、BACKEND_SERVICE を選択します。

  6. [バックエンド タイプ] は、[ゾーン ネットワーク エンドポイント グループ] または [インスタンス グループ] にする必要があります。

  7. [IP アドレス選択ポリシー] リストで、IP_ADDRESS_SELECTION_POLICY を選択します。

  8. [完了] をクリックします。

gcloud

バックエンド サービスの IP アドレス選択ポリシーを更新します。

グローバル

グローバル外部プロキシ ネットワーク ロードバランサの場合は、次のコマンドを使用します。

gcloud compute backend-services update BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=SSL | TCP \
    --ip-address-selection-policy=IP_ADDRESS_SELECTION_POLICY \
    --global

クロスリージョン

クロスリージョン内部プロキシ ネットワーク ロードバランサの場合は、次のコマンドを使用します。

gcloud compute backend-services update BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=TCP \
    --ip-address-selection-policy=IP_ADDRESS_SELECTION_POLICY \
    --global

リージョン

リージョン外部プロキシ ネットワーク ロードバランサの場合は、次のコマンドを使用します。

gcloud compute backend-services update BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=TCP \
    --ip-address-selection-policy=IP_ADDRESS_SELECTION_POLICY \
    --region=REGION

リージョン内部プロキシ ネットワーク ロードバランサの場合は、次のコマンドを使用します。

gcloud compute backend-services update BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=TCP \
    --ip-address-selection-policy=IP_ADDRESS_SELECTION_POLICY \
    --region=REGION

ロードバランサのテスト

必要なリソースがすべてデュアルスタックに更新されていることを検証する必要があります。すべてのリソースを更新すると、トラフィックがバックエンドに自動的に転送されるはずです。ログを確認して、変換が完了したことを確認します。

ロードバランサをテストして、変換が成功し、受信トラフィックが想定どおりにバックエンドに到達していることを確認します。

ロードバランサの IP アドレスを調べる

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. ロードバランサの名前をクリックします。

  3. [フロントエンド] セクションに、2 つのロードバランサ IP アドレスが表示されます。この手順では、IPv4 アドレスを IP_ADDRESS_IPV4、IPv6 アドレスを IP_ADDRESS_IPV6 で表しています。

  4. [バックエンド] セクションで IP アドレス選択ポリシーが Prefer IPv6 の場合、バックエンドに 2 つのヘルスチェック ステータスが表示されます。

ロードバランサにトラフィックを送信する

この例では、curl コマンドからのリクエストがバックエンドにランダムに分散されます。

外部ロードバランサの場合

  1. すべてのバックエンド VM が応答するまで、次のコマンドを数回繰り返します。

    curl -m1 IP_ADDRESS_IPV4:PORT

    curl -m1 IP_ADDRESS_IPV6:PORT

    たとえば、IPv6 アドレスが [fd20:1db0:b882:802:0:46:0:0]:80 の場合、コマンドは次のようになります。

    curl -m1 [fd20:1db0:b882:802:0:46:0:0]:80

内部ロードバランサの場合

  1. ロードバランサと同じ VPC ネットワークとリージョンにテスト クライアント VM を作成します。同じサブネットまたはゾーンに存在する必要はありません。

    gcloud compute instances create client-vm \
    --zone=ZONE \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=SUBNET

  2. SSH を使用してクライアント インスタンスに接続します。

    gcloud compute ssh client-vm \
   --zone=ZONE

  3. すべてのバックエンド VM が応答するまで、次のコマンドを数回繰り返します。

    curl -m1 IP_ADDRESS_IPV4:PORT

    curl -m1 IP_ADDRESS_IPV6:PORT

    たとえば、IPv6 アドレスが [fd20:1db0:b882:802:0:46:0:0]:80 の場合、コマンドは次のようになります。

    curl -m1 [fd20:1db0:b882:802:0:46:0:0]:80

ログを調べる

すべてのログエントリは、バックエンドの宛先 IPv4 アドレスと宛先 IPv6 アドレスをキャプチャします。デュアルスタックをサポートしているため、バックエンドで使用される IP アドレスを確認することが重要です。

トラフィックが IPv6 に送信されているか、IPv4 にフォールバックされているかどうかは、ログを表示することで確認できます。

ログには、バックエンドに関連付けられた backend_ip アドレスが含まれています。ログを調べて、backend_ip の宛先 IPv4 アドレスまたは宛先 IPv6 アドレスを比較することで、使用されている IP アドレスを確認できます。