内部パススルーネットワークロードバランサをネクストホップとして設定する（タグを使用）

このチュートリアルでは、サンプルを使用して、パケットを最終的な宛先に転送するためのネクストホップとして内部パススルーネットワークロードバランサをデプロイする方法を説明します。ここでは、ネットワークタグを使用して、ルートの適用対象となるクライアントインスタンスを構成します。

このガイドは、内部パススルーネットワークロードバランサの機能、関連コンポーネント（ファイアウォールルール、ヘルスチェックなど）、パケット転送時に内部パススルーネットワークロードバランサがネクストホップとして使用される仕組みを理解していることを前提としています。

ネクストホップ機能として内部パススルーネットワークロードバランサを使用すると、可用性の高いスケールアウト方式でサードパーティアプライアンスを統合できます。これを行うには、カスタム静的ルートを構成し、ロードバランサにネクストホップを設定する必要があります。これにより、ロードバランサはヘルスチェックされたサードパーティ VM アプライアンスのプールに宛先プレフィックスのトラフィックを分散します。このようなサードパーティアプライアンスの高可用性をサポートするためにネクストホップを選択する場合、いくつかのオプションがあります。

ネクストホップとして IP アドレスを指定する: 転送ルールに関連付けられた内部 IP アドレスをネクストホップとして使用します。このロードバランサの仮想 IP アドレスはピア間で学習できます。ピアを介してカスタムルートをエクスポートする必要はありません。
ネットワークタグを使用する: ネクストホップルートとしての内部パススルーネットワークロードバランサが、ネットワークタグで構成されたクライアントインスタンスにのみ適用されるように設定できます。これにより、ネクストホップルートとしてタグ付けされた内部パススルーネットワークロードバランサが適用されるクライアントインスタンスと、トラフィックをルーティングするアプライアンスのセットを選択できます。複数のクライアントインスタンスを別々の VPC に分離する必要はありません。それぞれが、アプライアンスのセットをフロントエンドにする優先内部パススルーネットワークロードバランサを参照します。タグ付きのルートは、VPC ネットワークピアリングでエクスポートまたはインポートされません。
同じ宛先プレフィックスの複数のルートを構成する: タグを使用すると、異なる内部ロードバランサをネクストホップとして使用して、同じ宛先に複数のルートを指定できます。ECMP（同じ宛先プレフィックス、同じタグ、異なるネクストホップ）はサポートされていませんが、同じ宛先の複数のルートに異なるタグまたは異なる優先順位を使用できます。

設定の概要

単一 NIC の VM を使用するマネージドインスタンスグループが異なるリージョンで定義されています。Linux インスタンスは、インターネットへのすべての送信トラフィック（North-South 送信トラフィックフロー）を SNAT 変換するように構成されています。リージョンフェイルオーバーは手動でトリガーします。このチュートリアルでは、内部パススルーネットワークロードバランサをネクストホップとして使用し、対称ハッシュを使用する East-West 接続についても説明します。

このセクションでは、以下の構成方法について説明します。

カスタムサブネットのある VPC ネットワークのサンプル
バックエンド VM への受信接続を許可するファイアウォールルール
NAT ゲートウェイをデプロイするバックエンドマネージドインスタンスグループ
接続をテストするクライアント VM
次の内部パススルーネットワークロードバランサのコンポーネント:
- バックエンドサービスのヘルスチェック
- 内部バックエンドサービス
- ロードバランサのフロントエンドの内部転送ルールと IP アドレス

この例のアーキテクチャは次のようになります。

ネクストホップ構成としての内部パススルーネットワークロードバランサ（クリックして拡大）

このチュートリアルの手順では、REGION_A と REGION_B をこの例で使用するリージョンに置き換えます。

VPC ネットワークとサブネットを作成する

hub-vpc という VPC ネットワークを作成します。

gcloud compute networks create hub-vpc --subnet-mode custom

REGION_A の hub-vpc にサブネットを作成します。

gcloud compute networks subnets create hub-subnet-a \
    --network hub-vpc \
    --range 10.0.0.0/24 \
    --region REGION_A

