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

このドキュメントでは、プロキシネットワークロードバランサのリソースとバックエンドを IPv4 のみ（シングルスタック）から IPv4 と IPv6（デュアルスタック）に移行する方法について説明します。このドキュメントでは、IPv4 のみ（シングルスタック）は IPv4 アドレスのみを使用するリソースを指し、IPv4 と IPv6（デュアルスタック）は IPv4 アドレスと IPv6 アドレスの両方を使用するリソースを指します。

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

利点

ロードバランサをデュアルスタックに変換する主なメリットは次のとおりです。

IPv6 の主な利点は、はるかに大きな IP アドレスプールを割り振ることができることです。
すでに IPv4 のみのロードバランサを使用している多くのユーザーは、クラウド固有の方法で、IPv4 のみのサポートされているバックエンドから IPv4 と IPv6（デュアルスタック）のバックエンドに移行できます。
上り（内向き）IPv6 トラフィックを終端し、必要に応じて IPv4 または IPv6 接続を介してこのトラフィックをバックエンドにプロキシするようにロードバランサを構成できます。詳細については、IPv6 をご覧ください。

制限事項

サブネットの IP スタックタイプを IPv4 と IPv6（デュアルスタック）から IPv4 のみに更新することはできません。
バックエンドサービスで IP アドレス選択ポリシーを IPv6 のみとして構成しても、IPv4 のみのバックエンドを構成できます。ただし、このような構成では、バックエンドが異常になり、クライアントにレスポンスコード 503 が返され、トラフィックがアップストリームに転送されません。ログの statusDetails には failed_to_pick_backend が示されます。
バックエンドサービスの IP アドレス選択ポリシーを IPv6 のみに構成できますが、バックエンドの IP スタックタイプは常に IPv4 と IPv6（デュアルスタック）です。
IPv4 と IPv6（デュアルスタック）をサポートするのは、GCE_VM_IP_PORT エンドポイントを使用する VM インスタンスグループバックエンドとゾーンネットワークエンドポイントグループ（NEG）のみです。
クロスリージョン内部プロキシネットワークロードバランサ、リージョン外部プロキシネットワークロードバランサ、リージョン内部プロキシネットワークロードバランサは、IPv6 を使用した転送ルールをサポートしていません。上り（内向き）IPv4 トラフィックは、IPv4 または IPv6 接続を介してデュアルスタックバックエンドにプロキシされます。
従来のプロキシネットワークロードバランサはデュアルスタックバックエンドをサポートしていません。ロードバランサは、IPv6 クライアントから受信した上り（内向き）IPv6 トラフィックを終端し、IPv4 接続を介してこのトラフィックを IPv4 バックエンドにプロキシします。

始める前に

インスタンスグループまたはゾーンネットワークエンドポイントグループ（NEG）のバックエンドを使用して、IPv4 のみのスタックを持つ SSL プロキシまたは TCP プロキシのプロキシネットワークロードバランサを設定する必要があります。

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

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

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

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

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

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

すべてのサブネットを一覧取得するには、gcloud compute networks subnets list コマンドを使用します。
```
gcloud compute networks subnets list
```
デュアルスタックに変換する IPv4 のみのスタックを持つサブネットの名前をメモします。以下では、この名前を SUBNET で表します。以下では、この VPC ネットワークを NETWORK で表します。
すべてのバックエンドサービスを一覧取得するには、gcloud beta compute backend-services list コマンドを使用します。
```
gcloud beta compute backend-services list
```
デュアルスタックに変換するバックエンドサービスの名前をメモします。以下では、この名前を BACKEND_SERVICE で表します。

ロードバランサがすでにある場合は、バックエンドの 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)"

