このドキュメントでは、プロキシ ネットワーク ロードバランサのリソースとバックエンドを 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 転送ルールはサポートされていません。
グローバル外部プロキシ ネットワーク ロードバランサの設定方法については、次のドキュメントをご覧ください。
- グローバル外部プロキシ ネットワーク ロードバランサを設定する: VM インスタンス グループのバックエンド、ゾーン NEG バックエンド
- リージョン外部プロキシ ネットワーク ロードバランサを設定する: VM インスタンス グループのバックエンド、ゾーン NEG バックエンド
- クロスリージョン内部プロキシ ネットワーク ロードバランサを設定する: VM インスタンス グループのバックエンド、ゾーン NEG バックエンド
- リージョン内部プロキシ ネットワーク ロードバランサを設定する: VM インスタンス グループのバックエンド、ゾーン NEG バックエンド
変換するリソースを特定する
ロードバランサが関連付けられているリソースの名前をメモします。これらの名前は後で指定する必要があります。
すべてのサブネットを一覧取得するには、
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で表します。すべてのインスタンス グループを一覧取得するには、
gcloud compute instance-groups listコマンドを使用します。gcloud compute instance-groups list
デュアルスタックに移行するネットワーク エンドポイント グループの名前をメモします。以下では、この名前を
INSTANCE_GROUPで表します。すべてのゾーン 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 アドレス範囲を構成する場合は、次の手順を完了します。
- [VPC ネットワーク ULA の内部 IPv6 範囲] で、[有効] を選択します。
[Allocate internal IPv6 range] で、[自動] または [手動] を選択します。
[手動] を選択した場合は、
fd20::/20の範囲内の/48の範囲を入力します。範囲が使用されている場合は、別の範囲を指定するように求めるプロンプトが表示されます。
プロキシ専用サブネットを更新する
Envoy ベースのロードバランサを使用している場合は、プロキシ専用サブネットのスタックタイプをデュアルスタックに変更することをおすすめします。プロキシ専用サブネットをサポートするロードバランサについては、サポートされているロードバランサをご覧ください。
プロキシ専用サブネットのスタックタイプをデュアルスタックに変更する手順は次のとおりです。
コンソール
Google Cloud コンソールの [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 コンソールで、[インスタンス テンプレート] ページに移動します。
- コピーして更新するインスタンス テンプレートをクリックします。
- [同様のものを作成] をクリックします。
- [詳細オプション] セクションを開きます。
- [ネットワーク タグ] に「
allow-health-check-ipv6」と入力します。 - [ネットワーク インターフェース] セクションで、[ネットワーク インターフェースを追加] をクリックします。
- [ネットワーク] リストで、カスタムモードの VPC ネットワークを選択します。
- [サブネットワーク] リストで、
SUBNETを選択します。 - [IP スタックタイプ] には、[IPv4 と IPv6（デュアルスタック）] を選択します。
- [作成] をクリックします。
ロードバランサに関連付けられたマネージド インスタンス グループ
MIGで基本のローリング アップデートを開始します。
ゾーン NEG を更新する
ゾーン NEG エンドポイントは編集できません。IPv4 エンドポイントを削除し、IPv4 アドレスと IPv6 アドレスの両方を持つ新しいデュアルスタック エンドポイントを作成する必要があります。
REGION_A リージョンにゾーン NEG（GCE_VM_IP_PORT タイプのエンドポイントを含む）を設定するには、まず GCP_NEG_ZONE ゾーンに VM を作成します。次に、VM ネットワーク エンドポイントをゾーン NEG に追加します。
VM を作成する
コンソール
Google Cloud コンソールで [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 アドレスを入力します。
ポートタイプを選択します。
- [デフォルト] を選択すると、エンドポイントはネットワーク エンドポイント グループのすべてのエンドポイントにデフォルト ポート
80を使用します。この例では、Apache サーバーがポート80でリクエストを配信しているため、これで十分です。 - [カスタム] を選択した場合は、使用するエンドポイントのポート番号を入力します。
- [デフォルト] を選択すると、エンドポイントはネットワーク エンドポイント グループのすべてのエンドポイントにデフォルト ポート
他のエンドポイントを追加するには、[ネットワーク エンドポイントを追加] をクリックし、前の手順を繰り返します。
すべてのエンドポイントを追加したら、[作成] をクリックします。
gcloud
エンドポイント（
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 トラフィックがブロックされます。
コンソール
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
プロキシ専用サブネットのファイアウォール ルールを作成する
リージョン外部プロキシ ネットワーク ロードバランサまたは内部プロキシ ネットワーク ロードバランサを使用している場合は、上り（内向き）ファイアウォール ルール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 を更新するには、次の操作を行います。
コンソール
Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。
[VPC ファイアウォール ルール] パネルで [
fw-allow-lb-access-ipv6] をクリックします。- 送信元 IPv6 範囲:
2600:2d00:1:b029::/64, IPV6_PROXY_ONLY_SUBNET_RANGE
- 送信元 IPv6 範囲:
[保存] をクリックします。
gcloud
プロキシ専用サブネットとの通信を許可するように
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 転送ルールは、クロスリージョン内部プロキシ ネットワーク ロードバランサ、リージョン外部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサではサポートされていません。
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[編集] をクリックします。
IPv6 のバックエンド サービスを構成する
- [バックエンドの構成] をクリックします。
- [バックエンド タイプ] で [インターネット ネットワーク エンドポイント グループ] を選択します。
- [IP アドレス選択ポリシー] リストで、[IPv6 優先] を選択します。
- [プロトコル] フィールドで次の操作を行います。
- TCP プロキシの場合は、[TCP] を選択します。
- SSL プロキシの場合は、[SSL] を選択します。
- ゾーン NEG の場合:
- [バックエンド] セクションで、[バックエンドを追加] をクリックします。
- [新しいバックエンド] パネルで、次の操作を行います。
- [ネットワーク エンドポイント グループ] リストで、
ZONAL_NEGを選択します。 - [最大接続数] フィールドに「10」と入力します。
- [ネットワーク エンドポイント グループ] リストで、
- インスタンス グループの場合: VM インスタンスまたはテンプレートをデュアルスタックに更新している場合は、更新する必要はありません。
- [完了] をクリックします。
- [ヘルスチェック] リストで、HTTP ヘルスチェックを選択します。
IPv6 転送ルールを構成する
IPv6 転送ルールは、クロスリージョン内部プロキシ ネットワーク ロードバランサ、リージョン外部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサではサポートされていません。
- [フロントエンドの構成] をクリックします。
- [フロントエンド IP とポートの追加] をクリックします。
- [名前] フィールドに、転送ルールの名前を入力します。
- [プロトコル] フィールドで次の操作を行います。
- TCP プロキシの場合は、[TCP] を選択します。
- SSL プロキシの場合は、[SSL] を選択します。
- [IP バージョン] を
IPv6に設定します。 - SSL プロキシの場合は、[証明書] リストで証明書を選択します。
- [完了] をクリックします。
- [更新] をクリックします。
gcloud
デュアルスタック ゾーン NEG をバックエンドとしてバックエンド サービスに追加します。
グローバル
グローバル外部プロキシ ネットワーク ロードバランサの場合は、次のコマンドを使用します。
gcloud 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 \ --globalリージョン
リージョン外部プロキシ ネットワーク ロードバランサとリージョン内部プロキシ ネットワーク ロードバランサの場合は、次のコマンドを使用します。
gcloud beta compute backend-services add-backend BACKEND_SERVICE \ --network-endpoint-group=ZONAL_NEG \ --max-rate-per-endpoint=10 \ --region=REGIONデュアルスタック インスタンス グループをバックエンドとしてバックエンド サービスに追加します。VM インスタンスまたはテンプレートをデュアルスタックに更新しているため、これ以上の対応は必要ありません。
グローバル外部プロキシ ネットワーク ロードバランサのみの場合:ターゲット 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 アドレス選択ポリシーとして |
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[編集] をクリックします。
[バックエンドの構成] をクリックします。
[バックエンド サービス] フィールドで、
BACKEND_SERVICEを選択します。[バックエンド タイプ] は、[ゾーン ネットワーク エンドポイント グループ] または [インスタンス グループ] にする必要があります。
[IP アドレス選択ポリシー] リストで、
IP_ADDRESS_SELECTION_POLICYを選択します。[完了] をクリックします。
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 beta compute backend-services update BACKEND_SERVICE_IPV6 \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=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=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=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
内部ロードバランサの場合
ロードバランサと同じ VPC ネットワークとリージョンにテスト クライアント VM を作成します。同じサブネットまたはゾーンに存在する必要はありません。
gcloud compute instances create client-vm \ --zone=ZONE \ --image-family=debian-12 \ --image-project=debian-cloud \ --tags=allow-ssh \ --subnet=SUBNETSSH を使用してクライアント インスタンスに接続します。
gcloud compute ssh client-vm \ --zone=ZONE
すべてのバックエンド 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 アドレスを確認できます。