region B の hub-vpc にサブネットを作成します。

gcloud compute networks subnets create hub-subnet-b \
    --network hub-vpc \
    --range 10.0.1.0/24 \
    --region REGION_B

spoke1-vpc という VPC ネットワークを作成します。

gcloud compute networks create spoke1-vpc --subnet-mode custom

spoke1-vpc にサブネットを作成します。

gcloud compute networks subnets create spoke1-subnet1 \
    --network spoke1-vpc \
    --range 192.168.0.0/24 \
    --region REGION_A

spoke2-vpc という VPC ネットワークを作成します。

gcloud compute networks create spoke2-vpc --subnet-mode custom

spoke2-vpc にサブネットを作成します。

gcloud compute networks subnets create spoke2-subnet1 \
    --network spoke2-vpc \
    --range 192.168.1.0/24 \
    --region REGION_A

ファイアウォールルールを構成する

指定した送信元の範囲からインスタンスに TCP、UDP、ICMP トラフィックが到達できるように、次のファイアウォールルールを構成します。

gcloud compute firewall-rules create hub-vpc-web-ping-dns \
    --network hub-vpc \
    --allow tcp:80,tcp:443,icmp,udp:53 \
    --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24

gcloud compute firewall-rules create spoke1-vpc-web-ping-dns \
    --network spoke1-vpc \
    --allow tcp:80,tcp:443,icmp,udp:53 \
    --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24

gcloud compute firewall-rules create spoke2-vpc-web-ping-dns \
    --network spoke2-vpc \
    --allow tcp:80,tcp:443,icmp,udp:53 \
    --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24

ヘルスチェックプローバーが hub-vpc のインスタンスにアクセスできるようにファイアウォールルールを作成します。

gcloud compute firewall-rules create hub-vpc-health-checks \
    --network hub-vpc \
    --allow tcp:80 \
    --target-tags natgw \
    --source-ranges 130.211.0.0/22,35.191.0.0/16

すべてのサブネット上のインスタンスに SSH アクセスを許可するファイアウォールルールを作成します。TCP 転送に Identity-Aware Proxy を使用する場合（推奨の方法）は、SSH を有効にする手順を行います。

gcloud compute firewall-rules create hub-vpc-allow-ssh \
    --network hub-vpc \
    --allow tcp:22

gcloud compute firewall-rules create spoke1-vpc-allow-ssh \
    --network spoke1-vpc \
    --allow tcp:22

gcloud compute firewall-rules create spoke2-vpc-allow-ssh \
    --network spoke2-vpc \
    --allow tcp:22

VPC ネットワークピアリングを構成する

hub-vpc から spoke1-vpc へのピアリングを作成します。

gcloud compute networks peerings create hub-to-spoke1 \
    --network hub-vpc \
    --peer-network spoke1-vpc \
    --peer-project PROJECT_ID \
    --export-custom-routes

spoke1-vpc から hub-vpc へのピアリングを作成します。

gcloud compute networks peerings create spoke1-to-hub \
    --network spoke1-vpc \
    --peer-network hub-vpc \
    --peer-project PROJECT_ID \
    --import-custom-routes

hub-vpc から spoke2-vpc へのピアリングを作成します。

gcloud compute networks peerings create hub-to-spoke2 \
    --network hub-vpc \
    --peer-network spoke2-vpc \
    --peer-project PROJECT_ID \
    --export-custom-routes

spoke2-vpc から hub-vpc へのピアリングを作成します。

gcloud compute networks peerings create spoke2-to-hub \
    --network spoke2-vpc \
    --peer-network hub-vpc \
    --peer-project PROJECT_ID \
    --import-custom-routes

リージョン A に NAT ゲートウェイ VM とロードバランシングリソースを作成する

REGION_A に、マネージドインスタンスグループのバックエンドを作成します。ロードバランシングリソースとネクストホップルートを作成します。

マネージドインスタンスグループを作成する

region A に、NAT ゲートウェイをデプロイするためのインスタンステンプレートを作成します。

