Private Service Connect インターフェースのマネージド サービス

1. はじめに

Private Service Connect インターフェースは、プロデューサーの Virtual Private Cloud（VPC）ネットワークがコンシューマの VPC ネットワーク内のさまざまな宛先への接続を開始できるようにするためのリソースです。プロデューサー ネットワークとコンシューマ ネットワークは、異なるプロジェクトや組織に属していてもかまいません。

ネットワーク アタッチメントが Private Service Connect インターフェースからの接続を受け入れると、Google Cloud はネットワーク アタッチメントで指定されたコンシューマー サブネットの IP アドレスをインターフェースに割り振ります。コンシューマ ネットワークとプロデューサー ネットワークが接続され、内部 IP アドレスを使用して通信が可能になります。

ネットワーク アタッチメントと Private Service Connect インターフェース間の接続は、Private Service Connect のエンドポイントとサービス アタッチメント間の接続に似ていますが、重要な違いが 2 つあります。

• ネットワーク アタッチメントは、プロデューサー ネットワークからコンシューマ ネットワークへの接続（マネージド サービスの下り、外向き）を開始できるようにします。エンドポイントは、コンシューマ ネットワークからプロデューサー ネットワークへの接続（マネージド サービスの上り、内向き）を開始できるようにします。
• Private Service Connect インターフェースの接続は推移的です。これは、プロデューサー ネットワークは、コンシューマ ネットワークに接続されている他のネットワークと通信できることを意味します。

作成するアプリの概要

コンシューマ VPC に単一の psc-network-attachment を作成し、L4 内部ロードバランサのバックエンドとして 2 つの PSC インターフェースを作成します。プロデューサー VPC から、tiger は backend-vpc の cosmo に curl を送信します。プロデューサーの VPC で、バックエンドと後続の PSC インターフェースを利用してトラフィックを Cosmo に転送する内部ロードバランサとして、宛先トラフィック 192.168.20.0/28 ネクストホップへの静的ルートを作成します。概要については、図 1 をご覧ください。

限定公開サービス アクセスを使用する場合は、お客様の VPC に VPC ピアリングされている Google マネージド サービスでも同じアプローチを使用できます。

図 1

注: このチュートリアルでは、図のトポロジに基づいて構成と検証の手順を説明します。組織の要件に合わせて必要に応じて手順を変更してください。

学習内容

• ネットワーク アタッチメントを作成する方法
• プロデューサーがネットワーク アタッチメントを使用してバックエンドとして PSC インターフェースを作成する方法
• ILB をネクストホップとして使用してプロデューサーからコンシューマへの通信を確立する方法
• VPC ピアリングを介してプロデューサー VM（tiger）からコンシューマ VM（cosmo）へのアクセスを許可する方法

必要なもの

• Google Cloud プロジェクト
• IAM 権限
• Compute ネットワーク管理者 （roles/compute.networkAdmin）
• Compute インスタンス管理者 （roles/compute.instanceAdmin）
• Compute セキュリティ管理者（roles/compute.securityAdmin）

2. 始める前に

チュートリアルをサポートするようにプロジェクトを更新する

このチュートリアルでは、$variables を使用して、Cloud Shell での gcloud 構成の実装を支援します。

Cloud Shell で次の操作を行います。

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

3. コンシューマの設定

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

Cloud Shell で次の操作を行います。

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

Private Service Connect ネットワーク アタッチメント サブネットを作成する

Cloud Shell で次の操作を行います。

gcloud compute networks subnets create intf-subnet --project=$projectid --range=192.168.10.0/28 --network=consumer-vpc --region=us-central1

バックエンド VPC を作成する

Cloud Shell で次の操作を行います。

gcloud compute networks create backend-vpc --project=$projectid --subnet-mode=custom

バックエンド VPC サブネットを作成する

Cloud Shell で次の操作を行います。

gcloud compute networks subnets create cosmo-subnet-1 --project=$projectid --range=192.168.20.0/28 --network=backend-vpc --region=us-central1

バックエンド VPC ファイアウォール ルールを作成する

Cloud Shell で、psc-network-attachment サブネットから cosmo へのトラフィックの上り（内向き）ルールを作成します。

gcloud compute firewall-rules create allow-ingress-to-cosmo \
    --network=backend-vpc \
    --action=ALLOW \
    --rules=ALL \
    --direction=INGRESS \
    --priority=1000 \
    --source-ranges="192.168.10.0/28" \
    --destination-ranges="192.168.20.0/28" \
    --enable-logging

