このチュートリアルでは、VPC ネットワーク ピアリングを使用してハブアンドスポーク アーキテクチャをデプロイする方法について説明します。
このチュートリアルは、一元管理を行うハブ アプライアンスを複数の Compute Engine 仮想マシンで構成し、Google Cloud 環境にハブアンドスポーク アーキテクチャを実装することを検討しているクラウド ネットワーク エンジニアや運用担当者を対象としています。このチュートリアルでは、各仮想マシンを NAT ゲートウェイとしてデプロイしますが、次世代ファイアウォールなどの他の機能にも同じ手法を使用できます。このチュートリアルは、VPC ネットワークと Compute Engine に精通していることを前提としています。
アーキテクチャ
このアーキテクチャでは、一連のスポーク VPC ネットワークはハブ VPC ネットワークを介して外部と通信を行います。ハブ VPC ネットワークでは、一元管理を行うアプライアンスのプール（ここではネットワーク アドレス変換（NAT）ゲートウェイ）を経由してトラフィックがルーティングされます。関連するルートは、ハブ VPC ネットワークからスポーク VPC ネットワークにエクスポートされます。NAT ゲートウェイは内部ロードバランサのバックエンドとして構成し、Cloud Load Balancing の内部パススルー ネットワーク ロードバランサをネクストホップとするデフォルト ルートを新たに追加します。
等価コスト マルチパス（ECMP）方式のルーティングで複数のルートを使用しても、内部ロードバランサと同じタイプの負荷分散と高可用性を実現できますが、内部パススルー ネットワーク ロードバランサには次の利点があります。
- ヘルスチェックを使用している場合、トラフィックは正常なインスタンスに転送されます。ECMP を使用すると、ルートがポイントするすべてのアクティブ インスタンスにトラフィックが転送されます。内部パススルー ネットワーク ロードバランサを使用すると、未使用のルートが生じる可能性を排除します。インスタンスの終了時や再起動時にルートをクリーンアップする必要もありません。
- ヘルスチェック タイマーを微調整できるため、フェイルオーバーの処理時間が短縮される可能性があります。マネージド インスタンス グループと自動修復を使用する場合もヘルスチェック タイマーをカスタマイズできますが、対象となるのはトラフィックのルーティングではなくインスタンスの再作成です。
Google では、マネージド サービスとして Cloud NAT も提供しています。これを使用すれば、ユーザーによる管理や操作なしで高可用性を実現できます。ただし、Cloud NAT はこのユースケースではサポートされません。これは、NAT 構成がピアリング ネットワークにインポートされないためです。
次の図は、このチュートリアルで構築するトポロジを表したものです。
このトポロジは、1 つのハブ VPC ネットワークと 2 つのスポーク VPC ネットワークで構成されています。スポーク VPC ネットワークは、VPC ネットワーク ピアリングを使用して、ハブ VPC ネットワークとピアリングされています。ハブ VPC ネットワークには、内部パススルー ネットワーク ロードバランサの背後に 2 つの NAT ゲートウェイ インスタンスがあります。静的デフォルト ルート（0/0 NAT-GW-ILB）は、ネクストホップとして内部パススルー ネットワーク ロードバランサをポイントします。この静的デフォルト ルートは、カスタムルートを使用して、VPC ネットワーク ピアリング経由でエクスポートされます。
目標
- 複数の VPC ネットワークを作成し、ハブアンドスポーク アーキテクチャを使用してピアリングする。
- ハブ VPC ネットワークで NAT ゲートウェイを作成して構成する。
- 内部パススルー ネットワーク ロードバランサを設定し、ネクストホップとして構成する。
- スポーク VPC ネットワークからパブリック インターネットへの接続を確認する。
費用
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
始める前に
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Compute Engine API.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Compute Engine API.
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
このチュートリアルでは、すべてのコマンドを Cloud Shell で実行します。
環境設定
Cloud Shell で、自身が作成または選択した Google Cloud プロジェクトで作業していることを確認します。
project-idは、Google Cloud プロジェクトに置き換えます。gcloud config set project project-id export PROJECT_ID=`gcloud config list --format="value(core.project)"`
デフォルトのコンピューティング リージョンとゾーンを設定します。
gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-c export REGION=us-central1 export ZONE=us-central1-cこのチュートリアルでは、リージョンは
us-central1、ゾーンはus-central1-cです。
VPC ネットワークとサブネットの作成
Cloud Shell で、ハブ VPC ネットワークとサブネットを作成します。
gcloud compute networks create hub-vpc --subnet-mode custom gcloud compute networks subnets create hub-subnet1 \ --network hub-vpc --range 10.0.0.0/24spoke1-vpcおよびspoke2-vpcという名前のスポーク VPC ネットワークを作成します。次に示すように、それぞれ 1 つのサブネットを指定します。gcloud compute networks create spoke1-vpc --subnet-mode custom gcloud compute networks create spoke2-vpc --subnet-mode custom gcloud compute networks subnets create spoke1-subnet1 \ --network spoke1-vpc --range 192.168.1.0/24 gcloud compute networks subnets create spoke2-subnet1 \ --network spoke2-vpc --range 192.168.2.0/24ハブ VPC ネットワークとスポーク VPC ネットワークにファイアウォール ルールを作成します。これらのルールでは、指定された RFC 1918 範囲からの内部トラフィック（TCP/80 と 443、UDP/53、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,192.168.1.0/24,192.168.2.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,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,192.168.2.0/24SSH 接続で使用する IAP がすべての仮想マシンにアクセスできるように、ハブ VPC ネットワークとスポーク VPC ネットワークのファイアウォール ルールを作成します。
gcloud compute firewall-rules create hub-vpc-iap \ --network hub-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20 gcloud compute firewall-rules create spoke1-vpc-iap \ --network spoke1-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20 gcloud compute firewall-rules create spoke2-vpc-iap \ --network spoke2-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20このチュートリアルでは、SSH 接続に Identity-Aware Proxy（IAP）を使用します。詳細については、外部 IP アドレスを持たないインスタンスへの接続をご覧ください。
ハブ VPC ネットワークで自動修復インスタンス グループのヘルスチェックを許可するファイアウォール ルールを作成します。
gcloud compute firewall-rules create hub-vpc-health-checks \ --network hub-vpc --allow tcp:443 --target-tags nat-gw \ --source-ranges 130.211.0.0/22,35.191.0.0/16
インスタンスと必要なルートの作成
Cloud Shell で、NAT ゲートウェイ用のインスタンス テンプレートを作成します。このテンプレートには、NAT ゲートウェイを設定する起動スクリプトが含まれます。
gcloud compute instance-templates create \ hub-nat-gw-ilbnhop-template \ --network hub-vpc \ --subnet hub-subnet1 \ --machine-type n1-standard-2 --can-ip-forward \ --tags nat-gw --scopes default,compute-rw \ --metadata startup-script='#! /bin/bash apt-get update # Enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf # Read VM network configuration: md_vm="http://metadata.google.internal/computeMetadata/v1/instance/" md_net="$md_vm/network-interfaces" nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google")" nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")" nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")" nic0_id="$(ip addr show | grep $nic0_addr | tail -c 5)" # Use a web server to pass the health check for this example. # In production, use a more complete test. sudo apt-get update sudo apt-get install apache2 -y sudo a2ensite default-ssl sudo a2enmod ssl echo "Example web page to pass health check" | \ tee /var/www/html/index.html sudo systemctl restart apache2 # Enable IP masquerading iptables -t nat -A POSTROUTING -o $nic0_id -j MASQUERADE'このチュートリアルでは、インスタンス タイプとして
n1-standard-2を使用しますが、それ以外の任意の数やサイズのゲートウェイも使用できます。VM あたりの最大下り（外向き）帯域幅などの要素を考慮してください。HTTP ヘルスチェックを作成します。
gcloud compute health-checks create http nat-gw-ilbnhop-health-check \ --region us-central1 \ --port 80単一のリージョン内で分散する 2 つのインスタンスを持つリージョン インスタンス グループを作成します。
gcloud compute instance-groups managed create \ hub-nat-gw-ilbnhop-mig \ --region us-central1 --size=2 \ --template=hub-nat-gw-ilbnhop-template \ --health-check nat-gw-ilbnhop-health-check \ --initial-delay 15このチュートリアルでは、初期遅延を 15 秒に設定します。本番環境のデプロイでは、要件に応じてこの設定をカスタマイズしてください。このチュートリアルでは、自動スケーリング ポリシーは使用しません。
バックエンド サービスを作成し、インスタンス グループを追加します。
gcloud compute backend-services create hub-nat-gw-ilbnhop-backend \ --load-balancing-scheme=internal \ --protocol=tcp \ --health-checks=nat-gw-ilbnhop-health-check gcloud compute backend-services add-backend \ hub-nat-gw-ilbnhop-backend \ --instance-group=hub-nat-gw-ilbnhop-mig \ --instance-group-region=us-central1転送ルールを作成します。
gcloud compute forwarding-rules create \ hub-nat-gw-ilbnhop \ --load-balancing-scheme=internal \ --network=hub-vpc \ --subnet=hub-subnet1 \ --address=10.0.0.10 \ --ip-protocol=TCP \ --ports=all \ --backend-service=hub-nat-gw-ilbnhop-backend \ --backend-service-region=us-central1 \ --service-label=hub-nat-gw-ilbnhop転送ルールに TCP のみが定義されていても、内部パススルー ネットワーク ロードバランサをネクストホップとして使用すると、転送ルールはバックエンド VM のすべてのポートにすべてのトラフィックを転送します。内部パススルー ネットワーク ロードバランサはリージョン ロードバランサです。
新しいルートを作成し、上記で作成した転送ルールをネクストホップに指定します。
gcloud compute routes create hub-nat-gw-ilbnhop \ --network=hub-vpc \ --destination-range=0.0.0.0/0 \ --next-hop-ilb=hub-nat-gw-ilbnhop \ --next-hop-ilb-region=us-central1 \ --priority=800ネクストホップ ルートがタグで構成されたクライアント インスタンスにのみ適用され、タグは VPC ネットワーク ピアリングを介してエクスポートまたはインポートされないように、ネットワーク タグを指定できます。
ハブ VPC からデフォルト ルートを削除します。
export hub_default_route=$(gcloud compute routes list \ --format="value(name)" --filter="network:hub-vpc AND \ nextHopGateway:default-internet-gateway" | head -n 1) gcloud compute routes delete $hub_default_route -qNAT ゲートウェイからのトラフィックのみを許可する新しいタグ付きルートを作成します。
gcloud compute routes create hub-default-tagged \ --network hub-vpc --destination-range 0.0.0.0/0 \ --next-hop-gateway default-internet-gateway \ --priority 700 --tags nat-gw各スポークの VPC からインターネットへのデフォルト ルートを削除します。
export spoke1_default_route=$(gcloud compute routes list \ --format="value(name)" --filter="network:spoke1-vpc AND \ nextHopGateway:default-internet-gateway") gcloud compute routes delete $spoke1_default_route -q export spoke2_default_route=$(gcloud compute routes list \ --format="value(name)" \ --filter="network:spoke2-vpc AND nextHopGateway:default-internet-gateway") gcloud compute routes delete $spoke2_default_route -qローカルルートとインポートされたルートの間に競合がある場合、常にローカルルートが優先されます。詳細については、ルーティング順序をご覧ください。
クライアント VM を作成します。
gcloud compute instances create spoke1-client \ --subnet=spoke1-subnet1 --no-address \ --metadata startup-script='#! /bin/bash apt-get update apt-get install dnsutils -y' gcloud compute instances create spoke2-client \ --subnet=spoke2-subnet1 --no-address \ --metadata startup-script='#! /bin/bash apt-get update apt-get install dnsutils -y'
VPC ネットワーク ピアリング接続の作成
VPC ネットワーク ピアリングは双方向であるため、両端で定義する必要があります。1 つの VPC ネットワークを複数の VPC ネットワークにピアリングできますが、上限があります。VPC ネットワーク ピアリングを介してデフォルト ルートに到達するには、VPC ネットワーク ピアリングを介してカスタムルートをインポートおよびエクスポートする機能を使用します。
このチュートリアルでは、すべての VPC ネットワークを同じ Google Cloud プロジェクトで作成します。
Cloud Shell で、ルートのエクスポート フラグを有効にして、ハブ VPC ネットワークからスポーク VPC ネットワークへの VPC 接続を作成します。
gcloud compute networks peerings create hub-to-spoke1 \ --network hub-vpc --peer-network spoke1-vpc \ --peer-project $PROJECT_ID \ --export-custom-routes gcloud compute networks peerings create hub-to-spoke2 \ --network hub-vpc --peer-network spoke2-vpc \ --peer-project $PROJECT_ID \ --export-custom-routesルートのインポート フラグを有効にして、
spoke1VPC ネットワークからハブ VPC ネットワークへの VPC ネットワーク ピアリング接続を作成します。gcloud compute networks peerings create spoke1-to-hub \ --network spoke1-vpc --peer-network hub-vpc \ --peer-project $PROJECT_ID \ --import-custom-routesルートのインポート フラグを有効にして、
spoke2VPC ネットワークからハブ VPC ネットワークへの VPC ネットワーク ピアリング接続を作成します。gcloud compute networks peerings create spoke2-to-hub \ --network spoke2-vpc --peer-network hub-vpc \ --peer-project $PROJECT_ID \ --import-custom-routes
ルートの伝播と接続の確認
Cloud Shell で、静的ルートが起動スクリプトの一部として正しく作成されたことを確認します。
gcloud compute routes list --filter="network:hub-vpc"出力に
hub-default-taggedルートとhub-nat-gw-ilbanhopルートが含まれていることを確認します。NAME NETWORK DEST_RANGE NEXT_HOP PRIORITY default-route-13a4b635b5eab48c hub-vpc 10.0.0.0/24 hub-vpc 1000 hub-default-tagged hub-vpc 0.0.0.0/0 default-internet-gateway 700 hub-nat-gw-ilbanhop hub-vpc 0.0.0.0/0 10.0.0.10 800 peering-route-3274f1257a9842a0 hub-vpc 192.168.2.0/24 hub-to-spoke2 1000 peering-route-798c5777f13094bc hub-vpc 192.168.1.0/24 hub-to-spoke1 1000
spoke1-vpcルーティング テーブルを確認して、デフォルト ルートが正しくインポートされたことを確認します。gcloud compute routes list --filter="network:spoke1-vpc"peering-routeで始まり、DEST_RANGE値が0.0.0.0/0であるルートが出力内にあることを確認します。NAME NETWORK DEST_RANGE NEXT_HOP PRIORITY default-route-75f6ea8f5fc54813 spoke1-vpc 192.168.1.0/24 spoke1-vpc 1000 peering-route-6c7f130b860bfd39 spoke1-vpc 10.0.0.0/24 spoke1-to-hub 1000 peering-route-9d44d362f98afbd8 spoke1-vpc 0.0.0.0/0 spoke1-to-hub 800
SSH を使用して、IAP 経由でいずれかのクライアントに接続します。
gcloud compute ssh spoke1-client --tunnel-through-iapNAT ゲートウェイ経由で Google Public DNS をテストし、接続を検証します。
sudo hping3 -S -p 80 -c 3 dns.google内部パススルー ネットワーク ロードバランサでサポートされているのは TCP と UDP であるため、ICMP ベースの ping を使用してインターネット接続を検証することはできません。そのため、hping3 などのツールを使用する必要があります。
出力は次のようになります。
HPING dns.google (eth0 8.8.4.4): S set, 40 headers + 0 data bytes len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=0 win=65535 rtt=4.6 ms len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=1 win=65535 rtt=4.4 ms len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=2 win=65535 rtt=4.3 ms --- dns.google hping statistic --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 4.3/4.4/4.6 ms
インターネットとの通信に使用するパブリック IP アドレスを検証します。
curl ifconfig.co出力に、いずれかの NAT ゲートウェイ インスタンスのパブリック IP アドレスが表示されます。このコマンドを再度実行すると、出力に異なるパブリック IP アドレスが表示されることがあります。これは、構成した内部ロード バランシング セッション アフィニティ（デフォルトではクライアント IP、プロトコル、ポート）を使用して接続が分散されるためです。
VPC ネットワーク ピアリングは推移的ではないため、スポーク VPC ネットワーク同士が VPC ネットワーク ピアリングで接続されることはありません。
本番環境に関する考慮事項
このチュートリアルで作成する構成では、1 つのリージョンに 2 つの NAT ゲートウェイを配置します。ただし、ECMP ロード バランシングは完璧ではなく、個々のフローが複数のリンクに分散されるわけではありません。このような動作は、次世代のファイアウォールなどのステートフル デバイスを使用するときに必要になります。
この構成を本番環境にデプロイする場合は、次の点を考慮してください。
- この構成は、一時的または非ステートフルなアウトバウンド リンクに最適です。NAT ゲートウェイ プールのサイズを変更すると、TCP 接続が再バランスされるため、確立済みの接続がリセットされる場合があります。
- ノードは自動的には更新されないため、デフォルトの Debian インストールにセキュリティ上の脆弱性がある場合は、イメージを手動で更新する必要があります。
- VM が複数のリージョンにまたがる場合は、各リージョンに NAT ゲートウェイを設定する必要があります。
- ゲートウェイあたりの帯域幅は、ハードウェアの種類によって異なります。VM あたりの最大下り（外向き）帯域幅などの要素を考慮してください。あるゲートウェイで障害が発生すると、トラフィックは残りのゲートウェイに分散されます。実行中のフローは再プログラムされないため、ゲートウェイがオンライン状態に戻っても、トラフィックがすぐに安定することはありません。したがって、サイジングの際は必ず十分なオーバーヘッドを確保してください。
- 予期しない結果に対して通知を受け取るには、Cloud Monitoring を使用してマネージド インスタンス グループとネットワーク トラフィックをモニタリングします。
クリーンアップ
課金を停止する最も簡単な方法は、チュートリアル用に作成した Google Cloud プロジェクトを削除することです。また、リソースを個別に削除することもできます。
プロジェクトの削除
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
個々のリソースを削除する
Google Cloud プロジェクトを残しておく場合は、このチュートリアル用に作成したリソースを削除できます。
VPC ネットワーク ピアリング接続を削除します。
gcloud compute networks peerings delete spoke2-to-hub \ --network spoke2-vpc -q gcloud compute networks peerings delete spoke1-to-hub \ --network spoke1-vpc -q gcloud compute networks peerings delete hub-to-spoke1 \ --network hub-vpc -q gcloud compute networks peerings delete hub-to-spoke2 \ --network hub-vpc -qインスタンス、ロードバランサ リソース、テンプレート、ルートを削除します。
gcloud compute instances delete spoke1-client \ --zone=us-central1-c -q gcloud compute instances delete spoke2-client \ --zone=us-central1-c -q gcloud compute routes delete hub-nat-gw-ilbnhop -q gcloud compute forwarding-rules delete hub-nat-gw-ilbnhop -q gcloud compute backend-services delete -q hub-nat-gw-ilbnhop-backend -q gcloud compute instance-groups managed delete hub-nat-gw-ilbnhop-mig \ --region us-central1 -q gcloud compute health-checks delete nat-gw-ilbnhop-health-check -q gcloud compute instance-templates delete hub-nat-gw-ilbnhop-template -q gcloud compute routes delete hub-default-tagged -qファイアウォール ルール、サブネット、VPC ネットワークを削除します。
gcloud compute firewall-rules delete spoke2-vpc-iap -q gcloud compute firewall-rules delete spoke2-vpc-web-ping-dns -q gcloud compute firewall-rules delete spoke1-vpc-iap -q gcloud compute firewall-rules delete spoke1-vpc-web-ping-dns -q gcloud compute firewall-rules delete hub-vpc-iap -q gcloud compute firewall-rules delete hub-vpc-web-ping-dns -q gcloud compute firewall-rules delete hub-vpc-health-checks -q gcloud compute networks subnets delete spoke1-subnet1 \ --region us-central1 -q gcloud compute networks subnets delete spoke2-subnet1 \ --region us-central1 -q gcloud compute networks subnets delete hub-subnet1 \ --region us-central1 -q gcloud compute networks delete spoke1-vpc -q gcloud compute networks delete spoke2-vpc -q gcloud compute networks delete hub-vpc -q
次のステップ
- VPC 設計のためのベスト プラクティスとリファレンス アーキテクチャを確認する。
- VPC ネットワーク ピアリングとネクストホップとしての内部パススルー ネットワーク ロードバランサのドキュメントを確認する。
- VM インスタンスの特別な構成を確認する。