Go to Qiita Advent Calendar 2024 Top
LoginSignup
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@testnin2(Shinobu Yasuda)inIBM

IBM Cloud: Private Path Service(Beta)を試してみた

Last updated at Posted at 2024-05-15

1. はじめに

Private Path Serviceのベータプログラムに参加して、その機能を確認してみたので、本稿で紹介する。なお、あくまで本サービスは現段階ではベータなので、GA時点では仕様が変更される可能性があるので注意してもらいたい。

2. Transit Gatewayではなぜダメなのか？

Transit Gatewayでは、VPC上の全てのネットワーク情報が、Transit Gatewayに接続している対象すべてにBGP advertiseされてしまう。これは、サービスを提供する上で外部に公開したくない内部ネットワーク情報もBGP advertiseされてしまうということである。

もちろん、ある程度はplefix filteringで互いの経路広告をフィルタリングすることもできるのだが、例えば以下のようにサービス提供側VPC(Provider VPC)と利用者側VPC(Consumer VPC)を1:1でTransit Gatewayで構成したとしても、

  • サービス利用者とサービス提供者のaddress prefixが重複していないか？（特にサービス利用者がアクセスしようとしているサービス提供者のネットワークが、サービス利用者のネットワークと重複していないか？）
  • サービス利用者間（この図においてはVPC-AとVPC-B）のaddress prefixが重複していないか？　（被ってしまうと、longest matchingでよりaddress prefix長が短い方としか通信できない）

など、互いのVPCのネットワーク設計を考慮しなければいけないため、一般的にTransit Gatewayはサービスを公開する用途には向いていない。

image.png

3. Private Path Serviceとは

Private Path Serviceでは、サービス提供側VPC(Provider VPC)で提供されている特定のサービスのみを、利用者側VPC(Consumer VPC)に公開することができるという利点がある。

  • Private Path Serviceでは、Transit Gatewayのように全てのネットワークが互いのVPCに公開されることはない。逆にいうと、Private Path Serviceを利用する上でのネットワーク設計において、サービス利用者(Consumer VPC)およびサービス提供者(Provider VPC)は、互いのネットワーク情報の詳細を知る必要はない。
  • Private Path Serviceでは、サービス利用者(Consumer VPC)からサービス提供者(Provider VPC)への一方通行のアクセスのみが許可されている。
    • 利用者側VPC(Consumer VPC)のVPEにアクセスすると、IBM Cloud backbone内でインターネットに出て行くことなく、サービス提供側VPC(Provider VPC)のPrivate Path NLB(PPNLB)に通信が転送され、その後PPNLBのバックエンドメンバーにロードバランシングされる。
    • PPNLBはリージョナルサービスであり、AZに跨ってactive-active topologyで稼働する。仮にどこか１つのAZが停止してもサービスを継続提供可能。
    • Backend memberから見ると、往路のトラフィックのsource IPはConsumer VPCのIPアドレスではなく、Provider VPCにあるPPNLBに割り当てられたVIPになる。
    • Backend memberからの復路のトラフィックは、PPNLBを経由することなく、VPEにDSR(Direct Server Return)で戻る。
    • Consumer VPCとProvider VPCは同一VPCであっても良い。

image.png

Private Pathの制限事項は以下の通り。

また、docsに明示的に記載はされていないが、あるPrivate Pathサービスに対して、１つのVPCには1つのVPEしか作成できないという制約もある（VPEもリージョナルサービスなので複数VPEを作成する意味はないので、この制約は妥当なものではあるが）。

あるPrivate Pathサービスに対して、１つのVPCには1つのVPEしか作成できない。
An error occurred and virtual private endpoint gateway 'vpe-privatepath-test02' wasn't created.
An endpoint gateway already exists for this service. There is just 1 endpoint gateway allowed for a service per VPC.