Cloud Router と NAT の構成

このチュートリアルでは、VM インスタンスにパブリック IP アドレスがないため、ソフトウェア パッケージのインストールに Cloud NAT を使用します。Cloud NAT を使用すると、プライベート IP アドレスを持つ VM からインターネットにアクセスできます。

Cloud Shell で、Cloud Router を作成します。

gcloud compute routers create cloud-router-for-nat --network backend-vpc --region us-central1

Cloud Shell で NAT ゲートウェイを作成します。

gcloud compute routers nats create cloud-nat-us-central1 --router=cloud-router-for-nat --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1

4. IAP を有効にする

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

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

Cloud Shell で、IAP ファイアウォール ルールを作成します。

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

5. コンシューマ VM インスタンスを作成する

Cloud Shell で、コンシューマ VM インスタンス cosmo を作成します。

gcloud compute instances create cosmo \
    --project=$projectid \
    --machine-type=e2-micro \
    --image-family debian-11 \
    --no-address \
    --image-project debian-cloud \
    --zone us-central1-a \
    --subnet=cosmo-subnet-1 \
    --metadata startup-script="#! /bin/bash
      sudo apt-get update
      sudo apt-get install tcpdump
      sudo apt-get install apache2 -y
      sudo service apache2 restart
      echo 'Welcome to cosmo's backend server !!' | tee /var/www/html/index.html
      EOF"

インスタンスの IP アドレスを取得して保存します。

Cloud Shell で、cosmo VM インスタンスに対して describe を実行します。

gcloud compute instances describe cosmo --zone=us-central1-a | grep  networkIP:

6. Private Service Connect ネットワーク アタッチメント

ネットワーク アタッチメントは、Private Service Connect インターフェースのコンシューマ側を表すリージョン リソースです。単一のサブネットをネットワーク アタッチメントに関連付けると、プロデューサーはそのサブネットから Private Service Connect インターフェースに IP を割り当てます。サブネットは、ネットワーク アタッチメントと同じリージョンに存在する必要があります。ネットワーク アタッチメントは、プロデューサー サービスと同じリージョンに存在する必要があります。

ネットワーク アタッチメントを作成する

Cloud Shell で、ネットワーク アタッチメントを作成します。

gcloud compute network-attachments create psc-network-attachment \
    --region=us-central1 \
    --connection-preference=ACCEPT_MANUAL \
    --producer-accept-list=$projectid \
    --subnets=intf-subnet

ネットワーク アタッチメントを一覧表示する

Cloud Shell で、ネットワーク アタッチメントを一覧表示します。

gcloud compute network-attachments list

ネットワーク アタッチメントの説明を取得する

Cloud Shell で、ネットワーク アタッチメントの説明を取得します。

gcloud compute network-attachments describe psc-network-attachment --region=us-central1

Private Service Connect インターフェースの作成時にプロデューサーが使用する psc-network-attachment URI をメモします。たとえば次のようになります。

user$ gcloud compute network-attachments describe psc-network-attachment --region=us-central1
connectionPreference: ACCEPT_MANUAL
creationTimestamp: '2023-06-07T11:27:33.116-07:00'
fingerprint: 8SDsvG6TfYQ=
id: '5014253525248340730'
kind: compute#networkAttachment
name: psc-network-attachment
network: https://www.googleapis.com/compute/v1/projects/$projectid/global/networks/consumer-vpc
producerAcceptLists:
- $projectid
region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/networkAttachments/psc-network-attachment
subnetworks:
- https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/subnetworks/intf-subnet

7. コンシューマ VPC とバックエンド VPC の間に VPC ピアリングを確立します。

コンシューマ VPC とバックエンド VPC の間に VPC ピアリング接続を作成します。これにより、Google がネットワーク接続のクロス組織ピアリングに加えて、マネージド サービスのお客様の VPC への接続を確立する方法が再現されます。VPC ピアリングは各 VPC から構成する必要があります。

コンシューマ VPC からバックエンド VPC へのピアリング

コンシューマからバックエンド VPC への VPC ピアリング接続を作成する

Cloud Shell で次の操作を行います。

gcloud compute networks peerings create consumer-to-backend-vpc \
    --network=consumer-vpc \
    --peer-project=$projectid \
    --peer-network=backend-vpc \
    --stack-type=IPV4_ONLY