gcloud compute instance-templates create hub-natgw-region-a-template \
    --network hub-vpc \
    --subnet hub-subnet-a \
    --region REGION_A \
    --machine-type n1-standard-2 \
    --can-ip-forward \
    --tags natgw \
    --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
# iptables configuration
iptables -t nat -F
sudo iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -j MASQUERADE
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 tcpdump -y
a2ensite default-ssl
a2enmod ssl
echo "Example web page to pass health check" | \
tee /var/www/html/index.html \
systemctl restart apache2'

REGION_A にインスタンスグループを作成します。

gcloud compute instance-groups managed create hub-natgw-region-a-mig \
    --region REGION_A \
    --size=2 \
    --template=hub-natgw-region-a-template

ロードバランサを作成する

次の手順で REGION_A にロードバランサを作成します。

ヘルスチェックを作成します。

gcloud compute health-checks create http natgw-ilbnhop-health-check \
    --port=80

バックエンドサービスを作成します。

gcloud compute backend-services create hub-natgw-region-a-be \
    --load-balancing-scheme=internal \
    --protocol tcp \
    --region REGION_A\
    --health-checks=natgw-ilbnhop-health-check

バックエンドとしてマネージドインスタンスグループを追加します。

gcloud compute backend-services add-backend hub-natgw-region-a-be \
    --instance-group=hub-natgw-region-a-mig \
    --instance-group-region=REGION_A

転送ルールを作成します。

gcloud compute forwarding-rules create hub-natgw-region-a \
    --load-balancing-scheme=internal \
    --network=hub-vpc \
    --subnet=hub-subnet-a \
    --address=10.0.0.10 \
    --ip-protocol=TCP \
    --ports=all \
    --allow-global-access \
    --backend-service=hub-natgw-region-a-be \
    --backend-service-region=REGION_A

ネクストホップのルートを作成する

事前定義のネットワークタグ ilbanh-region-a を使用して、内部パススルーネットワークロードバランサをネクストホップルートとして作成します。

gcloud compute routes create spoke1-natgw-region-a \
    --network=spoke1-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.0.10 \
    --tags=ilbanh-region-a \
    --priority 800

gcloud compute routes create spoke2-natgw-region-a \
    --network=spoke2-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.0.10 \
    --tags=ilbanh-region-a \
    --priority 800

接続をテストする

クライアントインスタンスを作成して接続をテストします。

spoke1-vpc にテストクライアントインスタンスを作成します。

gcloud compute instances create spoke1-client \
    --subnet=spoke1-subnet1 --no-address --zone ZONE_A \
    --tags=ilbanh-region-a \
    --metadata startup-script='#! /bin/bash
apt-get update
apt-get install tcpdump -y'

spoke2-vpc にテストクライアントインスタンスを作成します。

gcloud compute instances create spoke2-client \
    --subnet=spoke2-subnet1 --no-address --zone ZONE_A \
    --tags=ilbanh-region-a \
    --metadata startup-script='#! /bin/bash
apt-get update
apt-get install tcpdump -y'

North-South と East-West のトラフィックフローを検証する

NAT ゲートウェイ VM が実行されていることを確認し、割り当てられた外部 IP アドレスをメモします。
```
gcloud compute instances list --filter="status:RUNNING AND name~natgw"
```

ロードバランサが正常で、ルートが想定どおり作成されていることを確認します。

gcloud compute backend-services get-health hub-natgw-region-a-be --region REGION_A

backend: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/instanceGroups/hub-natgw-region-a-mig
status:
  healthStatus:
  - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/forwardingRules/hub-natgw-region-a
    forwardingRuleIp: 10.0.0.10
    healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-central1-b/instances/<INSTANCE_NAME>
    ipAddress: 10.0.0.5
    port: 80
  - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/forwardingRules/hub-natgw-region-a
    forwardingRuleIp: 10.0.0.10
    healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-central1-f/instances/<INSTANCE_NAME>
    ipAddress: 10.0.0.6
    port: 80
  kind: compute#backendServiceGroupHealth