すべての VM インスタンスとインスタンステンプレートを一覧取得するには、gcloud compute instances list コマンドと gcloud compute instance-templates list コマンドを使用します。
```
gcloud compute instances list
```
```
gcloud compute instance-templates list
```
デュアルスタックに変換するインスタンスとインスタンステンプレートの名前をメモします。以下では、これらの名前をそれぞれ VM_INSTANCE、INSTANCE_TEMPLATES で表します。
すべてのゾーン NEG を一覧取得するには、gcloud compute network-endpoint-groups list コマンドを使用します。
```
gcloud compute network-endpoint-groups list
```
デュアルスタックに移行するネットワークエンドポイントグループの名前をメモします。以下では、この名前を ZONAL_NEG で表します。
すべてのターゲット SSL プロキシを一覧取得するには、gcloud compute target-ssl-proxies list コマンドを使用します。
```
gcloud compute target-ssl-proxies list
```
ロードバランサに関連付けられているターゲットプロキシの名前をメモします。以下では、この名前を TARGET_PROXY で表します。
すべてのターゲット TCP プロキシを一覧取得するには、gcloud compute target-tcp-proxies list コマンドを使用します。
```
gcloud compute target-tcp-proxies list
```
ロードバランサに関連付けられているターゲットプロキシの名前をメモします。以下では、この名前を TARGET_PROXY で表します。

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

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

サブネットを更新する

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

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

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

注: default ネットワークを使用している場合は、カスタムモードの VPC ネットワークに変換する必要があります。
IPv6 を有効にする方法については、サブネットのスタックタイプをデュアルスタックに変更するをご覧ください。

注: サブネットの IPv6 アクセスタイプは External にする必要があります。
省略可: このネットワークのサブネットで内部 IPv6 アドレス範囲を構成する場合は、次の手順を完了します。
1. [VPC ネットワーク ULA の内部 IPv6 範囲] で、[有効] を選択します。
2. [Allocate internal IPv6 range] で、[自動] または [手動] を選択します。
  
  [手動] を選択した場合は、fd20::/20 の範囲内の /48 の範囲を入力します。範囲が使用されている場合は、別の範囲を指定するように求めるプロンプトが表示されます。

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

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

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

コンソール

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

[VPC ネットワーク] に移動
ネットワークの名前をクリックして、[VPC ネットワークの詳細] ページを表示します。
[サブネット] タブをクリックします。
[ロードバランシング用に予約されているプロキシ専用サブネット] セクションで、変更するプロキシ専用サブネットの名前をクリックします。
[サブネットの詳細] ページで、[編集] をクリックします。
[IP スタックタイプ] には、[IPv4 と IPv6（デュアルスタック）] を選択します。[IPv6 アクセスタイプ] は [内部] です。
[保存] をクリックします。

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 インスタンスをデュアルスタックに更新する手順は次のとおりです。

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

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

コンソール

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

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

ゾーン NEG を更新する

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

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

VM を作成する

コンソール

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