バックエンドからコンシューマ VPC への VPC ピアリング接続を作成する

Cloud Shell で次の操作を行います。

gcloud compute networks peerings create backend-to-consumer-vpc \
    --network=backend-vpc \
    --peer-project=$projectid \
    --peer-network=consumer-vpc \
    --stack-type=IPV4_ONLY

VPC ピアリングの状態の詳細を確認する

Cloud Shell で、VPC ピアリングが「アクティブ」と「接続済み」の状態であることを確認します。

gcloud compute networks peerings list

例:

user@cloudshell$ gcloud compute networks peerings list
NAME: backend-to-consumer-vpc
NETWORK: backend-vpc
PEER_PROJECT: $projectid
PEER_NETWORK: consumer-vpc
STACK_TYPE: IPV4_ONLY
PEER_MTU: 
IMPORT_CUSTOM_ROUTES: False
EXPORT_CUSTOM_ROUTES: False
STATE: ACTIVE
STATE_DETAILS: [2023-06-07T11:42:27.634-07:00]: Connected.

NAME: consumer-to-backend-vpc
NETWORK: consumer-vpc
PEER_PROJECT: $projectid
PEER_NETWORK: backend-vpc
STACK_TYPE: IPV4_ONLY
PEER_MTU: 
IMPORT_CUSTOM_ROUTES: False
EXPORT_CUSTOM_ROUTES: False
STATE: ACTIVE
STATE_DETAILS: [2023-06-07T11:42:27.634-07:00]: Connected.

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

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

Cloud Shell で次の操作を行います。

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

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

Cloud Shell で、psc インターフェースの vNIC0 に使用するサブネットを作成します。

gcloud compute networks subnets create prod-subnet --project=$projectid --range=10.20.1.0/28 --network=producer-vpc --region=us-central1

Cloud Shell で、インスタンス tiger に使用するサブネットを作成します。

gcloud compute networks subnets create prod-subnet-2 --project=$projectid --range=10.30.1.0/28 --network=producer-vpc --region=us-central1

Cloud Shell で、内部ロードバランサに使用するサブネットを作成します。

gcloud compute networks subnets create prod-subnet-3 --project=$projectid --range=172.16.10.0/28 --network=producer-vpc --region=us-central1

Cloud Router と NAT の構成

このチュートリアルでは、VM インスタンスにパブリック IP アドレスがないため、ソフトウェア パッケージのインストールに Cloud NAT を使用します。Cloud NAT を使用すると、プライベート IP アドレスを持つ VM からインターネットにアクセスできます。

Cloud Shell で、Cloud Router を作成します。

gcloud compute routers create cloud-router-for-nat-producer --network producer-vpc --region us-central1

Cloud Shell で NAT ゲートウェイを作成します。

gcloud compute routers nats create cloud-nat-us-central1-producer --router=cloud-router-for-nat-producer --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1

IAP を有効にする

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

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

Cloud Shell で、IAP ファイアウォール ルールを作成します。

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

プロデューサー VM インスタンスを作成する

Cloud Shell で、コンシューマ VM インスタンス tiger を作成します。

gcloud compute instances create tiger \
    --project=$projectid \
    --machine-type=e2-micro \
    --image-family debian-11 \
    --no-address \
    --image-project debian-cloud \
    --zone us-central1-a \
    --subnet=prod-subnet-2 \
    --metadata startup-script="#! /bin/bash
      sudo apt-get update
      sudo apt-get install tcpdump"

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

プロデューサー VPC で、prod-subnet-2 から producer-vpc 内のすべてのインスタンスへの通信を許可する上り（内向き）ファイアウォール ルールを作成します。

Cloud Shell で、プロデューサーのファイアウォール ルールを作成します。

gcloud compute --project=$projectid firewall-rules create allow-tiger-ingress --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=10.30.1.0/28 --enable-logging

10. Private Service Connect インターフェースを作成する

Private Service Connect インターフェースは、プロデューサーの Virtual Private Cloud（VPC）ネットワークがコンシューマの VPC ネットワーク内のさまざまな宛先への接続を開始できるようにするためのリソースです。プロデューサー ネットワークとコンシューマ ネットワークは、異なるプロジェクトや組織に属していてもかまいません。