ネクストホップとしての内部パススルーネットワークロードバランサが、想定される優先度でスポーク VPC に追加され、内部パススルーネットワークロードバランサの IP アドレスをターゲットにしていることを確認します。
```
gcloud compute routes list --filter="name~natgw"
```
Google Cloud コンソールに移動し、別のタブで NAT ゲートウェイ VM への SSH 接続を確立します。
各 SSH セッションで、次のコマンドを使用して tcpdump を開始します。
```
sudo tcpdump -n net 192.168.0.0/16
```
Google Cloud コンソールに移動し、spoke1-client VM への新しい SSH 接続を確立します。次のコマンドを使用して、spoke2-client 内部 IP アドレスに ping を実行します。
```
ping SPOKE2_CLIENT_INTERNAL_IP
```
NAT ゲートウェイの SSH ウィンドウに切り替えます。ICMP パケットが次のように表示されることを確認します。
```
16:51:28.411260 IP 192.168.0.2 > 192.168.1.2: ICMP echo request, id 1684, seq 492, length 64
16:51:28.411676 IP 192.168.1.2 > 192.168.0.2: ICMP echo reply, id 1684, seq 492, length 64
```
クライアント VM への ping が成功しているはずです。これは、次のことを示します。
- East-West トラフィックが NAT ゲートウェイ経由で有効になります。スポーク VPC 間で推移的ピアリングはサポートされません。
- 対称ハッシュが有効になり、想定どおり動作します。クライアントは送信元 IP アドレスを使用して通信できるため、SNAT 変換を行う必要はありません。
- すべてのプロトコルは、ネクストホップとしての内部パススルーネットワークロードバランサでサポートされています。
NAT ゲートウェイ VM で tcpdump の出力を停止し、iptables の統計情報を確認します。
```
watch sudo iptables -t nat -nvL
```
spoke1-client VM に戻り、次のコマンドを複数回実行します。出力に、ウェブサイトへの接続に使用されているパブリック送信元 IP アドレスが表示されます。
```
curl ifconfig.io
```
両方の NAT ゲートウェイ VM の IP アドレスが送信元 IP アドレスとして表示されます。これは、内部パススルーネットワークロードバランサがデフォルトのアフィニティ（5 タプルハッシュ）に基づいてトラフィックを分散していることを示しています。

NAT ゲートウェイ VM に戻り、パケットカウンタの値が増加していることを確認します。

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  105 11442 MASQUERADE  all  --  *      *       0.0.0.0/0           !192.168.0.0/16

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

リージョン B に NAT ゲートウェイ VM とロードバランシングリソースを作成する

region B に、マネージドインスタンスグループのバックエンドを作成します。ロードバランシングリソースとネクストホップルートを作成します。

マネージドインスタンスグループを作成する

region B に、NAT ゲートウェイをデプロイするためのインスタンステンプレートを作成します。

gcloud compute instance-templates create hub-natgw-region-b-template \
    --network hub-vpc \
    --subnet hub-subnet-b --region REGION_B \
    --machine-type n1-standard-2 --can-ip-forward \
    --tags natgw \
    --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
# iptables configuration
iptables -t nat -F
sudo iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -j MASQUERADE
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 tcpdump -y
a2ensite default-ssl
a2enmod ssl
echo "Example web page to pass health check" | \
tee /var/www/html/index.html \
systemctl restart apache2'

region B にインスタンスグループを作成します。

gcloud compute instance-groups managed create hub-natgw-region-b-mig \
    --region REGION_B \
    --size=2 \
    --template=hub-natgw-region-b-template

ロードバランサを作成する

次の手順でリージョン B にロードバランサを作成します。

バックエンドサービスを作成します。

gcloud compute backend-services create hub-natgw-region-b-be \
    --load-balancing-scheme=internal \
    --protocol tcp \
    --region REGION_B\
    --health-checks=natgw-ilbnhop-health-check

バックエンドとしてマネージドインスタンスグループを追加します。

