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

1. はじめに

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

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

作成するアプリの概要

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

a4fa0e406e7232fa.png

学習内容

  • ハイブリッド 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 Health Check

2. 始める前に

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

この Codelab では、$variables を使用して、Cloud Shell での gcloud 構成の実装を支援します。

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 ネットワーク内に複数のロードバランサをデプロイすると、ロード バランシング用に同じプロキシ専用サブネットが共有されます。

  1. クライアントは、ロードバランサの転送ルールの IP アドレスとポートに接続します。
  2. 各プロキシは、対応するロードバランサの転送ルールで指定された IP アドレスとポートでリッスンします。いずれかのプロキシがクライアントのネットワーク接続を受信して終了します。
  3. プロキシは、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 とオンプレミスまたは他のクラウド環境との間の地理的距離を最小限に抑える ZONE を使用します。たとえば、ドイツのフランクフルトのオンプレミス環境にサービスをホストする場合、NEG を作成するときに europe-west3-a Google Cloud ゾーンを指定できます。

また、Cloud Interconnect を使用している場合は、NEG の作成に使用する ZONE は、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 が 「緑」になっているのは、オンプレミス サービスへのヘルスチェックが成功したことを示しています。

c16a93d1e185336b.png

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

26db2d30747fd40a.png

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

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

bae85fdc418f9811.png

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] に移動して、新しく確立されたサービス アタッチメントを表示します。

bddc23a10d38d981.png

[Service-1] を選択すると、コンシューマーが Private Service Connection を確立するために使用するサービス アタッチメント URI など、詳細が表示されます。URI は後のステップで使用するため、メモしておきます。

5c0a74874536909d.png

サービス アタッチメントの詳細: 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 Connection が成功したことを確認します。確立された psc-consumer-1 接続と、以前に作成した対応する IP アドレスをメモします。

629d4cea87293a42.png

psc-consumer-1 を選択すると、サービス アタッチメント URI などの詳細情報が表示されます。

18b132b458f698b4.png

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

プロデューサー VPC から、[ネットワーク サービス] → [Private Service Connect] → [公開済みサービス] に移動して、Private Service Connection が成功したことを確認します。公開された service-1 接続に、1 つの転送ルール(接続エンドポイント)が示されていることに注意してください。

3387b170742d7d8d.png

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 からのものであることに注意してください。

6dafe24917c937cb.png

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. コンシューマーのクリーンアップ

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

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 をご覧ください。

参考資料と動画

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