ネットワーク アタッチメントが Private Service Connect インターフェースからの接続を受け入れると、Google Cloud はネットワーク アタッチメントで指定されたコンシューマー サブネットの IP アドレスをインターフェースに割り振ります。コンシューマ ネットワークとプロデューサー ネットワークが接続され、内部 IP アドレスを使用して通信が可能になります。

このチュートリアルでは、内部ロードバランサのバックエンドとなる Private Service Connect ネットワーク アタッチメントを使用して 2 つのインスタンスを作成します。

Cloud Shell で Private Service Connect インターフェース（rabbit）を作成し、ネットワーク アタッチメントの describe の出力から、前に特定した psc-network-attachment URI を挿入します。

gcloud compute instances create rabbit --zone us-central1-a --machine-type=f1-micro --can-ip-forward --network-interface subnet=prod-subnet,network=producer-vpc,no-address --network-interface network-attachment=https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/networkAttachments/psc-network-attachment --metadata startup-script="#! /bin/bash
      sudo apt-get update
      sudo apt-get install tcpdump
      sudo apt-get install apache2 -y
      sudo service apache2 restart"

Cloud Shell で Private Service Connect インターフェース（fox）を作成し、ネットワーク アタッチメントの describe の出力から、前に特定した psc-network-attachment URI を挿入します。

gcloud compute instances create fox --zone us-central1-a --machine-type=f1-micro --can-ip-forward --network-interface subnet=prod-subnet,network=producer-vpc,no-address --network-interface network-attachment=https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/networkAttachments/psc-network-attachment --metadata startup-script="#! /bin/bash
      sudo apt-get update
      sudo apt-get install tcpdump
      sudo apt-get install apache2 -y
      sudo service apache2 restart"

マルチ NIC の検証

PSC インターフェースが適切な IP アドレスで構成されていることを確認します。vNIC0 はプロデューサーの prod-subnet（10.20.1.0/28）を使用し、vNIC1 はコンシューマーの intf-subnet（192.168.10.0/28）を使用します。

gcloud compute instances describe rabbit --zone=us-central1-a | grep networkIP:

gcloud compute instances describe fox --zone=us-central1-a | grep networkIP:

例:

user$ gcloud compute instances describe rabbit --zone=us-central1-a | grep networkIP:
  networkIP: 10.20.1.2
  networkIP: 192.168.10.2

user$ gcloud compute instances describe fox --zone=us-central1-a | grep networkIP:
  networkIP: 10.20.1.3
  networkIP: 192.168.10.3

11. rabbit と fox を作成して非マネージド インスタンス グループに追加します。

次のセクションでは、PSC インターフェース インスタンス rabbit と fox で構成される非マネージド インスタンス グループを作成します。

Cloud Shell で、非マネージド インスタンス グループを作成します。

gcloud compute instance-groups unmanaged create psc-interface-instances-ig --project=$projectid --zone=us-central1-a

Cloud Shell で、インスタンス fox と rabbit をインスタンス グループに追加します。

gcloud compute instance-groups unmanaged add-instances psc-interface-instances-ig --project=$projectid --zone=us-central1-a --instances=fox,rabbit

12. TCP ヘルスチェック、バックエンド サービス、転送ルール、ファイアウォールを作成する

Cloud Shell で、バックエンド ヘルスチェックを作成します。

gcloud compute health-checks create http hc-http-80 --port=80

Cloud Shell でバックエンド サービスを作成します。

gcloud compute backend-services create psc-interface-backend --load-balancing-scheme=internal --protocol=tcp --region=us-central1 --health-checks=hc-http-80

gcloud compute backend-services add-backend psc-interface-backend --region=us-central1 --instance-group=psc-interface-instances-ig --instance-group-zone=us-central1-a

Cloud Shell で転送ルールを作成します。

gcloud compute forwarding-rules create psc-ilb --region=us-central1 --load-balancing-scheme=internal --network=producer-vpc --subnet=prod-subnet-3 --address=172.16.10.10 --ip-protocol=TCP --ports=all --backend-service=psc-interface-backend --backend-service-region=us-central1

Cloud Shell から、バックエンドのヘルスチェックを有効にするファイアウォール ルールを作成します。

gcloud compute firewall-rules create ilb-health-checks --allow tcp:80,tcp:443 --network producer-vpc --source-ranges 130.211.0.0/22,35.191.0.0/16 

13. PSC インターフェースの Linux IP テーブルを作成します - rabbit

PSC インターフェース インスタンスから、コンシューマー サブネットへのプロデューサー通信を許可するように Linux IP テーブルを構成します。

