このドキュメントでは、グローバル外部プロキシ ネットワーク ロードバランサのリソースとバックエンドを 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)のみです。
始める前に
インスタンス グループまたはゾーン ネットワーク エンドポイント グループ(NEG)のバックエンドを使用して、IPv4 のみのスタックを持つ SSL プロキシまたは TCP プロキシのグローバル外部プロキシ ネットワーク ロードバランサを設定する必要があります。
グローバル外部プロキシ ネットワーク ロードバランサの設定方法の詳細については、次のドキュメントをご覧ください。
- VM インスタンス グループのバックエンドを使用してグローバル外部プロキシ ネットワーク ロードバランサ(SSL プロキシ)を設定する
- VM インスタンス グループのバックエンドを使用してグローバル外部プロキシ ネットワーク ロードバランサ(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 ネットワークをカスタムモードに変換する必要があります。
IPv6 を有効にする方法については、サブネットのスタックタイプをデュアルスタックに変更するをご覧ください。
省略可: このネットワークのサブネットで内部 IPv6 アドレス範囲を構成する場合は、次の手順を完了します。
- [VPC ネットワーク ULA の内部 IPv6 範囲] で、[有効] を選択します。
[Allocate internal IPv6 range] で、[自動] または [手動] を選択します。
[手動] を選択した場合は、
fd20::/20
の範囲内の/48
の範囲を入力します。範囲が使用されている場合は、別の範囲を指定するように求めるプロンプトが表示されます。
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 オペレーティング システムと 10(buster)バージョンが選択されていることを確認します。必要に応じてイメージを変更するには、[選択] をクリックします。
[詳細オプション] セクションを開き、次の変更を行います。
- [ネットワーキング] セクションを開きます。
- [ネットワーク タグ] フィールドに「
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-10 \ --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 ヘルスチェック システム(2600:2d00:1:b029::/64
、2600:2d00:1:1::/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
- プロトコルとポート: すべて許可
- 名前:
[作成] をクリックします。
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
バックエンド サービスを更新して IPv6 の転送ルールを作成する
このセクションでは、IP アドレス選択ポリシーを Prefer IPv6
としてバックエンド サービス BACKEND_SERVICE
を更新し、ゾーン NEG バックエンドを追加する手順について説明します。
バックエンド サービスに��ンスタンス グループが関連付けられている場合は、インスタンス グループのバックエンド サービスを更新するをご覧ください。
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[編集] をクリックします。
IPv6 のバックエンド サービスを構成する
- [バックエンドの構成] をクリックします。
- [バックエンド タイプ] で [インターネット ネットワーク エンドポイント グループ] を選択します。
- [IP アドレス選択ポリシー] リストで、[IPv6 優先] を選択します。
- [プロトコル] フィールドで次の操作を行います。
- TCP プロキシの場合は、[TCP] を選択します。
- SSL プロキシの場合は、[SSL] を選択します。
- [バックエンド] セクションで、[バックエンドを追加] をクリックします。
- [新しいバックエンド] パネルで、次の操作を行います。
- [ネットワーク エンドポイント グループ] リストで、
ZONAL_NEG
を選択します。 - [最大接続数] フィールドに「10」と入力します。
- [ネットワーク エンドポイント グループ] リストで、
- [完了] をクリックします。
- [ヘルスチェック] リストで、HTTP ヘルスチェックを選択します。
IPv6 転送ルールを構成する
- [フロントエンドの構成] をクリックします。
- [フロントエンド IP とポートの追加] をクリックします。
- [名前] フィールドに、転送ルールの名前を入力します。
- [プロトコル] フィールドで次の操作を行います。
- TCP プロキシの場合は、[TCP] を選択します。
- SSL プロキシの場合は、[SSL] を選択します。
- [IP バージョン] を
IPv6
に設定します。 - SSL プロキシの場合は、[証明書] リストで証明書を選択します。
- [完了] をクリックします。
- [更新] をクリックします。
gcloud
HTTP トラフィックのバックエンド サービスを作成します。
gcloud beta compute backend-services update BACKEND_SERVICE \ --protocol=[SSL|TCP] \ --port-name=http \ --ip-address-selection-policy=PREFER_IPV6 \ --health-checks=HEALTH_CHECK \ --global
バックエンドとしてゾーン NEG をバックエンド サービスに追加します。
gcloud beta compute backend-services add-backend BACKEND_SERVICE \ --network-endpoint-group=ZONAL_NEG \ --global
ユーザーがロードバランサに接続する際に使用する外部 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 \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --address=lb-ipv6-1 \ --global \ --target-ssl-proxy=TARGET_PROXY \ --ports=443
TCP プロキシにバックエンド サービスの転送ルールを作成します。
gcloud beta compute target-tcp-proxies create TARGET_PROXY \ --backend-service=BACKEND_SERVICE \ --proxy-header=NONE
gcloud beta compute forwarding-rules create \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --address=lb-ipv6-1 \ --global \ --target-tcp-proxy=TARGET_PROXY \ --ports=443
インスタンス グループのバックエンド サービスを更新する
バックエンド サービスにインスタンス グループが関連付けられている場合は、次のようにバックエンド サービスを更新する必要があります。
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[編集] をクリックします。
バックエンド サービスを構成する
- [バックエンドの構成] をクリックします。
- [バックエンド タイプ] で [インスタンス グループ] を選択します。
- [IP アドレス選択ポリシー] リストで、[IPv6 優先] を選択します。
- [プロトコル] フィールドで次の操作を行います。
- TCP プロキシの場合は、[TCP] を選択します。
- SSL プロキシの場合は、[SSL] を選択します。
- VM インスタンスまたはテンプレートをデュアルスタックに更新した場合は、[バックエンド] セクションを再度更新する必要はありません。
- ヘルスチェックを選択します。
- [更新] をクリックします。
gcloud
HTTP トラフィックのバックエンド サービスを作成します。
gcloud beta compute backend-services update BACKEND_SERVICE \ --protocol=[SSL|TCP] \ --port-name=http \ --ip-address-selection-policy=PREFER_IPV6 \ --health-checks=HEALTH_CHECK \ --global
バックエンドとしてインスタンス グループをバックエンド サービスに追加します。VM インスタンスまたはテンプレートをデュアルスタックに更新している場合は、この手順をスキップできます。
gcloud beta compute backend-services add-backend BACKEND_SERVICE \ --instance-group=INSTANCE_GROUP \ --global
IP アドレス選択ポリシーを構成する
この手順は省略可能です。リソースとバックエンドをデュアルスタックに変換したら、IP アドレス選択ポリシーを使用して、Google Front End(GFE)からバックエンドに送信されるトラフィックの種類を指定します。
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
バックエンド サービスを更新します。
gcloud beta compute backend-services update BACKEND_SERVICE \ --load-balancing-scheme=EXTERNAL_MANAGED \ --protocol=HTTP \ --ip-address-selection-policy=IP_ADDRESS_SELECTION_POLICY \ --global
ロードバランサのテスト
必要なリソースがすべて���ュアルスタックに更新��れ��いる��とを検証する必要があります。すべてのリソースを更新すると、トラフィックがバックエンドに自動的に転送されるはずです。ログを確認して、変換が完了したことを確認します。
ロードバランサをテストして、変換が成功し、受信トラフィックが想定どおりにバックエンドに到達していることを確認します。
外部 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 アドレスを確認できます。