4. Private Path Service 利用のための一連の手順

  1. Provider VPC: VSI上にサービスを作成する

  2. Provider VPC: PPNLB(Private Path NLB)を作成し、上記のVSIをbackend serverとして登録する

  3. Provider VPC: Private Path Serviceを作成し、Consumer VPCからの接続許可に対するポリシーを設定する。この状態では、Private Path ServiceはPublish=Noの状態。

  4. Consumer VPC（同一アカウント）: 上記のPrivate Path Serviceに対してVPEを作成する。

  5. Provider VPC: Private Path Serviceにて、VPEからの接続リクエストを許可する。

  6. Consumer VPC（同一アカウント）: VPEに対して別AZのreserved IPを割り当てる。

  7. Consumer VPC（同一アカウント）: VPE経由での接続テストを行う。



    もし、別アカウントのVPCにサービス公開したい場合は、Publish=Yesに変更する必要がある。


  8. Provider VPC: Private Path ServiceのPublish=Yesに変更する（一度Yesにすると戻せない）

    https://cloud.ibm.com/docs/vpc?topic=vpc-pps-verify&interface=ui&locale=en
    To verify that the Private Path service is fully functional before publishing it for consumer use, you must use the same account to create the VPE gateway as the account used to create the Private Path service. (After you publish your Private Path service, any account can be used to create the VPE gateway.)

    https://cloud.ibm.com/docs/vpc?topic=vpc-pps-activating&interface=ui
    Important: After the service is published, it cannot be unpublished.

  9. Consumer VPC（別アカウント）: 上記のPrivate Path Serviceに対してVPEを作成する。

  10. Provider VPC: Private Path ServiceVPEからの接続リクエストを許可する。

  11. Consumer VPC（別アカウント）: VPEに対して別AZのreserved IPを割り当てる。

  12. Consumer VPC（別アカウント）: VPE経由での接続テストを行う。

以下では、1~7までの一連の手順を追ってみたいと思う。（8以降はほぼ同じなので今回は省略）

5. 手順

5-1. Provider VPC: VSI上にサービスを作成する

詳細手順は省略。今回はwebサーバーおよびSSHサービスが稼働していることとする。

[root@hub-spoke-test-syasuda1 ~]# curl localhost
This is PPS test

5-2. Provider VPC: Private Path NLB(PPNLB)を作成し、上記のVSIをbackend serverとして登録する

  1. Load Balancerの注文画面にて、Createを押下
    image.png
  2. NLBを選択image.png
  3. TypeとしてPrivate pathを選択。Tokyo1に存在するsubnetを選択する。なお、先述の通り、PPNLBはリージョナルサービスであり、このsubnet上でPPNLBが稼働するという意味ではない。このsubnetはbackend serverに転送する際のsource IPとして利用される。image.png
  4. ここはデフォルトのまま（後から設定をする）image.png
  5. 注文完了後。TypeがPrivate Pathになっている。image.png
  6. Frontend-listner/Backend-poolを作成し、公開対象のサービスが稼働するVSIをBackend poolに登録する（省略）。結果、以下のようになる。今回は任意のポート番号でアクセスできるように、Listner port rangesは1-65535で構成している。 image.png
    image.png
    image.png

5-3. Provider VPC: Private Path Serviceを作成する。

  1. Create image.png

  2. 以下を指定する。

    • リージョン、Private Path Service名、リソースグループなどを設定。
    • Provider VPCを選択し、先ほど作成したPPNLBを選択する。
    • service endpointのFQDNを指定。Consumer VPCからは、このFQDNでVPEにアクセス可能になる。
    • Zone Affinityの指定。有効にしておくと、Consumer VPCからのアクセス先であるVPEと同一ZoneにあるPPNLBにリクエストが転送される。このヒント情報には以下のように記載されている。image.png
    • Connection requestのdefault policy。Consumer VPCからの接続許可を求められた際のポリシーとして、
      1. 毎回レビューする(Review all requests)
      2. 常に許可する(Permit all requests)
      3. 常に拒否する(Deny all requests)
        の中から選択することができる。今回は1を選択した。

    image.png
    image.png

作成後の状態は、以下の通り。

  • Private Path Service一覧 image.png
  • まだこの状態では、Published=No。VPEを作成する際に、Private Path ServiceのCRN情報が必要になるので、控えておく。image.png