[VM インスタンス] に移動
[インスタンスを作成] をクリックします。
[名前] を vm-a1 に設定します。
[リージョン] に REGION_A を選択し、[ゾーン] フィールドに任意の値を選択します。この手順では、このサブネットを GCP_NEG_ZONE で表しています。
[ブートディスク] セクションで、ブートディスクオプションとして Debian GNU/Linux 12 (bookworm) が選択されていることを確認します。必要に応じて [選択] をクリックし、イメージを変更します。
[詳細オプション] セクションを開き、次の変更を行います。
- [ネットワーキング] セクションを開きます。
- [ネットワークタグ] フィールドに「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
```
[作成] をクリックします。
以下の手順を繰り返し、次の名前とゾーンの組み合わせを使用して、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 にエンドポイントを追加します。

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

[ネットワークエンドポイントグループ] に移動
[名前] リストで、ネットワークエンドポイントグループの名前（ZONAL_NEG）をクリックします。[ネットワークエンドポイントグループの詳細] ページが表示されます。
[このグループのネットワークエンドポイント] セクションで、以前に作成した NEG エンドポイントを選択します。[エンドポイントを削除] をクリックします。
[このグループのネットワークエンドポイント] セクションで [ネットワークエンドポイントを追加] をクリックします。
VM インスタンスを選択します。
[ネットワークインターフェース] セクションに、VM の名前、ゾーン、サブネットが表示されます。
[IPv4 アドレス] フィールドに、新しいネットワークエンドポイントの IPv4 アドレスを入力します。
[IPv6 アドレス] フィールドに、新しいネットワークエンドポイントの IPv6 アドレスを入力します。
注: 複数のエンドポイントを持つバックエンドサービスには、一意の IPv6 アドレスが必要です。エンドポイントは異なるサブネットに配置できますが、同じ IPv6 アドレスを複数のエンドポイントに使用することはできません。
ポートタイプを選択します。
1. [デフォルト] を選択すると、エンドポイントはネットワークエンドポイントグループのすべてのエンドポイントにデフォルトポート 80 を使用します。この例では、Apache サーバーがポート 80 でリクエストを配信しているため、これで十分です。
2. [カスタム] を選択した場合は、使用するエンドポイントのポート番号を入力します。
他のエンドポイントを追加するには、[ネットワークエンドポイントを追加] をクリックし、前の手順を繰り返します。
すべてのエンドポイントを追加したら、[作成] をクリックします。

gcloud

エンドポイント（GCE_VM_IP_PORT エンドポイント）を ZONAL_NEG に追加します。
注: 複数のエンドポイントを持つバックエンドサービスには、一意の IPv6 アドレスが必要です。エンドポイントは異なるサブネットに配置できますが、同じ IPv6 アドレスを複数のエンドポイントに使用することはできません。
```
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 ヘルスチェックシステム（2600:2d00:1:b029::/64）からのトラフィックを許可する上り（内向き）ルールがあることを確認します。この例では、ターゲットタグ allow-health-check-ipv6 を使用して、ルールが適用される VM インスタンスを識別します。

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

コンソール

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

[ファイアウォールポリシー] に移動
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」を入力します。
- プロトコルとポート: すべて許可
[作成] をクリックします。

