このページは Cloud Translation API によって翻訳されました。

Private Service Connect とハイブリッド NEG TCP プロキシを使用して、ハイブリッドネットワーク経由でオンプレミスサービスに接続する

1. はじめに

ハイブリッド接続で内部リージョン TCP プロキシロードバランサを使用すると、VPC ネットワーク内のクライアントがオンプレミス環境または他のクラウド環境でホストされているサービスを使用できるようになります。

ハイブリッドサービスを他の VPC ネットワークで利用できるようにするには、Private Service Connect を使用してサービスを公開します。サービスアタッチメントを内部リージョン TCP プロキシロードバランサの前に配置することで、他の VPC ネットワーク内のクライアントが、オンプレミスまたは他のクラウド環境で実行されているハイブリッドサービスにアクセスできるようになります。

作成するアプリの概要

この Codelab では、ネットワークエンドポイントグループを使用して、オンプレミスサービスへのハイブリッド接続が可能な内部 TCP プロキシロードバランサを構築します。コンシューマ VPC からオンプレミスサービスと通信できるようになります。

学習内容

ハイブリッド NEG バックエンドサービスを使用して TCP プロキシ ILB を作成する方法
Private Service Connect プロデューサー（サービスアタッチメント）とコンシューマ（転送ルール）を確立する方法
コンシューマからプロデューサーへのサービス通信をテストして検証する方法

必要なもの

確立済みのハイブリッドネットワーキング（HA VPN、相互接続、SW-WAN など）
Google Cloud プロジェクト

ハイブリッド接続を確立する

Google Cloud とオンプレミスまたは他のクラウド環境は、Cloud Router とともに Cloud Interconnect VLAN アタッチメントまたは Cloud VPN トンネルを使用して、ハイブリッド接続で接続する必要があります。高可用性接続の使用をおすすめします。

グローバル動的ルーティングが有効になっている Cloud Router は、BGP を介して特定のエンドポイントを学習し、Google Cloud VPC ネットワークにプログラムします。リージョン動的ルーティングはサポートされていません。静的ルートもサポートされていません。

Cloud Interconnect または Cloud VPN の構成に使用する Google Cloud VPC ネットワークは、ハイブリッドロードバランシングのデプロイに使用するネットワークと同じです。VPC ネットワークのサブネットの CIDR 範囲がリモートの CIDR 範囲と競合しないようにしてください。IP アドレスが重複する場合、リモート接続よりもサブネットルートが優先されます。

手順については、次をご覧ください。

カスタムルートアドバタイズ

以下のサブネットでは、Cloud Router からオンプレミスネットワークへのカスタムアドバタイズが必要です。これにより、オンプレミスのファイアウォールルールが更新されます。

サブネット	説明
172.16.0.0/23	オンプレミスサービスと直接通信するために使用される TCP プロキシサブネット
130.211.0.0/22、35.191.0.0/16	Google Cloud ヘルスチェック

2. 始める前に

Codelab をサポートするようにプロジェクトを更新する

この Codelab では、Cloud Shell での gcloud 構成の実装に役立つ $variables を使用します。

Cloud Shell 内で、次のコマンドを実行します。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. プロデューサーの設定

プロデューサー VPC を作成する

Cloud Shell 内で、次のコマンドを実行します。

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

プロデューサーサブネットを作成する

Cloud Shell 内で、次のコマンドを実行します。

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1

TCP プロキシサブネットを作成する

プロキシの割り当ては、ロードバランサレベルではなく VPC レベルで行われます。Envoy ベースのロードバランサを使用する仮想ネットワーク（VPC）の各リージョンにプロキシ専用サブネットを 1 つ作成する必要があります。同じリージョンおよび同じ VPC ネットワーク内に複数のロードバランサをデプロイすると、ロードバランシング用に同じプロキシ専用サブネットが共有されます。

クライアントは、ロードバランサの転送ルールの IP アドレスとポートに接続します。
各プロキシは、対応するロードバランサの転送ルールで指定された IP アドレスとポートをリッスンします。いずれかのプロキシがクライアントのネットワーク接続を受信して終了します。
プロキシは、NEG 内の適切なバックエンド VM またはエンドポイントへの接続を確立します。これは、ロードバランサの URL マップとバックエンドサービスによって決まります。

