1. はじめに
Private Service Connect を使用すると、サービス プロデューサーはサービス コンシューマに非公開でサービスを提供できます。Private Service Connect には次の利点があります。
- 1 つのサービス プロデューサー VPC ネットワークで複数のサービス コンシューマをサポートできます。
- 各コンシューマは、コンシューマが定義した内部 IP アドレスに接続します。Private Service Connect は、ネットワーク アドレス変換（NAT）を行い、リクエストをサービス プロデューサーに転送します。
図 2. Private Service Connect はエンドポイントとサービス アタッチメントを使用して、サービス コンシューマがコンシューマの VPC ネットワークからサービス プロデューサーの VPC ネットワーク内のサービスにトラフィックを送信できるようにします（クリックして拡大）。
学習内容
- Private Service Connect のメリット
- サービス コンシューマに関する主なコンセプト
- サービス プロデューサーの主なコンセプト
- プロデューサー環境を作成する
- サービス アタッチメントを介してサービス（プロデューサー環境）を公開する
- コンシューマ環境を作成する
- コンシューマ ネットワークに転送ルールを作成する
- TCP コンシューマ アクセスを検証する
- 有効化とプロキシ プロトコルの検証
- ポリシーのアクセス制御を有効にする
必要なもの
- 内部ロードバランサに関する知識
- 2 つのプロジェクトで VPC を作成可能
2. Private Service Connect のメリット
PSC には、VPC ピアリングを使用する場合と比べていくつかの利点があります。
プライベート IP 空間の制御の強化
- サービス ユーザーは、アクセスしたいマネージド サービスへの接続に使用するプライベート IP アドレスを制御できます。
- サービス ユーザーは、VPC で利用されるバックエンド サービス用にプライベート IP アドレス範囲を予約することについて心配する必要はありません。プロデューサー サービスに接続するには、ご自分のサブネットから IP アドレスを選択するだけです。
- サービス プロデューサーの場合、マルチテナント モデルのデプロイを選択できます。このモデルでは、複数のコンシューマ VPC にサービスを提供するサービスが VPC に含まれています。コンシューマのサブネット範囲が重複していても、問題が生じなくなりました。
- サービス プロバイダの場合、必要な数の VM インスタンスにサービスをスケーリングでき、追加の IP アドレスについてコンシューマに連絡しなくても済みます。
セキュリティと分離の向上
- サービス コンシューマの場合、サービス プロデューサーとの通信を開始できるのはご自身のみです。この一方向の接続により、ファイアウォールの構成が大幅に簡素化されるだけでなく、サービス プロデューサーからの大量のトラフィックによるリスクも軽減されます。
- サービス プロデューサーの場合、コンシューマの VPC のサブネット範囲に基づいてファイアウォール ルールを変更する必要がありません。サービス用に構成された NAT IP アドレスの範囲に合わせてファイアウォール ルールを作成するだけです。
スケーラビリティの向上
- PSC では、数千のコンシューマをサポートしてスケーラビリティに優れた設計を実現できます。また、サービス プロデューサーは、スケーラビリティに優れたマルチテナント サービスやシングル テナント サービスを提供できます。
- PSC を使用するサービス コンシューマは、VPC で必要に応じてリソースを作成できます。このスケーリングは、プロデューサー VPC で作成されたリソースの数に影響されません。
3. サービス コンシューマの主なコンセプト
Private Service Connect エンドポイントを使用すると、VPC ネットワークの外部にあるサービスを使用できます。サービス ユーザーは、ターゲット サービスに接続する Private Service Connect エンドポイントを作成します。
Endpoints
ターゲット サービスには、Private Service Connect エンドポイントを使用して接続します。エンドポイントには VPC ネットワーク内の内部 IP アドレスが 1 つ割り振られています。エンドポイントは転送ルールのリソースに基づいています。
エンドポイントに送信されたトラフィックは、VPC ネットワーク外のターゲットに転送されます。
目標
Private Service Connect エンドポイントにはターゲット（接続先のサービス）があります。
- API バンドル:
- すべての API: ほとんどの Google API
- VPC-SC: VPC Service Controls がサポートする API
- 別の VPC ネットワーク内の公開サービス。このサービスは組織やサードパーティによって管理されます。
公開サービス
エンドポイントをサービス プロデューサーのサービスに接続するには、サービスのサービス アタッチメントが必要です。サービス アタッチメント URI の形式は projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME です。
4. サービス プロデューサーの主なコンセプト
コンシューマがサービスを利用できるようにするには、コンシューマ IP アドレスのネットワーク アドレス変換（NAT）に使用する専用サブネットを 1 つ以上作成します。次に、これらのサブネットを参照するサービス アタッチメントを作成します。
Private Service Connect サブネット
サービスを公開するために、サービス プロデューサーはまず Private Service Connect 用の 1 つ以上のサブネットを作成します。
コンシューマの VPC ネットワークからリクエストが送信されると、コンシューマの送信元 IP アドレスが送信元 NAT（SNAT）を使用して Private Service Connect サブネットの 1 つから選択された IP アドレスに変換されます。
コンシューマの接続 IP アドレス情報を保持する場合は、コンシューマの接続情報の表示をご覧ください。
これらのサブネットは、VM インスタンスや転送ルールなどのリソースに使用できません。サブネットは、受信コンシューマ接続の SNAT に IP アドレスを提供する目的でのみ使用されます。
Private Service Connect サブネットには、63 個のコンシューマ VM ごとに少なくとも 1 つの IP アドレスが含まれている必要があります。これにより、各コンシューマ VM にネットワーク アドレス変換用の 1,024 個のソースタプルが割り当てられます。
Private Service Connect サブネットの最小サイズは /24 です。
サービス アタッチメント
サービス プロデューサーは、サービス アタッチメントを介してサービスを公開します。
- サービスを公開するために、サービス プロデューサーは、サービスのロードバランサ転送ルールを参照するサービス アタッチメントを作成します。
- サービス ユーザーは、サービスにアクセスするために、サービス アタッチメントを参照するエンドポイントを作成します。
接続の設定
サービスの作成時に、サービスの利用方法を選択します。次の 2 つの方法があります。
- すべてのプロジェクトの接続を自動的に受け入れる - すべてのサービス コンシューマは、エンドポイントを構成して、自動的にサービスに接続できます。
- 選択したプロジェクトの接続を受け入れる - サービス コンシューマがサービスに接続するようにエンドポイントを構成し、サービス プロデューサーが接続リクエストを承認または拒否します。
5. テスト環境
コンシューマ ネットワークは、サービス プロデューサーへのリクエストの発信に使用される TCP 静的 IP アドレスと、プロデューサーのサービス アタッチメント（公開サービス）にマッピングされる target-service-アタッチメントで構成されています。
次にプロデューサー ネットワークについて 見ていきましょうプロデューサー ネットワークにはコンシューマ ネットワークへのマッピングがなく、代わりにプロデューサー ネットワークにはコンシューマがサービスに使用するサービス アタッチメント（公開サービス）が含まれています。このラボで使用するプロデューサーのサービス アタッチメントは、TCP アプリケーションをサポートするバックエンド サービスにマッピングされたレイヤ 4 内部ロードバランサ（producer-forwarding-rule）です。
NAT サブネットと関連するファイアウォール ルールにより、プロデューサー アプリケーションとの通信が許可されています。
セルフペース型の環境設定
- Cloud コンソールにログインして、新しいプロジェクトを作成するか、既存のプロジェクトを再利用しますGmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。
プロジェクト ID を忘れないようにしてください。プロジェクト ID はすべての Google Cloud プロジェクトを通じて一意の名前にする必要があります（上記の名前はすでに使用されているので使用できません）。以降、このコードラボでは PROJECT_ID と呼びます。
- 次に、Google Cloud リソースを使用するために、Cloud Console で課金を有効にする必要があります。
このコードラボを実行しても、費用はほとんどかからないはずです。このチュートリアル以外で請求が発生しないように、リソースのシャットダウン方法を説明する「クリーンアップ」セクションの手順に従うようにしてください。Google Cloud の新規ユーザーは、$300 USD 分の無料トライアル プログラムをご利用いただけます。
Cloud Shell の起動
Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。
GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。
プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。
この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。
6. 始める前に
Codelab には 2 つのプロジェクトが必要ですが、PSC の要件ではありません。単一または複数のプロジェクトに対応するための参照にご注意ください。
単一プロジェクト - プロジェクトを更新してプロデューサー ネットワークとコンシューマ ネットワークをサポートする
Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] prodproject=YOUR-PROJECT-NAME consumerproject=YOUR-PROJECT-NAME echo $prodproject echo $consumerproject
複数のプロジェクト - プロデューサー ネットワークをサポートするようにプロジェクトを更新する
Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] prodproject=YOUR-PROJECT-NAME echo $prodproject
7. プロデューサー VPC ネットワークの作成
注: 次のセクションでは、プロデューサー サービスを含むプロジェクトで構成の更新を実行します。
VPC ネットワーク
Cloud Shell から
gcloud compute networks create vpc-demo-producer --project=$prodproject --subnet-mode=custom
サブネットの作成
Cloud Shell から
gcloud compute networks subnets create vpc-demo-us-west2 --project=$prodproject --range=10.0.2.0/24 --network=vpc-demo-producer --region=us-west2
Cloud NAT インスタンスを作成する
Cloud NAT は、PSC に使用される NAT とは異なります。Cloud NAT は、アプリケーション パッケージをダウンロードするためのインターネット アクセスに明示的に使用されます。
Cloud Router の作成
Cloud Shell から
gcloud compute routers create crnatprod --network vpc-demo-producer --region us-west2
Cloud NAT を作成する
Cloud Shell から
gcloud compute routers nats create cloudnatprod --router=crnatprod --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --enable-logging --region us-west2
8. コンピューティング インスタンスを作成する
Cloud Shell からインスタンス www-01 を作成します。
gcloud compute instances create www-01 \
--zone=us-west2-a \
--image-family=debian-9 \
--image-project=debian-cloud \
--subnet=vpc-demo-us-west2 --no-address \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install tcpdump -y
apt-get install apache2 -y
a2ensite default-ssl
apt-get install iperf3 -y
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
filter="{print \$NF}"
vm_zone="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/zone \
| awk -F/ "${filter}")"
echo "Page on $vm_hostname in $vm_zone" | \
tee /var/www/html/index.html
systemctl restart apache2
iperf3 -s -p 5050'
Cloud Shell からインスタンス www-02 を作成します。
gcloud compute instances create www-02 \
--zone=us-west2-a \
--image-family=debian-9 \
--image-project=debian-cloud \
--subnet=vpc-demo-us-west2 --no-address \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install tcpdump -y
apt-get install apache2 -y
a2ensite default-ssl
apt-get install iperf3 -y
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
filter="{print \$NF}"
vm_zone="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/zone \
| awk -F/ "${filter}")"
echo "Page on $vm_hostname in $vm_zone" | \
tee /var/www/html/index.html
systemctl restart apache2
iperf3 -s -p 5050'
9. 非マネージド インスタンス グループを作成する
www-01 とwww-02
Cloud Shell から
gcloud compute instance-groups unmanaged create vpc-demo-ig-www --zone=us-west2-a gcloud compute instance-groups unmanaged add-instances vpc-demo-ig-www --zone=us-west2-a --instances=www-01,www-02 gcloud compute health-checks create http hc-http-80 --port=80
10. TCP バックエンド サービス、転送ルール、ファイアウォール
Cloud Shell でバックエンド サービスを作成する
gcloud compute backend-services create vpc-demo-www-be-tcp --load-balancing-scheme=internal --protocol=tcp --region=us-west2 --health-checks=hc-http-80 gcloud compute backend-services add-backend vpc-demo-www-be-tcp --region=us-west2 --instance-group=vpc-demo-ig-www --instance-group-zone=us-west2-a
Cloud Shell で転送ルールを作成する
gcloud compute forwarding-rules create vpc-demo-www-ilb-tcp --region=us-west2 --load-balancing-scheme=internal --network=vpc-demo-producer --subnet=vpc-demo-us-west2 --address=10.0.2.10 --ip-protocol=TCP --ports=all --backend-service=vpc-demo-www-be-tcp --backend-service-region=us-west2
Cloud Shell で、バックエンド ヘルスチェックを有効にするファイアウォール ルールを作成する
gcloud compute firewall-rules create vpc-demo-health-checks --allow tcp:80,tcp:443 --network vpc-demo-producer --source-ranges 130.211.0.0/22,35.191.0.0/16 --enable-logging
IAP に VM インスタンスへの接続を許可するには、次のファイアウォール ルールを作成します。
- IAP を使用してアクセスできるようにするすべての VM インスタンスに適用します。
- IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可する。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。
Cloud Shell から
gcloud compute firewall-rules create psclab-iap-prod --network vpc-demo-producer --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging
11. TCP NAT サブネットを作成する
Cloud Shell から
gcloud compute networks subnets create vpc-demo-us-west2-psc-tcp --network=vpc-demo-producer --region=us-west2 --range=192.168.0.0/24 --purpose=private-service-connect
12. TCP サービス アタッチメントとファイアウォール ルールを作成する
Cloud Shell で TCP サービス アタッチメントを作成する
gcloud compute service-attachments create vpc-demo-psc-west2-tcp --region=us-west2 --producer-forwarding-rule=vpc-demo-www-ilb-tcp --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=vpc-demo-us-west2-psc-tcp
TCP サービス アタッチメントを検証する
gcloud compute service-attachments describe vpc-demo-psc-west2-tcp --region us-west2
Cloud Shell で、ILB バックエンドへの TCP NAT サブネットのアクセスを許可するファイアウォール ルールを作成する
gcloud compute --project=$prodproject firewall-rules create vpc-demo-allowpsc-tcp --direction=INGRESS --priority=1000 --network=vpc-demo-producer --action=ALLOW --rules=all --source-ranges=192.168.0.0/24 --enable-logging
13. コンシューマ VPC ネットワークの作成
注: 次のセクションでは、コンシューマ サービスを含むプロジェクトで構成の更新を実行します。
次のセクションでは、コンシューマ VPC を別のプロジェクトで構成します。コンシューマ ネットワークとプロデューサー ネットワーク間の通信は、コンシューマ ネットワークで定義されているサービス アタッチメントを介して行われます。
VPC ネットワーク
Codelab には 2 つのプロジェクトが必要ですが、PSC の要件ではありません。単一または複数のプロジェクトに対応するための参照にご注意ください。
単一プロジェクト - プロジェクトを更新してプロデューサー ネットワークとコンシューマ ネットワークをサポートする
Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] consumerproject=YOUR-PROJECT-NAME prodproject=YOUR-PROJECT-NAME echo $prodproject echo $consumerproject
複数のプロジェクト - コンシューマ ネットワークをサポートするようにプロジェクトを更新する
Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] consumerproject=YOUR-PROJECT-NAME echo $consumerproject
Cloud Shell から
gcloud compute networks create vpc-demo-consumer --project=$consumerproject --subnet-mode=custom
PSC 用サブネットの作成
Cloud Shell から
gcloud compute networks subnets create consumer-subnet --project=$consumerproject --range=10.0.60.0/24 --network=vpc-demo-consumer --region=us-west2
TCP アプリケーション用の静的 IP アドレスを作成する
Cloud Shell から
gcloud compute addresses create vpc-consumer-psc-tcp --region=us-west2 --subnet=consumer-subnet --addresses 10.0.60.100
ファイアウォール ルールを作成する
IAP に VM インスタンスへの接続を許可するには、次のファイアウォール ルールを作成します。
- IAP を使用してアクセスできるようにするすべての VM インスタンスに適用します。
- IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可する。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。
Cloud Shell から
gcloud compute firewall-rules create psclab-iap-consumer --network vpc-demo-consumer --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging
PSC では必須ではありませんが、プロデューサー サービス アタッチメントへのコンシューマ PSC トラフィックをモニタリングする下り（外向き）ファイアウォール ルールを作成します。
gcloud compute --project=$consumerproject firewall-rules create vpc-consumer-psc --direction=EGRESS --priority=1000 --network=vpc-demo-consumer --action=ALLOW --rules=all --destination-ranges=10.0.60.0/24 --enable-logging
Cloud NAT インスタンスを作成する
Cloud NAT は、PSC に使用される NAT とは異なります。Cloud NAT は、アプリケーション パッケージをダウンロードするためのインターネット アクセスに明示的に使用されている
Cloud Router の作成
Cloud Shell から
gcloud compute routers create crnatconsumer --network vpc-demo-consumer --region us-west2
Cloud NAT を作成する
Cloud Shell から
gcloud compute routers nats create cloudnatconsumer --router=crnatconsumer --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --enable-logging --region us-west2
14. テスト インスタンス VM を作成
Cloud Shell から
gcloud compute instances create test-instance-1 \
--zone=us-west2-a \
--image-family=debian-9 \
--image-project=debian-cloud \
--subnet=consumer-subnet --no-address \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install iperf3 -y
apt-get install tcpdump -y'
15. TCP サービス アタッチメントを作成する
Cloud Shell から
gcloud compute forwarding-rules create vpc-consumer-psc-fr-tcp --region=us-west2 --network=vpc-demo-consumer --address=vpc-consumer-psc-tcp --target-service-attachment=projects/$prodproject/regions/us-west2/serviceAttachments/vpc-demo-psc-west2-tcp
16. 確認事項
CURL、TCPDUMP、ファイアウォール ログを使用して、コンシューマとプロデューサーの通信を検証します。
コンシューマのプロジェクト内では、静的 IP アドレスを使用してプロデューサーとの通信を開始します。この静的 IP アドレスとコンシューマ転送ルールのマッピングは、次の構文を実行して検証します。
注: 次のセクションでは、コンシューマ サービスを含むプロジェクトで構成の更新を実行します。
コンシューマ VPC の Cloud Shell で TCP 転送ルールと静的 IP を特定する
gcloud compute forwarding-rules describe vpc-consumer-psc-fr-tcp --region us-west2
出力:
IPAddress: 10.0.60.100 IPProtocol: TCP creationTimestamp: '2021-07-14T13:34:23.359-07:00' id: '2768158450402915488' kind: compute#forwardingRule labelFingerprint: 42WmSpB8rSM= name: vpc-consumer-psc-fr-tcp <snip>
17. TCP 検証
注: 次のセクションでは、プロデューサー サービスを含むプロジェクトで構成の更新を実行します。
Producer Project から、「www-01」を特定します。&「www-02」インスタンスごとに 1 つの SSH セッションを起動します。
「www-01」からTCPDUMP を実行して NAT を監視
sudo tcpdump -i any net 192.168.0.0/16 -n
「www-02」からTCPDUMP を実行して NAT を監視
sudo tcpdump -i any net 192.168.0.0/16 -n
注: 次のセクションでは、コンシューマ サービスを含むプロジェクトで構成の更新を実行します。
コンシューマ プロジェクトから、「test-instance-1」を特定します。2 つのセッションを開始します
「test-instance-1」からTCPDUMP を実行してコンシューマを
sudo tcpdump -i any host 10.0.60.100 -n
「test-instance-1」からセッション 2 が TCP 検証と
curl -v 10.0.60.100
18. 調査結果 - 消費者
「test-instance-1」からセッション 2 の CURL が成功し、200 OK が返されます。
@test-instance-1:~$ curl -v 10.0.60.100 * Rebuilt URL to: 10.0.60.100/ * Trying 10.0.60.100... * TCP_NODELAY set * Connected to 10.0.60.100 (10.0.60.100) port 80 (#0) > GET / HTTP/1.1 > Host: 10.0.60.100 > User-Agent: curl/7.52.1 > Accept: */* > < HTTP/1.1 200 OK < Date: Wed, 14 Jul 2021 21:20:22 GMT < Server: Apache/2.4.25 (Debian) < Last-Modified: Wed, 14 Jul 2021 20:09:09 GMT < ETag: "1d-5c71aed5edabd" < Accept-Ranges: bytes < Content-Length: 29 < Content-Type: text/html < Page on www-01 in us-west2-a * Curl_http_done: called premature == 0 * Connection #0 to host 10.0.60.100 left intact
「test-instance-1」からTCPDUMP で VM インスタンスを識別 → TCP 静的 IP の通信と応答
21:20:22.572052 IP 10.0.60.2.59432 > 10.0.60.100.80: Flags [P.], seq 1:76, ack 1, win 222, options [nop,nop,TS val 634554 ecr 998739], length 75: HTTP: GET / HTTP/1.1 21:20:22.572688 IP 10.0.60.100.80 > 10.0.60.2.59432: Flags [P.], seq 1:257, ack 76, win 220, options [nop,nop,TS val 998739 ecr 634554], length 256: HTTP: HTTP/1.1 200 OK
ファイアウォールのロギング
ログ エクスプローラを使用してファイアウォール ルール「vpc-consumner-psc」を検証するVM インスタンスと静的 IP の間のフローをキャプチャし、
- Cloud コンソールから、[オペレーション ロギングの特定] → [ログ エクスプローラ] に移動します。
- [クエリ] フィールドで、consumerproject を使用して以下のエントリを更新し、[クエリを実行] を選択します。
logName:(projects/yourconsumerproject/logs/compute.googleapis.com%2Ffirewall) AND jsonPayload.rule_details.reference:("network:vpc-demo-consumer/firewall:vpc-consumer-psc")
- 提供されたスクリーンショットに従って、クエリ結果は次のようになります。
- ログを開き、以下の出力を確認します。dest_ip に注目してください。10.0.60.100 は STATIC TCP IP で、src_ip: 10.0.60.2 は VM インスタンスの IP アドレスです。
19. 所見 - プロデューサー
バックエンド インスタンス「www-01」から「www-02」TCP NAT サブネットと TCP ILB 間の次の通信が観測されます。
21:20:22.572186 IP 192.168.0.2.1024 > 10.0.2.10.80: Flags [P.], seq 1:76, ack 1, win 222, options [nop,nop,TS val 634554 ecr 998739], length 75: HTTP: GET / HTTP/1.1 21:20:22.572679 IP 10.0.2.10.80 > 192.168.0.2.1024: Flags [P.], seq 1:257, ack 76, win 220, options [nop,nop,TS val 998739 ecr 634554], length 256: HTTP: HTTP/1.1 200 OK
20. ファイアウォールのロギング
ログ エクスプローラを使用してファイアウォール ルール「vpc-demo-allowpsc-tcp」を検証するTCP NAT とTCP ILB フロー:
- Cloud コンソールから、[オペレーション ロギングの特定] → [ログ エクスプローラ] に移動します。
- [クエリ] フィールドで、以下のエントリを「yourprodproject」に変更し、[クエリを実行] を選択します。
logName:(projects/yourprodproject/logs/compute.googleapis.com%2Ffirewall) AND jsonPayload.rule_details.reference:("network:vpc-demo-producer/firewall:vpc-demo-allowpsc-tcp")
- 提供されたスクリーンショットに従って、クエリ結果は次のようになります。
- ログを開き、以下の出力を確認します。TCP ILB dest_ip: 10.0.2.10 および NAT TCP source_range (192.168.0.0/24) &それぞれ src_ip: 192.168.0.2 です。
21. プロキシ プロトコルを有効にする
デフォルトでは、Private Service Connect はコンシューマの送信元 IP アドレスをサービス プロデューサーの VPC ネットワーク内の Private Service Connect サブネットのいずれかのアドレスに変換します。代わりにコンシューマの元の送信元 IP アドレスを表示するには、PROXY プロトコルを有効にします。PROXY プロトコルが有効になっている場合、コンシューマの送信元 IP アドレスと PSC 接続 ID は PROXY プロトコル ヘッダーから取得できます。
プロデューサー公開サービスを削除する
注: 次のセクションでは、プロデューサー サービスを含むプロジェクトで構成の更新を実行します。
Cloud Shell から TCP サービス アタッチメントを削除する
gcloud compute service-attachments delete vpc-demo-psc-west2-tcp --region=us-west2 --quiet
Cloud Shell から、サービス アタッチメントが削除されたことを確認（リストされているアイテム: 0）
gcloud compute service-attachments list
プロキシ プロトコルを有効にした TCP サービス アタッチメントを作成する
gcloud compute service-attachments create vpc-demo-psc-west2-tcp --region=us-west2 \ --producer-forwarding-rule=vpc-demo-www-ilb-tcp \ --connection-preference=ACCEPT_AUTOMATIC \ --nat-subnets=vpc-demo-us-west2-psc-tcp \ --enable-proxy-protocol
Cloud Shell から、プロキシ プロトコルが有効（true）でサービス アタッチメントが作成されていることを検証する
gcloud compute service-attachments describe vpc-demo-psc-west2-tcp --region=us-west2 | grep -i enableProxyProtocol:
注: 次のセクションでは、コンシューマ サービスを含むプロジェクトで構成の更新を実行します。
Cloud Shell から TCP 転送ルールを削除する
gcloud compute forwarding-rules delete vpc-consumer-psc-fr-tcp --region=us-west2 --quiet
以前に作成した（プロデューサー）サービス アタッチメントに関連付ける TCP 転送ルールを再作成する
Cloud Shell で TCP 転送ルールを作成する
gcloud compute forwarding-rules create vpc-consumer-psc-fr-tcp \ --region=us-west2 --network=vpc-demo-consumer \ --address=vpc-consumer-psc-tcp \ --target-service-attachment=projects/$prodproject/regions/us-west2/serviceAttachments/vpc-demo-psc-west2-tcp
プロキシ プロトコルの検証
注: 次のセクションでは、プロデューサー サービスを含むプロジェクトで構成の更新を実行します。
Producer Project から、「www-01」を特定します。&「www-02」インスタンスごとに 1 つのセッションを起動します。
「www-01」からTCPDUMP を実行して NAT を監視
sudo tcpdump -nnvvXSs 1514 net 192.168.0.0/16
「www-02」からTCPDUMP を実行して NAT を監視
sudo tcpdump -nnvvXSs 1514 net 192.168.0.0/16
注: 次のセクションでは、コンシューマ サービスを含むプロジェクトで構成の更新を実行します。
コンシューマ プロジェクトから、「test-instance-1」を特定します。単一のセッションを開始する
「test-instance-1」からcurl を実行し、
curl 10.0.60.100
調査結果 - 消費者
PROXY Protocol v2 が有効になっていても、PROXY Protocol v2 をサポートするようにアプリケーションが構成されていない場合、以下の例のようにクライアントから接続するとエラー メッセージが表示されます。追加のプロキシ v2 ヘッダーに対応するために Apache の更新が必要この Codelab では扱いません。
「test-instance-1」からバックエンド クエリは成功しますが、セッション CURL では想定どおりの 400 件の不正なリクエストが生成されます。
@test-instance-1:~$ curl 10.0.60.100 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> </head><body> <h1>Bad Request</h1> <p>Your browser sent a request that this server could not understand.<br /> </p> <hr> <address>Apache/2.4.25 (Debian) Server at www-02.c.deepakmichaelprod.internal Port 80</address>
調査結果 - 消費者
バックエンド インスタンス「www-01」から「www-02」キャプチャにプロキシ プロトコルが埋め込まれた状態で、TCP NAT サブネットと TCP ILB 間の次のような通信が確認されています。
ほとんどの場合、tcpdump の 3 番目のパケットには、関連するプロキシ プロトコル情報要素（IE）が含まれています。必要に応じて、プロキシ プロトコル IE を含む 39 バイトのパケットを識別します。
192.168.0.3.1025 > 10.0.2.10.80: Flags [P.], cksum 0xb617 (correct), seq 2729454396:2729454435, ack 1311105819, win 28160, length 39: HTTP
0x0000: 4500 004f 0000 4000 4006 6df4 c0a8 0003 E..O..@.@.m.....
0x0010: 0a00 020a 0401 0050 a2b0 2b3c 4e25 e31b .......P..+<N%..
0x0020: 5018 6e00 b617 0000 0d0a 0d0a 000d 0a51 P.n............Q
0x0030: 5549 540a 2111 0017 0a00 3c02 0a00 3c64 UIT.!.....<...<d
0x0040: 8138 0050 e000 0800 9b34 d70a 003c 64 .8.P.....4...<d
PROXY プロトコル署名を特定する: パケット キャプチャで 0d0a0d0a000d0a515549540a
PROXY プロトコル署名を識別すると、次のようにフィールドを分解してデコードできます。
PROXY プロトコル署名: 0d0a0d0a000d0a515549540a
その他の PROXY プロトコル フィールド: 21 11 00 17
IP とポート: 0a003c02 0a003c64 8138 0050
TLV タイプ: e0
TLV 長さ: 00 08
pscConnection ID: 009b34d70a003c64
16 進数 | 10 進数 / IP | ||
PROXY プロトコル署名 |
| ||
バージョン、プロトコル、長さ |
| ||
ソース IP |
|
| |
宛先 IP |
|
| |
送信元ポート |
|
| |
宛先ポート |
|
| |
TLV Type（PP2_TYPE_GCP） |
| ||
TLV の長さ |
| ||
pscConnectionId |
|
| |
pscConnectionId は、次のようにコンシューマ転送ルールを記述し、一致していることを確認して検証することもできます。
注: 次のセクションでは、コンシューマ サービスを含むプロジェクトで構成の更新を実行します。
Cloud Shell から TCP 転送ルールの説明を取得する
gcloud compute forwarding-rules describe vpc-consumer-psc-fr-tcp --region=us-west2
pscConnectionID を説明する出力
$ gcloud compute forwarding-rules describe vpc-consumer-psc-fr-tcp --region=us-west2 IPAddress: 10.0.60.100 IPProtocol: TCP creationTimestamp: '2021-07-14T16:50:31.766-07:00' id: '4443494505307621032' kind: compute#forwardingRule labelFingerprint: 42WmSpB8rSM= name: vpc-consumer-psc-fr-tcp network: https://www.googleapis.com/compute/v1/projects/deepakmichaeldev/global/networks/vpc-demo-consumer networkTier: PREMIUM pscConnectionId: '43686719580552292' pscConnectionStatus: ACCEPTED
22. 接続ポリシー
公開サービスでは、プロジェクトの自動承認と明示的な承認を切り替えることができます。
自動承認から明示的な承認に変更しても、この変更前にサービスに接続していたコンシューマ エンドポイントには影響しません。既存のコンシューマ エンドポイントは、サービス アタッチメントが削除されるまで、公開サービスに接続できます。新しいコンシューマ エンドポイントがサービスに接続するには、事前に承認が必要です。詳細については、公開サービスへのアクセス リクエストの管理をご覧ください。
このセクションでは、プロデューサーの接続ポリシーを変更して、コンシューマのサービス アタッチメントを明示的に承認します。
注: 次のセクションでは、プロデューサー サービスを含むプロジェクトで構成の更新を実行します。
プロデューサー サービスの Cloud Shell で、接続設定ポリシーを自動承認から手動で承認に更新します。
gcloud compute service-attachments update vpc-demo-psc-west2-tcp --region=us-west2 --connection-preference ACCEPT_MANUAL
エンドポイントのステータスを確認するには、[ネットワーク サービス] → [Private Service Connect] → [公開サービス] → [vpc-demo-psc-west2-tcp] → [接続されたプロジェクト] に移動します。
コンシューマ プロジェクトが「保留中」に変更されましたステータスが表示されます。
Cloud Shell で次のコマンドを実行して、コンシューマ プロジェクトを受け入れ、適切なプロジェクト名で更新していることを確認します。
gcloud compute service-attachments update vpc-demo-psc-west2-tcp --region=us-west2 --consumer-accept-list $consumerproject=20
エンドポイントのステータスを確認するには、[ネットワーク サービス] → [Private Service Connect] → [公開サービス] → [vpc-demo-psc-west2-tcp] → [接続されたプロジェクト] に移動します。
コンシューマ プロジェクトが「Accepted」に変更されたことを通知ステータスが表示されます。
23. クリーンアップ手順
プロデューサー ネットワークのクリーンアップ手順
注: 次のセクションでは、プロデューサー サービスを含むプロジェクトで構成の更新を実行します。
Producer Project ターミナルの単一の Cloud Shell から、ラボのコンポーネントを削除する
gcloud compute routers nats delete cloudnatprod --router=crnatprod --region=us-west2 --quiet gcloud compute routers delete crnatprod --region=us-west2 --quiet gcloud compute instances delete www-01 --zone=us-west2-a --quiet gcloud compute instances delete www-02 --zone=us-west2-a --quiet gcloud compute service-attachments delete vpc-demo-psc-west2-tcp --region=us-west2 --quiet gcloud compute forwarding-rules delete vpc-demo-www-ilb-tcp --region=us-west2 --quiet gcloud compute backend-services delete vpc-demo-www-be-tcp --region=us-west2 --quiet gcloud compute instance-groups unmanaged delete vpc-demo-ig-www --zone=us-west2-a --quiet gcloud compute health-checks delete hc-http-80 --quiet gcloud compute firewall-rules delete vpc-demo-allowpsc-tcp --quiet gcloud compute firewall-rules delete vpc-demo-health-checks --quiet gcloud compute firewall-rules delete psclab-iap-prod --quiet gcloud compute networks subnets delete vpc-demo-us-west2 --region=us-west2 --quiet gcloud compute networks subnets delete vpc-demo-us-west2-psc-tcp --region=us-west2 --quiet gcloud compute networks delete vpc-demo-producer --quiet
注: 次のセクションでは、コンシューマ サービスを含むプロジェクトで構成の更新を実行します。
コンシューマー ネットワークのクリーンアップ手順
Producer Project ターミナルの単一の Cloud Shell から、ラボのコンポーネントを削除する
gcloud compute routers nats delete cloudnatconsumer --router=crnatconsumer --region=us-west2 --quiet gcloud compute routers delete crnatconsumer --region=us-west2 --quiet gcloud compute instances delete test-instance-1 --zone=us-west2-a --quiet gcloud compute forwarding-rules delete vpc-consumer-psc-fr-tcp --region=us-west2 --quiet gcloud compute addresses delete vpc-consumer-psc-tcp --region=us-west2 --quiet gcloud compute firewall-rules delete psclab-iap-consumer --quiet gcloud compute networks subnets delete consumer-subnet --region=us-west2 --quiet gcloud compute firewall-rules delete vpc-consumer-psc --quiet gcloud compute networks delete vpc-demo-consumer --quiet
24. 完了
以上で、この Codelab は完了です。
学習した内容
- Private Service Connect のメリット
- サービス コンシューマに関する主なコンセプト
- サービス プロデューサーの主なコンセプト
- プロデューサー環境を作成する
- サービス アタッチメントを介してサービス（プロデューサー環境）を公開する
- コンシューマ環境を作成する
- コンシューマ ネットワークに転送ルールを作成する
- TCP コンシューマ アクセスを検証する
- 有効化とプロキシ プロトコルの検証
- ポリシーのアクセス制御を有効にする