gcloud compute backend-services add-backend hub-natgw-region-b-be \
    --instance-group=hub-natgw-region-b-mig \
    --instance-group-region=REGION_B

転送ルールを作成します。

gcloud compute forwarding-rules create hub-natgw-region-b \
    --load-balancing-scheme=internal \
    --network=hub-vpc \
    --subnet=hub-subnet-b \
    --address=10.0.1.10 \
    --ip-protocol=TCP \
    --ports=all \
    --allow-global-access \
    --backend-service=hub-natgw-region-b-be \
    --backend-service-region=REGION_B

ネクストホップのルートを作成する

事前定義のネットワークタグ ilbanh-region-a を使用して、内部パススルーネットワークロードバランサをネクストホップルートとして作成します。

gcloud compute routes create spoke1-natgw-region-b \
    --network=spoke1-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.1.10 \
    --tags=ilbanh-region-a \
    --priority 900

gcloud compute routes create spoke2-natgw-region-b \
    --network=spoke2-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.1.10 \
    --tags=ilbanh-region-a \
    --priority 900

リージョンフェイルオーバーを検証する

NAT ゲートウェイ VM が実行されていることを確認し、割り当てられた外部 IP をメモします。
```
gcloud compute instances list --filter="status:RUNNING AND name~natgw"
```

ロードバランサが正常な状態で、ルートが想定どおり作成されていることを確認します。

gcloud compute backend-services get-health hub-natgw-region-b-be --region REGION_B

backend: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/instanceGroups/hub-natgw-region-b-mig
status:
  healthStatus:
  - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/forwardingRules/hub-natgw-region-b
    forwardingRuleIp: 10.0.1.10
    healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-west2-a/instances/<INSTANCE_NAME>
    ipAddress: 10.0.1.3
    port: 80
  - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/forwardingRules/hub-natgw-region-b
    forwardingRuleIp: 10.0.1.10
    healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-west2-b/instances/<INSTANCE_NAME>
    ipAddress: 10.0.1.2
    port: 80
  kind: compute#backendServiceGroupHealth

ネクストホップとしての内部パススルーネットワークロードバランサが、想定される優先度でスポーク VPC に追加され、内部パススルーネットワークロードバランサの IP アドレスをターゲットにしていることを確認します。
```
gcloud compute routes list --filter="name~natgw"
```
これで、優先度の高いルートを削除して状況を記録し、リージョンフェイルオーバーを検証できるようになりました。spoke1-client VM に切り替えて次のコマンドを実行します。1 秒ごとに curl リクエストが送信されます。このコマンドは、使用されている外部 IP アドレスも報告します。
```
while true; do echo -n `date` && echo -n ' - ' && curl ifconfig.io --connect-timeout 1; done
```
region A の NAT ゲートウェイに割り当てられた外部 IP アドレスが優先されます。これは、優先度が最も高いルートです。curl コマンドを実行したまま Cloud Shell に切り替え、region A の内部パススルーネットワークロードバランサへのルートを削除して結果を確認します。
```
gcloud -q compute routes delete spoke1-natgw-region-a
```
region B に、NAT ゲートウェイ VM に割り当てられた外部 IP アドレスが表示されます。ダウンタイムは最小のはずです。これは、リージョンフェイルオーバーが成功したことを示しています。

リソースのクリーンアップ

ネクストホップルートとして設定した内部パススルーネットワークロードバランサを削除します。

gcloud -q compute routes delete spoke1-natgw-region-b

gcloud -q compute routes delete spoke2-natgw-region-a

gcloud -q compute routes delete spoke2-natgw-region-b

内部パススルーネットワークロードバランサのリソースとバックエンドを削除します。

gcloud -q compute forwarding-rules delete hub-natgw-region-a \
  --region REGION_A

gcloud -q compute backend-services delete hub-natgw-region-a-be \
  --region REGION_A

gcloud -q compute instance-groups managed delete hub-natgw-region-a-mig \
  --region REGION_A

gcloud -q compute instance-templates delete hub-natgw-region-a-template

gcloud -q compute forwarding-rules delete hub-natgw-region-b \
  --region REGION_B