ネットワークが自動モードかカスタムモードかにかかわらず、プロキシ専用サブネットを作成する必要があります。プロキシ専用サブネットでは 64 個以上の IP アドレスを指定する必要があります。これは、/26 以下のプレフィックス長に対応します。推奨されるサブネットサイズは /23（512 個のプロキシ専用アドレス）です。

Cloud Shell 内で、次のコマンドを実行します。

gcloud compute networks subnets create proxy-subnet-us-central \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-central1 \
  --network=producer-vpc \
  --range=172.16.0.0/23

Private Service Connect NAT サブネットを作成する

Private Service Connect で使用する専用サブネットを 1 つ以上作成します。Google Cloud コンソールを使用してサービスを公開する場合、その手順でサブネットを作成できます。サービスのロードバランサと同じリージョンにサブネットを作成します。通常のサブネットを Private Service Connect のサブネットに変換することはできません。

Cloud Shell 内で、次のコマンドを実行します。

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

プロデューサーのファイアウォールルールを作成する

Private Service Connect エンドポイントとサービスアタッチメント間のトラフィックを許可するようにファイアウォールルールを構成します。この Codelab では、NAT サブネット 100.100.10.0/24 に Private Service Connect サービスアタッチメント（内部ロードバランサ）へのアクセスを許可する上り（内向き）ファイアウォールルールを作成しました。

Cloud Shell 内で、次のコマンドを実行します。

gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24

Cloud Shell 内で、Google Cloud ヘルスチェックが TCP ポート 80 でオンプレミスサービス（バックエンドサービス）に到達することを許可する fw-allow-health-check ルールを作成する

gcloud compute firewall-rules create fw-allow-health-check \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:80

オンプレミスサービスがポート 80 でプロキシサブネットと通信することを許可する上り（内向き）ファイアウォールルールを作成する

gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=172.16.0.0/23 \
    --rules=tcp:80

ハイブリッド接続 NEG を設定する

NEG を作成するときは、Google Cloud とオンプレミスまたは他のクラウド環境との間の地理的距離を最小限に抑えるゾーンを使用します。たとえば、ドイツのフランクフルトのオンプレミス環境にサービスをホストする場合、NEG の作成時に europe-west3-a Google Cloud ゾーンを指定できます。

また、Cloud Interconnect を使用している場合、NEG の作成に使用するゾーンは、Cloud Interconnect アタッチメントが構成されているリージョンと同じにする必要があります。

使用可能なリージョンとゾーンについては、Compute Engine ドキュメントの: 使用可能なリージョンとゾーンをご覧ください。

Cloud Shell 内で gcloud compute network-endpoint-groups create コマンドを使用して、ハイブリッド接続 NEG を作成する

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

Cloud Shell 内で、オンプレミスの IP:Port エンドポイントをハイブリッド NEG に追加します。

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

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

次の手順では、ロードバランサ（転送ルール）を構成し、ネットワークエンドポイントグループに関連付けることができます。

Cloud Shell 内で、オンプレミスサービスに渡すリージョンヘルスチェックを作成する

gcloud compute health-checks create tcp on-prem-service-hc \
    --region=us-central1 \
    --use-serving-port

Cloud Shell でオンプレミスバックエンド用のバックエンドサービスを作成する

gcloud compute backend-services create on-premise-service-backend \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --protocol=TCP \
   --region=us-central1 \
   --health-checks=on-prem-service-hc \
   --health-checks-region=us-central1

Cloud Shell 内で、ハイブリッド NEG バックエンドをバックエンドサービスに追加します。MAX_CONNECTIONS には、バックエンドで処理する最大同時接続数を入力します。

gcloud compute backend-services add-backend on-premise-service-backend \
   --network-endpoint-group=on-prem-service-neg \
   --network-endpoint-group-zone=us-central1-a \
   --region=us-central1 \
   --balancing-mode=CONNECTION \
   --max-connections=100

Cloud Shell 内でターゲットプロキシを作成する

gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
   --backend-service=on-premise-service-backend \
   --region=us-central1

Cloud Shell 内で転送ルール（ILB）を作成する

gcloud compute forwarding-rules create コマンドを使用して、転送ルールを作成します。

FWD_RULE_PORT は、1 ～ 65535 の単一のポート番号に置き換えます。転送ルールは、宛先ポートが一致するパケットのみを転送します。

gcloud compute forwarding-rules create tcp-ilb-psc \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --network=producer-vpc \
   --subnet=subnet-201 \
   --ports=80 \
   --region=us-central1 \
   --target-tcp-proxy=on-premise-svc-tcpproxy \
   --target-tcp-proxy-region=us-central1

内部ロードバランサの IP アドレスを取得する

gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:

Example output:
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
IPAddress: 10.10.1.2

4. ロードバランサを検証する

Cloud コンソールで、[ネットワークサービス] → [ロードバランシング] → [ロードバランサ] に移動します。1 つの NEG は「緑色」で、オンプレミスサービスへのヘルスチェックが成功したことを示します。

‘on-premise-service-backend'を選択すると、フロントエンドの IP アドレスが生成されます。

5. オンプレミスから学習したルートを表示する

[VPC ネットワーク] → [ルート] に移動します。なお、学習したオンプレミスサービスのサブネット 192.168.1.0/27 は、

6. オンプレミスサービスへの接続を検証する

プロデューサー VPC から、オンプレミスサービスへの接続をテストするための VM を作成します。その後、サービスアタッチメントを構成して構成します。

Cloud Shell 内で、プロデューサー VPC にテストインスタンスを作成する

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --no-address

IAP に VM インスタンスへの接続を許可するには、次のファイアウォールルールを作成します。

IAP を使用してアクセスできるようにするすべての VM インスタンスに適用します。
IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可する。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。

Cloud Shell 内で、プロデューサー VPC にテストインスタンスを作成する

gcloud compute firewall-rules create ssh-iap \
    --network producer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Cloud Shell で IAP を使用して test-box-us-central1 にログインし、ロードバランシングの IP アドレスに対して curl を実行してオンプレミスサービスへの接続を検証します。タイムアウトした場合は再試行する。

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

オンプレミスサービスへの接続を検証する curl を実行します。確認したら、VM を終了して Cloud Shell プロンプトに戻ります。手順 3 と 4 で特定した出力に基づいて、内部ロードバランサの IP を置き換えます。