gcloud

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
```

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

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

プロキシ専用サブネットから internalIpv6Prefix を取得するには、次のコマンドを実行します。

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

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

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

コンソール

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

[ファイアウォールポリシー] に移動
[VPC ファイアウォールルール] パネルで [fw-allow-lb-access-ipv6] をクリックします。
- 送信元 IPv6 範囲: 2600:2d00:1:b029::/64, IPv6_PROXY
[保存] をクリックします。

gcloud

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

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

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

このセクションでは、IP アドレス選択ポリシーを Prefer IPv6 としてバックエンドサービス BACKEND_SERVICE を更新し、ゾーン NEG バックエンドを追加する手順について説明します。

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

バックエンドサービスにインスタンスグループが関連付けられている場合は、インスタンスグループのバックエンドサービスを更新するをご覧ください。

コンソール

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

[ロードバランシング] に移動
ロードバランサの名前をクリックします。
[編集] をクリックします。

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

[バックエンドの構成] をクリックします。
[バックエンドタイプ] で [インターネットネットワークエンドポイントグループ] を選択します。
[IP アドレス選択ポリシー] リストで、[IPv6 優先] を選択します。
[プロトコル] フィールドで次の操作を行います。
- TCP プロキシの場合は、[TCP] を選択します。
- SSL プロキシの場合は、[SSL] を選択します。
[バックエンド] セクションで、[バックエンドを追加] をクリックします。
[新しいバックエンド] パネルで、次の操作を行います。
- [ネットワークエンドポイントグループ] リストで、ZONAL_NEG を選択します。
- [最大接続数] フィールドに「10」と入力します。
[完了] をクリックします。
[ヘルスチェック] リストで、HTTP ヘルスチェックを選択します。

IPv6 転送ルールを構成する

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

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

gcloud

SSL または TCP トラフィックのバックエンドサービスを更新します。

グローバル

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

gcloud beta compute backend-services update BACKEND_SERVICE \
   --load-balancing-scheme=EXTERNAL_MANAGED \
   --protocol=[SSL|TCP] \
   --ip-address-selection-policy=PREFER_IPV6 \
   --global

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

gcloud beta compute backend-services update BACKEND_SERVICE \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --protocol=[SSL|TCP] \
   --ip-address-selection-policy=PREFER_IPV6 \
   --global

リージョン

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

gcloud beta compute backend-services update BACKEND_SERVICE \
   --load-balancing-scheme=EXTERNAL_MANAGED \
   --protocol=[SSL|TCP] \
   --ip-address-selection-policy=PREFER_IPV6 \
   --region=REGION

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

gcloud beta compute backend-services update BACKEND_SERVICE \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --protocol=[SSL|TCP] \
   --ip-address-selection-policy=PREFER_IPV6 \
   --region=REGION

バックエンドとしてゾーン NEG をバックエンドサービスに追加します。
グローバル

グローバル外部プロキシネットワークロードバランサとクロスリージョン内部プロキシネットワークロードバランサの場合は、次のコマンドを使用します。
gcloud beta compute backend-services add-backend BACKEND_SERVICE \ --network-endpoint-group=ZONAL_NEG \ --max-rate-per-endpoint=10 \ --global
リージョン

リージョン外部プロキシネットワークロードバランサとリージョン内部プロキシネットワークロードバランサの場合は、次のコマンドを使用します。
gcloud beta compute backend-services add-backend BACKEND_SERVICE \ --network-endpoint-group=ZONAL_NEG \ --max-rate-per-endpoint=10 \ --region=REGION
ユーザーがロードバランサに接続する際に使用する外部 IPv6 アドレスを予約します。
グローバル

グローバル外部プロキシネットワークロードバランサの場合は、次のコマンドを使用します。
gcloud compute addresses create lb-ipv6-1 \ --ip-version=IPV6 \ --network-tier=PREMIUM \ --global

SSL プロキシにバックエンドサービスの転送ルールを作成します。

gcloud beta compute target-ssl-proxies create TARGET_PROXY \
   --backend-service=BACKEND_SERVICE \
   --ssl-certificates=[SSL_CERT_1][,[SSL_CERT_2],...] \
   --ssl-policy=my-ssl-policy \
   --proxy-header=NONE

グローバル

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

gcloud beta 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 プロキシにバックエンドサービスの転送ルールを作成します。

gcloud beta compute target-tcp-proxies create TARGET_PROXY \
   --backend-service=BACKEND_SERVICE \
   --proxy-header=NONE

グローバル

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

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

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

gcloud beta compute forwarding-rules create FORWARDING_RULE_IPV6 \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --network-tier=PREMIUM \
   --network=NETWORK \
   --subnet=SUBNET \
   --subnet-region=REGION \
   --address=lb-ipv6-1 \
   --global \
   --target-tcp-proxy=TARGET_PROXY \
   --ports=80

リージョン

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

gcloud beta compute forwarding-rules create FORWARDING_RULE_IPV6 \
   --load-balancing-scheme=EXTERNAL_MANAGED \
   --network-tier=PREMIUM \
   --network=NETWORK \
   --subnet=SUBNET \
   --address=lb-ipv6-1 \
   --region=REGION \
   --target-tcp-proxy==TARGET_PROXY \
   --target-tcp-proxy-region=REGION \
   --ports=80

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

gcloud beta compute forwarding-rules create FORWARDING_RULE_IPV6 \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --network-tier=PREMIUM \
   --network=NETWORK \
   --subnet=SUBNET \
   --address=lb-ipv6-1 \
   --region=REGION \
   --target-tcp-proxy=TARGET_PROXY \
   --target-tcp-proxy-region=REGION \
   --ports=80

インスタンスグループのバックエンドサービスを更新する

バックエンドサービスにインスタンスグループが関連付けられている場合は、次のようにバックエンドサービスを更新する必要があります。

コンソール

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

[ロードバランシング] に移動
ロードバランサの名前をクリックします。
[編集] をクリックします。

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

[バックエンドの構成] をクリックします。
[バックエンドタイプ] で [インスタンスグループ] を選択します。
[IP アドレス選択ポリシー] リストで、[IPv6 優先] を選択します。
[プロトコル] フィールドで次の操作を行います。
- TCP プロキシの場合は、[TCP] を選択します。
- SSL プロキシの場合は、[SSL] を選択します。
VM インスタンスまたはテンプレートをデュアルスタックに更新した場合は、[バックエンド] セクションを再度更新する必要はありません。
ヘルスチェックを選択します。
[更新] をクリックします。

gcloud

バックエンドとしてインスタンスグループをバックエンドサービスに追加します。VM インスタンスまたはテンプレートをデュアルスタックに更新している場合は、この手順をスキップできます。
グローバル

グローバル外部プロキシネットワークロードバランサとクロスリージョン内部プロキシネットワークロードバランサの場合は、次のコマンドを使用します。
gcloud beta compute backend-services add-backend BACKEND_SERVICE \ --instance-group=INSTANCE_GROUP \ --global
リージョン

リージョン外部プロキシネットワークロードバランサとリージョン内部プロキシネットワークロードバランサの場合は、次のコマンドを使用します。
gcloud beta compute backend-services add-backend BACKEND_SERVICE \ --instance-group=INSTANCE_GROUP \ --region=REGION

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

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

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

IP アドレス選択ポリシー説明

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

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` を選択した場合、構成エラーは発生しませんが、トラフィックはバックエンドに転送されません。

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 を選択した場合、構成エラーは発生しませんが、トラフィックはバックエンドに転送されません。

