1. はじめに
Private Service Connect を使用すると、VPC ネットワーク内のグローバル内部 IP アドレスを使用してプライベート エンドポイントを作成できます。これらの内部 IP アドレスには、storage-pscendpoint.p.googleapis.com や bigtable-adsteam.p.googleapis.com などの意味のある名前で DNS 名を割り当てることができます。storage.googleapis.com などのパブリック サービス エンドポイントに API リクエストを送信する代わりに、VPC ネットワーク内部の限定公開である Private Service Connect エンドポイントにリクエストを送信できます。
これらの名前と IP アドレスは、VPC ネットワークと、Cloud VPN トンネルまたは Cloud Interconnect アタッチメント(VLAN)を使用して接続されているオンプレミス ネットワークに対して内部的なものです。
エンドポイントに配信されるトラフィックを制御し、トラフィックを Google Cloud 内にとどめることができます。
学習内容
- Private Service Connect のユースケース
- ネットワークの要件
- サポートされている API
- Private Service Connect エンドポイントを作成する
- Cloud Storage バケットを作成する
- Cloud DNS 限定公開ゾーンの作成と更新
- NAT GW を作成してパブリック Apigee にアクセスする
- BOTO 構成ファイルの作成と更新
- PSC サービス エンドポイントに対して解決された VM1 で gsutil list を実行する
- VM2 で、公開 googleapis.com に対して解決された gsutil list を実行
- tcpdump を使用して DNS の解決を検証する
必要なもの
- DNS、nano または vi エディタに関する知識
2. Private Service Connect のユースケース
同じ VPC ネットワーク内に複数の Private Service Connect エンドポイントを作成できます。特定のエンドポイントへの帯域幅に制限はありません。Private Service Connect エンドポイントはグローバル内部 IP アドレスを使用するため、VPC ネットワーク内の任意のリソースで使用できます。
複数のエンドポイントがある場合は、Cloud Router とファイアウォール ルールを使用して異なるネットワーク パスを指定できます。
- ファイアウォール ルールを作成して、一部の VM には Private Service Connect エンドポイントを介した Google API へのアクセスを禁止し、他の VM にはアクセスを許可できます。
- VM インスタンスに、インターネットへのすべてのトラフィックを禁止するファイアウォール ルールを設定できます。Private Service Connect エンドポイントに送信されたトラフィックは、引き続き Google に到達します。
- Cloud VPN トンネルまたは Cloud Interconnect アタッチメント(VLAN)を使用して VPC に接続しているオンプレミス ホストがある場合、一部のリクエストをトンネルまたは VLAN 経由で送信し、他のリクエストを公共のインターネット経由で送信できます。この構成を使用すると、限定公開の Google アクセスでサポートされていない Google ブックスなどのサービスに対して、トンネルや VLAN をバイパスできます。この構成を作成するには、Private Service Connect エンドポイントを作成し、Cloud Router のカスタム ルート アドバタイズを使用して Private Service Connect エンドポイントの IP アドレスをアドバタイズして、Cloud DNS インバウンド転送ポリシーを有効にします。アプリケーションは、Private Service Connect エンドポイントの名前を使用して Cloud VPN トンネルまたは Cloud Interconnect アタッチメント(VLAN)経由でリクエストを送信し、その他のリクエストはデフォルトの DNS 名を使用してインターネット経由で送信できます。
- 複数の Cloud Interconnect アタッチメント(VLAN)を使用してオンプレミス ネットワークを VPC ネットワークに接続する場合、図 2 に示すように、オンプレミスからの一部のトラフィックを VLAN 経由で送信し、残りのトラフィックを VLAN 経由で送信できます。これにより、Google ではなく独自の広域ネットワーキングを使用し、地理的要件に合わせてデータの移動を制御できます。この構成を作成するには、2 つの Private Service Connect エンドポイントを作成します。1 つ目の VLAN を管理する Cloud Router の BGP セッションで、1 つ目のエンドポイントにカスタムルート アドバタイズを作成し、2 つ目の VLAN を管理する Cloud Router の BGP セッションで、2 つ目のエンドポイントに別のカスタム ルート アドバタイズを作成する。Private Service Connect エンドポイント名を使用するように構成されているオンプレミス ホストは、対応する Cloud Interconnect アタッチメント(VLAN)経由でトラフィックを送信します。
- アクティブ/アクティブ トポロジで複数の Cloud Interconnect アタッチメント(VLAN)を使用することもできます。VLAN を管理する Cloud Router の BGP セッションで、カスタムルート アドバタイズを使用して同じ Private Service Connect エンドポイント IP アドレスをアドバタイズすると、オンプレミス システムからエンドポイントに送信されるパケットは、ECMP を使用して VLAN 間でルーティングされます。
図 1. Private Service Connect、Cloud Router、オンプレミス ホストを構成することで、Google API へのトラフィックの送信に使用する Cloud Interconnect アタッチメント(VLAN)を制御できます。
3. ネットワークの要件
Private Service Connect を使用するには、外部 IP アドレスを持たない仮想マシン(VM)インスタンスのプライマリ インターフェースが、限定公開の Google アクセスが有効になっているサブネット内に必要です。
外部 IP アドレスを持つ VM は、そのサブネットで限定公開の Google アクセスが有効になっているかどうかにかかわらず、Private Service Connect エンドポイントを使用して Google API とサービスにアクセスできます。Private Service Connect エンドポイントへの接続は、Google のネットワーク内にとどまります。
Private Service Connect エンドポイントは、ピアリングされた VPC ネットワークからアクセスできません。
サポートされている API
Private Service Connect エンドポイントを作成するときに、アクセスする必要がある API のバンドル(all-apis または vpc-sc)を選択します。
API バンドルを使用すると、限定公開の Google アクセス VIP で利用できる API にアクセスできます。
- all-apis バンドルを使用すると、private.googleapis.com と同じ API にアクセスできます。
- vpc-sc バンドルは、restricted.googleapis.com と同じ API へのアクセスを提供します。
4. Codelab のトポロジとユースケース
図 1 - Codelab トポロジ
Codelab のユースケース -
お客様は、Cloud Storage のデータ転送にプライベート(相互接続)アクセスとパブリック googleapis アクセスを組み合わせて使用する必要があります。お客様の要件を満たすために、一意の /32 アドレス、BOTO 構成、DNS レコードの更新で構成される Private Service Connect をデプロイします。仮想マシン 1 は Cloud Storage バケットへのアクセスに PSC を使用します。一方、VM2 は NAT GW 経由でパブリック googleapis.com の IP 範囲を使用します。
このラボのすべての側面が Google Cloud Platform 内にデプロイされますが、トラフィックの分離を必要とするハイブリッド クラウド デプロイにも同じユースケースを適用できます。
5. 設定と要件
セルフペース型の環境設定
- Cloud Console にログインし、新しいプロジェクトを作成するか、既存のプロジェクトを再利用します(Gmail アカウントまたは G Suite アカウントをお持ちでない場合は、アカウントを作成する必要があります)。
プロジェクト ID を忘れないようにしてください。プロジェクト ID はすべての Google Cloud プロジェクトを通じて一意の名前にする必要があります(上記の名前はすでに使用されているので使用できません)。以降、このコードラボでは PROJECT_ID
と呼びます。
- 次に、Google Cloud リソースを使用するために、Cloud Console で課金を有効にする必要があります。
このコードラボを実行しても、費用はほとんどかからないはずです。このチュートリアル以外で請求が発生しないように、リソースのシャットダウン方法を説明する「クリーンアップ」セクションの手順に従うようにしてください。Google Cloud の新規ユーザーは $300 の無料トライアル プログラムをご利用いただけます。
Cloud Shell の起動
Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell(Cloud 上で動作するコマンドライン環境)を使用します。
GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。
プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。
この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。
6. 始める前に
API を有効にする
Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] projectname=YOUR-PROJECT-NAME echo $projectname
必要なサービスをすべて有効にする
gcloud services enable compute.googleapis.com gcloud services enable servicedirectory.googleapis.com gcloud services enable dns.googleapis.com
7. VPC ネットワークを作成
VPC ネットワーク
Cloud Shell から
gcloud compute networks create psc-lab --subnet-mode custom
出力
Created NAME SUBNET_MODE BGP_ROUTING_MODE IPV4_RANGE GATEWAY_IPV4 psc-lab CUSTOM REGIONAL
サブネットの作成
Cloud Shell から
gcloud compute networks subnets create psclab-subnet \ --network psc-lab --range 10.0.0.0/24 --region us-central1
–enable-private-ip-google-access
出力
Created NAME REGION NETWORK RANGE psclab-subnet us-central1 psc-lab 10.0.0.0/24
ファイアウォール ルールを作成する
Cloud Shell から
gcloud compute firewall-rules create psclab-ssh \ --network psc-lab --allow tcp:22 --source-ranges=35.235.240.0/20
出力
NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED psclab-ssh psc-lab INGRESS 1000 tcp:22 False
Cloud NAT インスタンスを作成する
Cloud Router の作成
Cloud Shell から
gcloud compute routers create crnat \ --network psc-lab \ --asn 65000 \ --region us-central1
Cloud NAT を作成する
Cloud Shell から
gcloud compute routers nats create cloudnat \ --router=crnat \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges \ --enable-logging \ --region us-central1
8. Private Service Connect エンドポイントを作成する
Private Service Connect エンドポイント IP <pscendpointip>
を構成する場合は、VPC で定義されていない一意の IP アドレスを指定する必要があります。
Cloud Shell から
gcloud beta compute addresses create psc-ip \ --global \ --purpose=PRIVATE_SERVICE_CONNECT \ --addresses=<pscendpointip> \ --network=psc-lab
「pscendpointip」を保存使用しないでください。
(gcloud compute addresses list --filter=name:psc-ip --format="value(address)") pscendpointip=$(gcloud compute addresses list --filter=name:psc-ip --format="value(address)") echo $pscendpointip
エンドポイントを Google API およびサービスに接続する転送ルールを作成します。
Cloud Shell から
gcloud beta compute forwarding-rules create pscendpoint \ --global \ --network=psc-lab \ --address=psc-ip \ --target-google-apis-bundle=all-apis
構成済みの Private Service Connect エンドポイントを一覧表示する
Cloud Shell から
gcloud compute forwarding-rules list \ --filter target="(all-apis OR vpc-sc)" --global
構成した Private Service Connect エンドポイントの説明を取得する
Cloud Shell から
gcloud compute forwarding-rules describe \ pscendpoint --global
9. バケットを作成する
Cloud Storage バケットを作成し、BUCKET_NAME を任意のグローバルに一意の名前に置き換えます。
Cloud Shell から
gsutil mb -l us-central1 -b on gs://BUCKET_NAME
'BUCKET_NAME' を保存使用しないでください。
BUCKET_NAME=YOUR BUCKET NAME echo $BUCKET_NAME
10. DNS 構成
Google Cloud Storage を使用するアプリケーションがあるとします。Private Service Connect を使用しない場合、アプリケーションは「storage.googleapis.com」に接続する可能性がありますが、デフォルトではパブリック アドレスに解決されます。Private Service Connect では、「storage-psclab.p.googleapis.com」などの名前を作成して使用できます。名前とアドレスは、VPC ネットワークと、接続されているすべてのオンプレミス ネットワークに対して限定公開です。
DNS 用の Private Service Connect は、SERVICE-ENDPOINT.p.googleapis.com の命名規則に従います。上記の例では、「storage」はSERVICE と「psclab」エンドポイントです必ず「-」記号を接続されています。
Private Service Connect エンドポイントを使用して Cloud Storage にアクセスするには、Private Service Connect エンドポイントの IP アドレスを指す DNS(A)レコード storage-psclab.p.googleapis.com を作成します。
DNS 限定公開ゾーンの作成
gcloud dns --project=$projectname managed-zones create psc-dns-zone --description="" --dns-name="p.googleapis.com." --visibility="private" --networks="psc-lab"
DNS A レコードを作成する
gcloud dns --project=$projectname record-sets transaction start --zone=psc-dns-zone gcloud dns --project=$projectname record-sets transaction add $pscendpointip --name=storage-pscendpoint.p.googleapis.com. --ttl=300 --type=A --zone=psc-dns-zone gcloud dns --project=$projectname record-sets transaction execute --zone=psc-dns-zone
11. 仮想マシンの作成
Private Service Connect の検証に使用する仮想マシン(psc-instance-1)を作成する
Cloud Shell から
gcloud compute instances create psc-instance-1 \ --subnet psclab-subnet \ --zone us-central1-a \ --image=centos-7-v20210122 \ --image-project=centos-cloud \ --no-address \ --metadata=startup-script=yum\ install\ tcpdump\ -y$'\n'yum\ install\ bind-utils\ -y$'\n'yum\ install\ nano\ -y
VM インスタンス(psc-instance-1)にログインします。
Cloud Shell を使用して VM に SSH 接続する
gcloud compute ssh --zone "us-central1-a" "psc-instance-1" --project "$projectname"
+(以下のスクリーンショット)を 3 回クリックして、追加の Cloud Shell ターミナルを作成します。
公開されている Google API の検証に使用する仮想マシン(psc-instance-2)を作成する
タブ 2 から
gcloud compute instances create psc-instance-2 \ --subnet psclab-subnet \ --zone us-central1-a \ --image=centos-7-v20210122 \ --image-project=centos-cloud \ --no-address \ --metadata=startup-script=yum\ install\ tcpdump\ -y$'\n'yum\ install\ bind-utils\ -y$'\n'yum\ install\ nano\ -y
タブ 2 から、Cloud Shell を介して VM に SSH 接続します。
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] projectname=YOUR-PROJECT-NAME echo $projectname gcloud compute ssh --zone "us-central1-a" "psc-instance-2" --project "$projectname"
タブ 3 から、Cloud Shell 経由で psc-instance-1 に SSH 接続
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] projectname=YOUR-PROJECT-NAME echo $projectname gcloud compute ssh --zone "us-central1-a" "psc-instance-1" --project "$projectname"
タブ 4 から、Cloud Shell を使用して psc-instance-2 に SSH で接続します。
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] projectname=YOUR-PROJECT-NAME echo $projectname gcloud compute ssh --zone "us-central1-a" "psc-instance-2" --project "$projectname"
12. 既存の gsutil の動作を確認する
タブ 4(psc-instance-2)から tcpdump を開始し、DNS トラフィックを監視します。
sudo tcpdump -vv -i eth0 port 53
タブ 2(psc-instance-2)からのストレージ バケットの DNS ルックアップを調査
BUCKET_NAME=YOUR BUCKET NAME echo $BUCKET_NAME gsutil -D ls gs://$BUCKET_NAME
gsutil のデバッグを調べる。HOST storage.googleapis.com は DNS の解決に使用されている。
<snip> send: 'GET /storage/v1/b/$BUCKET_NAME/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000 HTTP/1.1\r\nHost: storage.googleapis.com\r\ncontent-length: 0\r\nauthorization: Bearer ya29.c.KpkB7wfaMjfc_WXEKCeNF4Md0fEHnfDU7tqBf3cd0u43yEmYXqj8fX_X5wWdNdDVH6k1EkjeAeIJDzKGvyjPOkf1Io2kVeUqYX69sDv53huW1NslffjAHKchbZ0CP3Cg83TS3Pa55jLcuE0TLbYycVrgSbD3H90LaapUGbWD3kj4IsJLf9J8R98Bqobu8HZwwqk92hlZ4zVzRqOM\r\naccept-encoding: gzip, deflate\r\naccept: application/json\r\nuser-agent: apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0\r\n\r\n' reply: 'HTTP/1.1 200 OK\r\n' <snip>
タブ 4(psc-instance-2)から、ストレージ バケットへのアクセス時に GoogleAPI.com パブリック DNS A レコードが使用されていることを確認します。
metadata.google.internal.domain > psc-instance-2.c.yourprojectname.internal.33973: [udp sum ok] 36442 q: A? storage.googleapis.com. 11/0/0 storage.googleapis.com. A 108.177.111.128, storage.googleapis.com. A 142.250.128.128, storage.googleapis.com. A 74.125.70.128, storage.googleapis.com. A 74.125.201.128, storage.googleapis.com. A 64.233.183.128, storage.googleapis.com. A 173.194.198.128, storage.googleapis.com. A 172.217.219.128, storage.googleapis.com. A 142.250.136.128, storage.googleapis.com. A 209.85.234.128, storage.googleapis.com. A 172.217.212.128, storage.googleapis.com. A 172.217.214.128
13. gsutil の動作を変更する
前のステップで、PSC エンドポイントの IP アドレスにマッピングされた限定公開 DNS ゾーンと A レコードを作成したことを思い出してください。次のステップでは、psc-instance-1 の VM BOTO ファイルを更新して、gsutil の動作を制御します。
タブ 1(psc-instance-1)の VM インスタンス ターミナルで BOTO のデフォルト構成を表示する
[psc-instance ~]$ more /etc/boto.cfg
出力(project_id は異なります)
[GSUtil] default_project_id = 234086459238 default_api_version = 2 [GoogleCompute] service_account = default
nano エディタまたは VI エディタを使用して BOTO の構成を更新し、すべてのエントリをコピーして貼り付けます。
例: sudo nano /etc/boto.cfg
または
例: sudo vi /etc/boto.cfg
VM インスタンスのターミナルタブ 1(psc-instance-1)から
[Credentials] gs_host = storage-pscendpoint.p.googleapis.com gs_host_header = storage.googleapis.com gs_json_host = storage-pscendpoint.p.googleapis.com gs_json_host_header = www.googleapis.com
構成を検証する。DNS ルックアップには [認証情報] の順序が重要
more /etc/boto.cfg [Credentials] gs_host = storage-pscendpoint.p.googleapis.com gs_host_header = storage.googleapis.com gs_json_host = storage-pscendpoint.p.googleapis.com gs_json_host_header = www.googleapis.com [GSUtil] default_project_id = 234086459238 default_api_version = 2 [GoogleCompute] service_account = default
14. 更新された gsutil ルックアップ動作を確認する
タブ 3(psc-instance-1)から tcpdump を開始し、DNS トラフィックを監視します。
sudo tcpdump -vv -i eth0 port 53
タブ 1(psc-instance-1)でのストレージ バケット gsutil ルックアップの調査
BUCKET_NAME=YOUR BUCKET NAME echo $BUCKET_NAME gsutil -D ls gs://$BUCKET_NAME
デバッグログで、Private Service Connect エンドポイント「pscendpoint」を介してストレージ バケットに到達可能であることを確認する
出力:
<snip> INFO 0131 22:14:18.795986 base_api.py] Making http GET to https://storage-pscendpoint.p.googleapis.com/storage/v1/b/$BUCKET_NAME/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000 INFO 0131 22:14:18.796415 base_api.py] Headers: {u'Host': 'www.googleapis.com', 'accept': 'application/json', 'accept-encoding': 'gzip, deflate', 'content-length': '0', 'user-agent': 'apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0'} INFO 0131 22:14:18.796502 base_api.py] Body: (none) connect: (storage-pscendpoint.p.googleapis.com, 443) send: 'GET /storage/v1/b/psc-bucket/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000 HTTP/1.1\r\ncontent-length: 0\r\naccept-encoding: gzip, deflate\r\naccept: application/json\r\nuser-agent: apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0\r\nhost: www.googleapis.com\r\nauthorization: Bearer ya29.c.KpkB7wd3XWiYeRyTuth5_HPlNV-hPwc2Nn7RSIeMpzrpa_j4EsMPl2m_mDGKAcGHvYIgiC5bT2UVQirAPpSbbpToa6G6lkaBbH5SZwHwgNXYfisp5Ww1UjXe4rTa69a_Wp0WesafcwPNnYzDo3xf5VGh3iGhySA04kTXuyT--MgOU8U-XLII2LJQxUWlV8KEdrvyCuqRb-jsDdk_\r\n\r\n' reply: 'HTTP/1.1 200 OK\r\n' <snip>
タブ 3(psc-instance-1)で、PSC エンドポイント IP がストレージ バケットへのアクセス時に使用された DNS A レコードであることを確認します。
@psc-instance-1 ~]$ sudo tcpdump -vv -i eth0 port 53 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 05:02:33.936256 IP (tos 0x0, ttl 64, id 55416, offset 0, flags [DF], proto UDP (17), length 82) psc-instance-1.c.yourprojectname.internal.42296 > metadata.google.internal.domain: [bad udp cksum 0x5e4e -> 0xcceb!] 34796+ A? storage-pscendpoint.p.googleapis.com. (54) 05:02:33.936269 IP (tos 0x0, ttl 64, id 55417, offset 0, flags [DF], proto UDP (17), length 82) psc-instance-1.c.yourprojectname.internal.42296 > metadata.google.internal.domain: [bad udp cksum 0x5e4e -> 0x3ebd!] 5632+ AAAA? storage-pscendpoint.p.googleapis.com. (54) 05:02:33.944018 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 98) metadata.google.internal.domain > psc-instance-1.c.yourprojectname.42296: [udp sum ok] 34796 q: A? storage-pscendpoint.p.googleapis.com. 1/0/0 storage-pscendpoint.p.googleapis.com. A 10.10.110.10 (70) 05:02:33.946005 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 175)
Private Service Connect エンドポイント IP が DNS の解決に使用されるようになったことを確認する
tab1 から
nslookup storage-pscendpoint.p.googleapis.com
出力
@psc-instance ~]$ nslookup storage-pscendpoint.p.googleapis.com Server: 169.254.169.254 Address: 169.254.169.254#53 Non-authoritative answer: Name: storage-pscendpoint.p.googleapis.com Address: <pscip>
15. クリーンアップ手順
VM インスタンスを終了(すべてのタブ)
exit
単一の Cloud Shell ターミナルからラボのコンポーネントを削除する
gcloud compute routers nats delete cloudnat --router=crnat --region=us-central1 --quiet gcloud compute routers delete crnat --region=us-central1 --quiet gcloud beta compute forwarding-rules delete pscendpoint --global --quiet gcloud beta compute addresses delete psc-ip --global --quiet gsutil rm -r gs://$BUCKET_NAME gcloud compute instances delete psc-instance-1 --zone=us-central1-a --quiet gcloud compute instances delete psc-instance-2 --zone=us-central1-a --quiet gcloud compute firewall-rules delete psclab-ssh --quiet gcloud compute networks subnets delete psclab-subnet --region us-central1 --quiet gcloud compute networks delete psc-lab --quiet
コンソールで、正しいプロジェクトが表示されていることを確認し、[ネットワーキング サービス] → [Cloud DNS] を選択します。
特定と[psc-dns-zone] をクリックして
レコードセット「storage-pscendpoint.p.googleapis.com」を選択[Delete Record Sets] をクリックします。
[ゾーンを削除] をクリックしてラボのクリーンアップを完了する
16. 完了
以上で、この Codelab は完了です。
学習した内容
- Private Service Connect のユースケース
- ネットワークの要件
- サポートされている API
- Private Service Connect エンドポイントを作成しました
- Cloud Storage バケットを作成している
- Cloud DNS 限定公開ゾーンを作成している
- BOTO 構成ファイルを更新しました
- NAT GW の作成
- VM1 で PSC サービス エンドポイントに対して解決される gsutil list を実行する
- VM2 で gsutil list を実行し、公開中の googleapis.com に対して解決する
- tcpdump を使用して DNS の解決を検証する