Private Service Connect インターフェースのゲスト OS 名を確認する

ルーティングを構成するには、Private Service Connect インターフェースのゲスト OS 名が必要です。これは、Google Cloud のインターフェース名とは異なります。

Cloud Shell で IAP を使用して、psc-interface VM rabbit にログインします。

gcloud compute ssh rabbit --project=$projectid --zone=us-central1-a --tunnel-through-iap

Cloud Shell で、psc-interface インスタンスの IP アドレスを取得します。

ip a

例:

user@rabbit:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 42:01:0a:14:01:02 brd ff:ff:ff:ff:ff:ff
    altname enp0s4
    inet 10.20.1.2/32 brd 10.20.1.2 scope global dynamic ens4
       valid_lft 59396sec preferred_lft 59396sec
    inet6 fe80::4001:aff:fe14:102/64 scope link 
       valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 42:01:c0:a8:0a:02 brd ff:ff:ff:ff:ff:ff
    altname enp0s5
    inet 192.168.10.2/32 brd 192.168.10.2 scope global dynamic ens5
       valid_lft 66782sec preferred_lft 66782sec
    inet6 fe80::4001:c0ff:fea8:a02/64 scope link 
       valid_lft forever preferred_lft forever

PSC インターフェースのゲートウェイ IP を確認する

ネットワーク インターフェースのリストで、Private Service Connect インターフェースの IP アドレスに関連付けられているインターフェース名（例: ens5（vNIC1））を見つけて保存します。

ルーティングを構成するには、Private Service Connect インターフェースのデフォルト ゲートウェイの IP アドレスが必要です。

Cloud Shell では、PSC インターフェースが vNIC1 に関連付けられているため、1 を使用します。

curl http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/1/gateway -H "Metadata-Flavor: Google" && echo

この例では、デフォルトの gw 192.168.10.1 が生成されます。

user@rabbit:~$ curl http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/1/gateway -H "Metadata-Flavor: Google" && echo
192.168.10.1

コンシューマー サブネットのルートを追加する

Private Service Connect インターフェースに接続するコンシューマ サブネットごとに、Private Service Connect インターフェースのデフォルト ゲートウェイへのルートを追加する必要があります。これにより、コンシューマー ネットワークに送信されるトラフィックが、Private Service Connect インターフェースから送信されます。

ルートテーブルを検証する

Cloud Shell で現在のルートを検証します。

ip route show

例:

user@rabbit:~$ ip route show
default via 10.20.1.1 dev ens4 
10.20.1.0/28 via 10.20.1.1 dev ens4 
10.20.1.1 dev ens4 scope link 
192.168.10.0/28 via 192.168.10.1 dev ens5 
192.168.10.1 dev ens5 scope link 

Cloud Shell で、cosmo-subnet-1 へのルートを追加します。

sudo ip route add 192.168.20.0/28 via 192.168.10.1 dev ens5

ルートテーブルを検証する

Cloud Shell で、更新された追加ルートを検証します。

ip route show

例:

user@rabbit:~$ ip route show
default via 10.20.1.1 dev ens4 
10.20.1.0/28 via 10.20.1.1 dev ens4 
10.20.1.1 dev ens4 scope link 
192.168.10.0/28 via 192.168.10.1 dev ens5 
192.168.10.1 dev ens5 scope link 
192.168.20.0/28 via 192.168.10.1 dev ens5 

IP テーブルルールを作成する

Cloud Shell で、現在の IP テーブルを検証します。

sudo iptables -t nat -L -n -v

例:

user@rabbit:~$ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination  

Cloud Shell で IP テーブルを更新する

sudo iptables -t nat -A POSTROUTING -o ens5 -j MASQUERADE
sudo sysctl net.ipv4.ip_forward=1

Cloud Shell で、更新された IP テーブルを検証します。

sudo iptables -t nat -L -n -v

例:

user@rabbit:~$ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  all  --  *      ens5    0.0.0.0/0            0.0.0.0/0

14. PSC インターフェースの Linux IP テーブルを作成する - fox

PSC インターフェース インスタンスから、コンシューマー サブネットへのプロデューサー通信を許可するように Linux IP テーブルを構成します。

Private Service Connect インターフェースのゲスト OS 名を確認する

ルーティングを構成するには、Private Service Connect インターフェースのゲスト OS 名が必要です。これは、Google Cloud のインターフェース名とは異なります。