deepakmichael@test-box-us-central1:~$ curl -v 10.10.1.2
* Expire in 0 ms for 6 (transfer 0x55b9a6b2f0f0)
*   Trying 10.10.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b9a6b2f0f0)
* Connected to 10.10.1.2 (10.10.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.10.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:42:38 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:42:38 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

7. Private Service Connect サービスアタッチメントを作成する

次の手順ではサービスアタッチメントを作成します。コンシューマエンドポイントとペアにすると、VPC ピアリングを必要とせずにオンプレミスサービスへのアクセスが実現します。

サービスアタッチメントを作成する

Cloud Shell 内でサービスアタッチメントを作成する

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

省略可: 共有 VPC を使用する場合は、サービスプロジェクトにサービスアタッチメントを作成する

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

TCP サービスアタッチメントを検証する

gcloud compute service-attachments describe service-1 --region us-central1

8. 省略可: [ネットワークサービス] → [Private Service Connect] に移動して、新しく確立されたサービスアタッチメントを表示します。

[Service-1] を選択すると、コンシューマがプライベートサービス接続を確立するために使用するサービスアタッチメント URI など、より詳細な情報が提供されます。後のステップで使用するため、URI をメモしておきます。

サービスアタッチメントの詳細: projects/<projectname>/regions/us-central1/serviceAttachments/service-1

9. ユーザー設定

コンシューマ VPC を作成する

Cloud Shell 内で、次のコマンドを実行します。

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

コンシューマサブネットを作成する

Cloud Shell 内で GCE サブネットを作成する

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

Cloud Shell 内でコンシューマエンドポイントサブネットを作成する

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

コンシューマエンドポイント（転送ルール）を作成する

Cloud Shell 内で、コンシューマエンドポイントとして使用する静的 IP アドレスを作成します。

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

前に生成したサービスアタッチメント URI を使用して、コンシューマエンドポイントを作成します。

Cloud Shell 内でコンシューマエンドポイントを作成する

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

10. コンシューマー Private Service Connect を検証する - コンシューマー VPC

コンシューマ VPC から [ネットワークサービス] > [Private Service Connect] > [接続エンドポイント] に移動して、Private Service 接続が成功したことを確認します。確立済みの psc-consumer-1 接続と、それに対応する先ほど作成した IP アドレスをメモしておきます。

psc-consumer-1 を選択すると、サービスアタッチメント URI を含む追加の詳細が提供されます。

11. コンシューマー Private Service Connect を検証する - プロデューサー VPC

プロデューサー VPC から [ネットワークサービス] > [Private Service Connect] → [公開サービス] に移動し、プライベートサービス接続が成功したことを確認します。公開された service-1 接続は、1 つの転送ルール（接続エンドポイント）を示しています。

12. 限定公開 DNS ゾーンを作成し、A レコード

PSC 接続エンドポイントにマッピングされた限定公開 DNS ゾーンを作成して、VPC 内の任意のホストからプロデューサーへのシームレスなアクセスを可能にする。

Cloud Shell から

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

13. VM を使用してプロデューサーサービスへのコンシューマアクセスを検証する

コンシューマ VPC から、コンシューマエンドポイント service1.codelabs.net にアクセスしてオンプレミスサービスへの接続をテストする VM を作成します。

Cloud Shell 内でコンシューマ VPC にテストインスタンスを作成する

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --no-address

IAP に VM インスタンスへの接続を許可するには、次のファイアウォールルールを作成します。

IAP を使用してアクセスできるようにするすべての VM インスタンスに適用します。
IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可する。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。

Cloud Shell 内でコンシューマ VPC にテストインスタンスを作成する

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Cloud Shell で IAP を使用して consumer-vm にログインし、dns FQDN service1.codelab.net に対して curl を実行してオンプレミスサービスへの接続を検証します。タイムアウトした場合は再試行する。

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

オンプレミスサービスへの接続を検証する curl を実行します。確認したら、VM を終了して Cloud Shell プロンプトに戻ります。

Cloud Shell 内で curl を実行する

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

以下は、オンプレミスサービスからのキャプチャの例です。送信元 IP アドレス 172.16.0.2 は、TCP プロキシサブネット範囲 172.16.0.0/23 からのものです。

14. プロデューサーのクリーンアップ

Producer コンポーネントを削除する

Cloud Shell 内でプロデューサーコンポーネントを削除する

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete tcp-ilb-psc --region=us-central1 --quiet

gcloud compute target-tcp-proxies delete on-premise-svc-tcpproxy --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete on-prem-service-hc --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

15. ユーザーのクリーンアップ

コンシューマコンポーネントを削除する

Cloud Shell 内でコンシューマコンポーネントを削除する

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet

16. 完了

これで、TCP プロキシを使用する Private Service Connect の構成と検証が完了しました。

また、プロデューサーインフラストラクチャを作成し、オンプレミスサービスを指すプロデューサー VPC にサービスアタッチメントを追加しました。オンプレミスサービスへの接続を許可するコンシューマ VPC にコンシューマエンドポイントを作成する方法を学習しました。

次のステップ

以下の Codelab をご覧ください。

Private Service Connect とハイブリッド NEG TCP プロキシを使用して、ハイブリッドネットワーク経由でオンプレミスサービスに接続する

1. はじめに

作成するアプリの概要

学習内容

必要なもの

ハイブリッド接続を確立する

カスタムルートアドバタイズ

2. 始める前に

Codelab をサポートするようにプロジェクトを更新する

3. プロデューサーの設定

プロデューサー VPC を作成する

プロデューサーサブネットを作成する

TCP プロキシサブネットを作成する

Private Service Connect NAT サブネットを作成する

プロデューサーのファイアウォールルールを作成する

ハイブリッド接続 NEG を設定する

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

4. ロードバランサを検証する

5. オンプレミスから学習したルートを表示する

6. オンプレミスサービスへの接続を検証する

7. Private Service Connect サービスアタッチメントを作成する

サービスアタッチメントを作成する

8. 省略可: [ネットワークサービス] → [Private Service Connect] に移動して、新しく確立されたサービスアタッチメントを表示します。

9. ユーザー設定

コンシューマ VPC を作成する

コンシューマサブネットを作成する

コンシューマエンドポイント（転送ルール）を作成する

10. コンシューマー Private Service Connect を検証する - コンシューマー VPC

11. コンシューマー Private Service Connect を検証する - プロデューサー VPC

12. 限定公開 DNS ゾーンを作成し、A レコード

13. VM を使用してプロデューサーサービスへのコンシューマアクセスを検証する

以下は、オンプレミスサービスからのキャプチャの例です。送信元 IP アドレス 172.16.0.2 は、TCP プロキシサブネット範囲 172.16.0.0/23 からのものです。

14. プロデューサーのクリーンアップ

Producer コンポーネントを削除する

15. ユーザーのクリーンアップ

コンシューマコンポーネントを削除する

16. 完了

次のステップ

参考資料と動画

リファレンスドキュメント

Private Service Connect とハイブリッド NEG TCP プロキシを使用して、ハイブリッド ネットワーク経由でオンプレミス サービスに接続する

1. はじめに

作成するアプリの概要

学習内容

必要なもの

ハイブリッド接続を確立する

カスタムルート アドバタイズ

2. 始める前に

Codelab をサポートするようにプロジェクトを更新する

3. プロデューサーの設定

プロデューサー VPC を作成する

プロデューサー サブネットを作成する

TCP プロキシ サブネットを作成する

Private Service Connect NAT サブネットを作成する

プロデューサーのファイアウォール ルールを作成する

ハイブリッド接続 NEG を設定する

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

4. ロードバランサを検証する

5. オンプレミスから学習したルートを表示する

6. オンプレミス サービスへの接続を検証する

7. Private Service Connect サービス アタッチメントを作成する

サービス アタッチメントを作成する

8. 省略可: [ネットワーク サービス] → [Private Service Connect] に移動して、新しく確立されたサービス アタッチメントを表示します。

9. ユーザー設定

コンシューマ VPC を作成する

コンシューマ サブネットを作成する

コンシューマ エンドポイント（転送ルール）を作成する

10. コンシューマー Private Service Connect を検証する - コンシューマー VPC

11. コンシューマー Private Service Connect を検証する - プロデューサー VPC

12. 限定公開 DNS ゾーンを作成し、A レコード

13. VM を使用してプロデューサー サービスへのコンシューマ アクセスを検証する

以下は、オンプレミス サービスからのキャプチャの例です。送信元 IP アドレス 172.16.0.2 は、TCP プロキシ サブネット範囲 172.16.0.0/23 からのものです。

14. プロデューサーのクリーンアップ

Producer コンポーネントを削除する

15. ユーザーのクリーンアップ

コンシューマ コンポーネントを削除する

16. 完了

次のステップ

参考資料と動画

リファレンス ドキュメント

Private Service Connect とハイブリッド NEG TCP プロキシを使用して、ハイブリッドネットワーク経由でオンプレミスサービスに接続する

カスタムルートアドバタイズ

プロデューサーサブネットを作成する

TCP プロキシサブネットを作成する

プロデューサーのファイアウォールルールを作成する

6. オンプレミスサービスへの接続を検証する

7. Private Service Connect サービスアタッチメントを作成する

サービスアタッチメントを作成する

8. 省略可: [ネットワークサービス] → [Private Service Connect] に移動して、新しく確立されたサービスアタッチメントを表示します。

コンシューマサブネットを作成する

コンシューマエンドポイント（転送ルール）を作成する

13. VM を使用してプロデューサーサービスへのコンシューマアクセスを検証する

以下は、オンプレミスサービスからのキャプチャの例です。送信元 IP アドレス 172.16.0.2 は、TCP プロキシサブネット範囲 172.16.0.0/23 からのものです。

コンシューマコンポーネントを削除する

リファレンスドキュメント