gcloud -q compute backend-services delete hub-natgw-region-b-be \
  --region REGION_B

gcloud -q compute instance-groups managed delete hub-natgw-region-b-mig \
  --region REGION_B

gcloud -q compute instance-templates delete hub-natgw-region-b-template

gcloud -q compute health-checks delete natgw-ilbnhop-health-check

クライアント VM を削除します。

gcloud -q compute instances delete spoke1-client \
  --zone=ZONE_A

gcloud -q compute instances delete spoke2-client \
  --zone=ZONE_A

VPC ネットワークピアリング、ファイアウォールルール、サブネット、VPC を削除します。

gcloud -q compute networks peerings delete spoke2-to-hub \
  --network spoke2-vpc

gcloud -q compute networks peerings delete spoke1-to-hub \
  --network spoke1-vpc

gcloud -q compute networks peerings delete hub-to-spoke1 \
  --network hub-vpc

gcloud -q compute networks peerings delete hub-to-spoke2 \
  --network hub-vpc

gcloud -q compute firewall-rules delete spoke2-vpc-web-ping-dns

gcloud -q compute firewall-rules delete spoke1-vpc-web-ping-dns

gcloud -q compute firewall-rules delete hub-vpc-web-ping-dns

gcloud -q compute firewall-rules delete hub-vpc-health-checks

gcloud -q compute firewall-rules delete hub-vpc-allow-ssh

gcloud -q compute firewall-rules delete spoke1-vpc-allow-ssh

gcloud -q compute firewall-rules delete spoke2-vpc-allow-ssh

gcloud -q compute networks subnets delete spoke1-subnet1 \
  --region REGION_A

gcloud -q compute networks subnets delete spoke2-subnet1 \
  --region REGION_A

gcloud -q compute networks subnets delete hub-subnet-a \
  --region REGION_A

gcloud -q compute networks subnets delete hub-subnet-b \
  --region REGION_B

gcloud -q compute networks delete spoke1-vpc

gcloud -q compute networks delete spoke2-vpc

gcloud -q compute networks delete hub-vpc

次のステップ

フェイルオーバーに関する重要な情報については、内部パススルーネットワークロードバランサのフェイルオーバーのコンセプトをご覧ください。
内部パススルーネットワークロードバランサの Logging と Monitoring の構成については、内部パススルーネットワークロードバランサのロギングとモニタリングをご覧ください。
VPC ネットワークに接続されたピアネットワークから内部パススルーネットワークロードバランサにアクセスする方法については、内部パススルーネットワークロードバランサと接続ネットワークをご覧ください。
内部パススルーネットワークロードバランサの問題をトラブルシューティングする方法については、内部パススルーネットワークロードバランサのトラブルシューティングをご覧ください。

内部パススルー ネットワーク ロードバランサをネクストホップとして設定する（タグを使用）

設定の概要

VPC ネットワークとサブネットを作成する

ファイアウォール ルールを構成する

VPC ネットワーク ピアリングを構成する

リージョン A に NAT ゲートウェイ VM とロード バランシング リソースを作成する

マネージド インスタンス グループを作成する

ロードバランサを作成する

ネクストホップのルートを作成する

接続をテストする

North-South と East-West のトラフィック フローを検証する

リージョン B に NAT ゲートウェイ VM とロード バランシング リソースを作成する

マネージド インスタンス グループを作成する

ロードバランサを作成する

ネクストホップのルートを作成する

リージョン フェイルオーバーを検証する

リソースのクリーンアップ

次のステップ

内部パススルーネットワークロードバランサをネクストホップとして設定する（タグを使用）

ファイアウォールルールを構成する

VPC ネットワークピアリングを構成する

リージョン A に NAT ゲートウェイ VM とロードバランシングリソースを作成する

マネージドインスタンスグループを作成する

North-South と East-West のトラフィックフローを検証する

リージョン B に NAT ゲートウェイ VM とロードバランシングリソースを作成する

マネージドインスタンスグループを作成する

リージョンフェイルオーバーを検証する