新しい Cloud Shell タブを開き、プロジェクト設定を更新します。

Cloud Shell で次の操作を行います。

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

Cloud Shell で IAP を使用して、psc-interface VM fox にログインします。

gcloud compute ssh fox --project=$projectid --zone=us-central1-a --tunnel-through-iap

Cloud Shell で、psc-interface インスタンスの IP アドレスを取得します。

ip a

例:

user@fox:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 42:01:0a:14:01:03 brd ff:ff:ff:ff:ff:ff
    altname enp0s4
    inet 10.20.1.3/32 brd 10.20.1.3 scope global dynamic ens4
       valid_lft 65601sec preferred_lft 65601sec
    inet6 fe80::4001:aff:fe14:103/64 scope link 
       valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 42:01:c0:a8:0a:03 brd ff:ff:ff:ff:ff:ff
    altname enp0s5
    inet 192.168.10.3/32 brd 192.168.10.3 scope global dynamic ens5
       valid_lft 63910sec preferred_lft 63910sec
    inet6 fe80::4001:c0ff:fea8:a03/64 scope link 
       valid_lft forever preferred_lft forever

PSC インターフェースのゲートウェイ IP を確認する

ネットワーク インターフェースのリストで、Private Service Connect インターフェースの IP アドレスに関連付けられているインターフェース名（例: ens5（vNIC1））を見つけて保存します。

ルーティングを構成するには、Private Service Connect インターフェースのデフォルト ゲートウェイの IP アドレスが必要です。

Cloud Shell では、PSC インターフェースが vNIC1 に関連付けられているため、1 を使用します。

curl http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/1/gateway -H "Metadata-Flavor: Google" && echo

この例では、デフォルトの gw 192.168.10.1 が生成されます。

user@fox:~$ curl http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/1/gateway -H "Metadata-Flavor: Google" && echo
192.168.10.1

コンシューマー サブネットのルートを追加する

Private Service Connect インターフェースに接続するコンシューマ サブネットごとに、Private Service Connect インターフェースのデフォルト ゲートウェイへのルートを追加する必要があります。これにより、コンシューマー ネットワークに送信されるトラフィックが、Private Service Connect インターフェースから送信されます。

ルートテーブルを検証する

Cloud Shell で現在のルートを検証します。

ip route show

例:

user@fox:~$ ip route show
default via 10.20.1.1 dev ens4 
10.20.1.0/28 via 10.20.1.1 dev ens4 
10.20.1.1 dev ens4 scope link 
192.168.10.0/28 via 192.168.10.1 dev ens5 
192.168.10.1 dev ens5 scope link 

Cloud Shell で、cosmo-subnet-1 へのルートを追加します。

sudo ip route add 192.168.20.0/28 via 192.168.10.1 dev ens5

ルートテーブルを検証する

Cloud Shell で、更新された追加ルートを検証します。

ip route show

例:

user@fox:~$ ip route show
default via 10.20.1.1 dev ens4 
10.20.1.0/28 via 10.20.1.1 dev ens4 
10.20.1.1 dev ens4 scope link 
192.168.10.0/28 via 192.168.10.1 dev ens5 
192.168.10.1 dev ens5 scope link 
192.168.20.0/28 via 192.168.10.1 dev ens5

IP テーブルルールを作成する

Cloud Shell で、現在の IP テーブルを検証します。

sudo iptables -t nat -L -n -v

例:

user@fox:~$ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Cloud Shell で IP テーブルを更新します。

sudo iptables -t nat -A POSTROUTING -o ens5 -j MASQUERADE
sudo sysctl net.ipv4.ip_forward=1

Cloud Shell で、更新された IP テーブルを検証します。

sudo iptables -t nat -L -n -v

例:

user@fox:~$ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  all  --  *      ens5    0.0.0.0/0            0.0.0.0/0  

15. ルートテーブルを更新する

producer-vpc で、コンシューマ サブネット 192.168.20.0/28 への静的ルートを作成し、ネクストホップを内部ロードバランサにします。作成すると、宛先 192.168.20.0/28 への（producer-vpc 内の）すべてのパケットが内部ロードバランサに転送されます。

新しい Cloud Shell タブを開き、プロジェクト設定を更新します。

Cloud Shell で次の操作を行います。

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

Cloud Shell で、静的ルートを使用してプロデューサー VPC ルートテーブルを更新します。