コンソール

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

[ロードバランシング] に移動
ロードバランサの名前をクリックします。
[編集] をクリックします。
[バックエンドの構成] をクリックします。
[バックエンドサービス] フィールドで、BACKEND_SERVICE を選択します。
[バックエンドタイプ] は、[ゾーンネットワークエンドポイントグループ] または [インスタンスグループ] にする必要があります。
[IP アドレス選択ポリシー] リストで、IP_ADDRESS_SELECTION_POLICY を選択します。
[完了] をクリックします。

gcloud

バックエンドサービスを更新します。

グローバル

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

gcloud beta 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 beta compute backend-services update BACKEND_SERVICE_IPV6 \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --protocol=[SSL|TCP] \
   --ip-address-selection-policy=IP_ADDRESS_SELECTION_POLICY \
   --global

リージョン

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

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

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

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

ロードバランサのテスト

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

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

外部 IP アドレスを検索する

コンソール

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

[ロードバランシング] に移動
ロードバランサの名前をクリックします。
[フロントエンド] セクションに、2 つのロードバランサ IP アドレスが表示されます。この手順では、IPv4 アドレスを IP_ADDRESS_IPV4、IPv6 アドレスを IP_ADDRESS_IPV6 で表しています。
[バックエンド] セクションで IP アドレス選択ポリシーが Prefer IPv6 の場合、バックエンドに 2 つのヘルスチェックステータスが表示されます。

インスタンスに送信されるトラフィックをテストする

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

すべてのバックエンド 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 アドレスを確認できます。

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

利点

制限事項

始める前に

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

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

サブネットを更新する

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

コンソール

gcloud

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

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

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

コンソール

ゾーン NEG を更新する

VM を作成する

コンソール

gcloud

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

コンソール

gcloud

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

コンソール

gcloud

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

コンソール

gcloud

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

コンソール

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

IPv6 転送ルールを構成する

gcloud

グローバル

リージョン

グローバル

リージョン

グローバル

グローバル

グローバル

リージョン

インスタンス グループのバックエンド サービスを更新する

コンソール

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

gcloud

グローバル

リージョン

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

コンソール

gcloud

グローバル

リージョン

ロードバランサのテスト

外部 IP アドレスを検索する

コンソール

インスタンスに送信されるトラフィックをテストする

ログを調べる

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

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

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

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

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

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

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

インスタンスグループのバックエンドサービスを更新する

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