5-4. Consumer VPC: VPEを作成する

  1. Create image.png
  2. 以下を指定する。
    • リージョン、VPE名、リソースグループなどを設定。
    • VPCはConsumer VPCを指定。
    • VPEに割り当てるSecurity Groupを指定
    • Request connection to a serviceでは、Non-IBM Cloud Serviceを選択する。これによって、先ほど作成したPrivate Path Serviceを指定することができる。
    • Private Path Service CRNには、先ほど作成したPrivate Path ServiceのCRNを入力する。
    • image.png
      image.png
      image.png
  3. 先ほど作成したVPEは以下の通り。まだPending状態になっている。image.png

5-5. Provider VPC: Private Path Serviceにて、VPEからの接続リクエストを許可する

Provider VPCのPrivate Path Serviceにて、先ほどのVPEからの接続リクエストが来ているため、承認する。
image.png

  • レビュー待ちの接続リクエストは、Requests to reviewに表示される。image.png
  • 承認されたリクエストは、Permittedで表示される。なお、いったん承認された接続を、Revokeすることも可能。
    image.png

これにより、Consumer VPCで作成された先ほどのVPEのステータスがPendingからStableに変更した。
image.png

5-6. Consumer VPC: VPEに別zoneのreserved IPを割り当てる。

VPEの詳細画面におけるAttached Resourcesに移動する。VPE自体はリージョナルサービスだが、まだTokyo1のReserved IPが1つしか紐づいいていない。高可用性を保つため、Tokyo2/Tokyo3にもReserved IPを割り当てる。Reserved IPを今後も再利用できるように、Auto-releaseは無効にしておいた。

  • before image.png
  • after image.png

5-7. Consumer VPC: 接続テスト

consumer VPCからのservice endpointに対する名前解決。VPEのReserved IPの１つが返ってくる。
$ dig web1.syasuda.pps

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.15 <<>> web1.syasuda.pps
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34896
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;web1.syasuda.pps.		IN	A

;; ANSWER SECTION:
web1.syasuda.pps.	900	IN	A	10.0.0.50

;; Query time: 2 msec
;; SERVER: 161.26.0.7#53(161.26.0.7)
;; WHEN: Wed May 15 17:51:10 JST 2024
;; MSG SIZE  rcvd: 66
consumer VPCからのservice endpointに対するweb access。
$ curl http://web1.syasuda.pps
This is PPS test!
consumer VPCからのservice endpointに対するSSH access。
$ ssh root@web1.syasuda.pps
The authenticity of host 'web1.syasuda.pps (10.0.0.50)' can't be established.
ECDSA key fingerprint is SHA256:dVIWnUPdqR08l8rj8ez0V/WtVYODR/0VWHLE/SzL9kA.
ECDSA key fingerprint is MD5:82:89:98:f8:df:81:00:c7:8b:e0:b8:3d:cc:7c:48:b7.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'web1.syasuda.pps,10.0.0.50' (ECDSA) to the list of known hosts.
Last login: Wed May 15 04:52:12 2024 from 111.238.9.129
[root@hub-spoke-test-syasuda1 ~]#
ターゲットサーバーにとっては、Consumer VPCのVSIのIPアドレスではなく、PPNLBのVIPが接続元IPとなっている。
[root@hub-spoke-test-syasuda1 ~]# tail -f /var/log/httpd/access_log
（途中省略）
172.16.0.10 - - [15/May/2024:05:17:44 -0400] "GET / HTTP/1.1" 200 18 "-" "curl/7.29.0"
（途中省略）

[root@hub-spoke-test-syasuda1 ~]# tail -f /var/log/secure
（途中省略）
May 15 05:19:38 hub-spoke-test-syasuda1 sshd[12093]: Accepted publickey for root from 172.16.0.10 port 4096 ssh2: RSA SHA256:0pUqd7pCk8KQH30tsDMx6pTKD/G/DWoVjALradjauuQ
May 15 05:19:38 hub-spoke-test-syasuda1 sshd[12093]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
（途中省略）
3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?