gcloud beta compute routes create producer-to-cosmo-subnet-1 --project=$projectid --network=producer-vpc --priority=1000 --destination-range=192.168.20.0/28 --next-hop-ilb=psc-ilb --next-hop-ilb-region=us-central1

16. tiger から cosmo への接続が正常に行われたことを確認します。

Curl の検証

curl を実行して、プロデューサー VM インスタンス tiger がコンシューマ インスタンス cosmo と通信できることを確認しましょう。

新しい Cloud Shell タブを開き、プロジェクト設定を更新します。

Cloud Shell で次の操作を行います。

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

Cloud Shell で IAP を使用して tiger インスタンスにログインします。

gcloud compute ssh tiger --project=$projectid --zone=us-central1-a --tunnel-through-iap

tiger インスタンスから、チュートリアルの前半で特定した cosmo の IP アドレスに対して curl を実行します。

curl -v <cosmo's IP Address>

例:

user@tiger:~$ curl -v 192.168.20.2
*   Trying 192.168.20.2:80...
* Connected to 192.168.20.2 (192.168.20.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.20.2
> User-Agent: curl/7.74.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Fri, 09 Jun 2023 03:49:42 GMT
< Server: Apache/2.4.56 (Debian)
< Last-Modified: Fri, 09 Jun 2023 03:28:37 GMT
< ETag: "27-5fda9f6ea060e"
< Accept-Ranges: bytes
< Content-Length: 39
< Content-Type: text/html
< 
Welcome to cosmo's backend server !!

おめでとうございます。curl コマンドを実行して、producer-vpc から backend-vpc への接続を正常に検証しました。

17. クリーンアップ

Cloud Shell で、チュートリアルのコンポーネントを削除します。

gcloud compute instances delete cosmo --zone=us-central1-a --quiet

gcloud compute instances delete rabbit --zone=us-central1-a --quiet

gcloud compute instances delete fox --zone=us-central1-a --quiet

gcloud compute instances delete tiger --zone=us-central1-a --quiet

gcloud compute network-attachments delete psc-network-attachment --region=us-central1 --quiet

gcloud compute firewall-rules delete allow-ingress-to-cosmo allow-tiger-ingress ilb-health-checks ssh-iap-consumer   ssh-iap-producer --quiet

gcloud beta compute routes delete producer-to-cosmo-subnet-1 --quiet 

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

gcloud compute backend-services delete psc-interface-backend --region=us-central1 --quiet

gcloud compute instance-groups unmanaged delete psc-interface-instances-ig --zone=us-central1-a --quiet

gcloud compute health-checks delete hc-http-80 --quiet

gcloud compute networks subnets delete cosmo-subnet-1 prod-subnet prod-subnet-2 prod-subnet-3 intf-subnet --region=us-central1 --quiet

gcloud compute routers delete cloud-router-for-nat --region=us-central1 --quiet

gcloud compute routers delete cloud-router-for-nat-producer --region=us-central1 --quiet

gcloud compute networks delete consumer-vpc --quiet

gcloud compute networks delete producer-vpc --quiet

gcloud compute networks delete backend-vpc --quiet

18. 完了

これで、Private Service Connect インターフェースの構成と検証が完了し、VPC ピアリングを介したコンシューマとプロデューサーの接続が検証されました。

コンシューマ インフラストラクチャを作成し、プロデューサーがマルチ NIC VM を作成してコンシューマとプロデューサーの通信をブリッジできるようにネットワーク アタッチメントを追加しました。PSC インターフェースを使用して、プロデューサーの VPC 内の内部ロードバランサと静的ルートを使用して、VPC ピアリングを介して 1P/3P サービスと通信する方法について学習しました。

Cosmopup はチュートリアルが大好きです。

次のステップ

以下のチュートリアルをご覧ください。

• GKE を使用した Private Service Connect によるサービスの公開と使用
• Private Service Connect でサービスを公開して使用する
• Private Service Connect と内部 TCP プロキシ ロードバランサを使用して、ハイブリッド ネットワーキング経由でオンプレミス サービスに接続する

参考資料と動画

• Private Service Connect の概要
• Private Service Connect とは
• サポートされているロードバランサのタイプ

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

• 内部 HTTP(S) ロードバランサの概要
• ヘルスチェックの概要
• Private Service Connect を使用してサービスを公開する方法
• Private Service Connect - DNS の自動化