16. IBM Cloud: VMware as a Service（VMWaaS) - Transit Gateway接続

Last updated at 2024-10-04Posted at 2024-03-20

1. はじめに

今までは、VDC内部からの通信や、VDC外部からのインターネット通信、IBM Cloudのprivate networkへの通信などを確認してきました。しかし、IBM Cloudには、Classic Infrastructure/VPC/IBM Power Virtual Serverなど様々なIaaS環境が存在し、それらとも相互接続したいという要件は多くあると思われます。また、オンプレミスからVDCにDirect Link経由でセキュアに接続したいという要望もあるでしょう。一般的に、IBM CloudではTransit Gatewayが各種サービスへの接続ハブとなるため、本稿ではVDCがTransit Gatewayと連携できることを確認したいと思います。

過去の記事はこちら。

2. VDCとのTransit Gateway連携の概要

参考docsはこちら。
VDCから6本のGRE TunnelをTransit Gatewayに接続する（GRE TunnelはTransit Gateway内で冗長化されていないため、各AZに付き2本構成する。）
VMware Cloud Director siteとGRE接続するTransit Gatewayは、VMware Cloud Director siteと同じリージョンである必要がある。
Transit Gatewayは別アカウントでも良い。

以下の画面からも、この後のアーキテクチャー概要を確認することができます。

VDC詳細画面においてInterconnectivityのタブに移動する。
上記画面にてLearn Moreを選択すると、以下の画面が現れる。

3. VDCとのTransit Gateway接続

今回利用しているVDC/VMware Cloud DirectorがDALにあるため、DALにTransit Gatewayを作成しておく。
VDCの詳細画面におけるInterconnectivityのタブにて、Add connection groupを押下。
上記のTransit Gateway IDを入力してAdd。
仕掛かり中。パラメーターを生成している。
パラメーター生成が完了した。
上記で表示されたパラメーターを１つ１つコピーしながらTransit Gatewayにコンソールから設定しても良いのだが、、、、6つもconnectionがあるので大変である。よって、以下のように、Generatet CLI commandからコマンドを実行させた方が良い。

今回の検証において、VMware Cloud Director siteはus-southに存在します。Add connection groupにて、jp-tokに存在するTransit Gatewayも試しに指定してみましたが、その場合でもus-south接続用のパラメーターおよびCLIコマンドが生成されました。生成されたCLIコマンドの中でus-southの箇所を置き換えてjp-tokを指定してみましたが、コマンドは成功しても、以下のようにずっとPending Approval状態が続いて結局GREが接続できませんでした。やはり、docsに書かれているように、VMware Cloud Director siteとGRE接続するTransit Gatewayは、VMware Cloud Director siteと同じリージョンである必要がありそうです。

上記のCLIを実行した結果。
Transit Gateway側でも同様に構成がされている。

6つのGRE Connectionのうち１つでも非接続状態の場合は、以下のような警告が表示されます。

4. Transit Gatewayへの経路広告

この状態で、Transit GatewayにおけるBGP reportを生成させても、VDCからの経路広告はありません。

VDCからの経路広告を実施するためには、VDCにて経路広告の設定を行う必要があります。

Edge Gatewayにおける、Routing -> Route Advertisementに移動し、EDITを押下。
VDC内のrouted networkの公開対象を追加する。
- 例えば、10.55.0.0/24, 10.55.1.0/24, 10.55.2.0/24,...というrouted networkが存在し、それらを全てTransit GatewayへのBGP広告対象とするのであれば、10.55.0.0/16を設定すれば、10.55.0.0/24, 10.55.1.0/24, 10.55.2.0/24、...がそれぞれTransit Gatewayに広告される（10.55.0.0/16で広告される訳ではない）。ここでは、Prefix Filteringをしていると思うと良いかもしれない。
- 今回は、VDC routed networkのうち、192.168.100.0/24というsubnetのみをBGPの広告対象とする。
追加された。
Transit Gatewayにて経路情報レポートを生成すると、以下のように複数経路から192.168.100.0/24宛の経路が広告されていることがわかる。

VDC上には最低１つのrouted networkが必要です。１つもrouted networkが存在しない場合は、BGPの構成をしても広告されません。

5. VPCとの接続確認

以下、VDC - Transit Gateway - VPC間の接続確認を実施します。

5-1. Transit GatewayにVPCを追加。

東京リージョンにあるVPCをTransit Gatewayのconnectionに追加します。

5-2. VPCにおけるSecurity Groupで、VDCからのアクセスを許可

今回は、RFC1918で定めるprivate network(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)をすべて許可しています。

5-3. IPSetsの追加

VDCのFirewall設定のために、RFC1918-private-networkというIP Setを定義し、10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16を追加します。

NEW
該当のsubnetを追加してSAVE
結果。

5-4. Edge Firewallの設定

VDC-> VPCおよびVPC -> VDCの通信を許可するために、RFC1918-private-networkからRFC1918-private-networkへの通信をすべて許可します。

5-5. NATの設定

ちなみに、これまでの過去の解説に従って構成していた場合、この時点でもVPC -> VDCへのpingが通りますが、VDC -> VPCへのpingは通りません。

[root@tok1-vpc ~]# ping 192.168.100.2
PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data.
64 bytes from 192.168.100.2: icmp_seq=1 ttl=51 time=139 ms
64 bytes from 192.168.100.2: icmp_seq=2 ttl=51 time=139 ms
64 bytes from 192.168.100.2: icmp_seq=3 ttl=51 time=139 ms
64 bytes from 192.168.100.2: icmp_seq=4 ttl=51 time=139 ms
^C
--- 192.168.100.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 139.359/139.555/139.899/0.428 ms

[root@jumpserver ~]# ping 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
^C
--- 10.0.0.4 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4131ms

これは、以下のようにVDC -> VPCへの通信に対しても、SNATが適用されてしまっているからです。

VDC -> Internet: SNATが必要
VDC -> IBM Cloud Private Network: SNATが必要
VDC -> Transit Gateway -> （他のリソース): SNATが発生してはいけない

というところが、ポイントです。

VDC -> VPCへの通信でSNATのルールが適用されないようにするためには、以下の手順に従います。

（今回のVPC上のVSIのnetworkは10.0.0.0/8上に存在するので、10.0.0.0/8宛の通信はNO SNATにするようなNATを追加する。
既存のSNATルールについて、SNATルールのPriorityを100に下げる。
確認
とはいっても、このままでは本当にPriority値が正しく設定されているのかを一目で見れないので、左下のカラム編集ボタンを押下し、Priorityを追加
5.　最終確認。

複数NATルールが存在する場合は、どちらのNATルールを優先して適用するかはPriorityによって決まります。Priorityにて設定する数字が低い方が優先度が高くなります。再度、Priorityの説明を記載しておきます。

If an address has multiple NAT rules, the rule with the highest priority is applied. A lower value means a higher precedence for this rule.

priorityが同じ場合は、どちらのNATルールが適用されるか保証がありません（試してみたところ、先に作成されたNATルールが実行されているようにも見えますが・・・・・・そういう仕様であるという明文化された情報はありませんし、どちらが先に作成されたのかを当時の設定者以外が判別するのは困難だと思われます）

6. 接続確認

これにより、VPC<->VDC間のすべての通信が可能になりました。

VDC -> VPC

[root@jumpserver ~]# ping 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=62 time=140 ms
64 bytes from 10.0.0.4: icmp_seq=2 ttl=62 time=140 ms
64 bytes from 10.0.0.4: icmp_seq=3 ttl=62 time=139 ms
64 bytes from 10.0.0.4: icmp_seq=4 ttl=62 time=139 ms
^C
--- 10.0.0.4 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 139.363/139.495/139.624/0.093 ms

VDC -> IBM Cloud Private Network

[root@jumpserver ~]# ping 161.26.0.10
PING 161.26.0.10 (161.26.0.10) 56(84) bytes of data.
64 bytes from 161.26.0.10: icmp_seq=1 ttl=249 time=0.818 ms
64 bytes from 161.26.0.10: icmp_seq=2 ttl=249 time=0.863 ms
64 bytes from 161.26.0.10: icmp_seq=3 ttl=249 time=0.785 ms
64 bytes from 161.26.0.10: icmp_seq=4 ttl=249 time=0.870 ms
^C
--- 161.26.0.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3104ms
rtt min/avg/max/mdev = 0.785/0.834/0.870/0.034 ms

[root@jumpserver ~]# ping s3.direct.jp-tok.cloud-object-storage.appdomain.cloud
PING s3.direct.jp-tok.cloud-object-storage.appdomain.cloud (161.26.0.22) 56(84) bytes of data.
64 bytes from 16.00.1aa1.ip4.static.sl-reverse.com (161.26.0.22): icmp_seq=1 ttl=240 time=148 ms
64 bytes from 16.00.1aa1.ip4.static.sl-reverse.com (161.26.0.22): icmp_seq=2 ttl=240 time=148 ms
64 bytes from 16.00.1aa1.ip4.static.sl-reverse.com (161.26.0.22): icmp_seq=3 ttl=240 time=148 ms
64 bytes from 16.00.1aa1.ip4.static.sl-reverse.com (161.26.0.22): icmp_seq=4 ttl=240 time=148 ms
^C
--- s3.direct.jp-tok.cloud-object-storage.appdomain.cloud ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 147.991/148.026/148.061/0.024 ms

VDC -> Internet

[root@new-syasuda-tok1-vpc1 ~]# ping www.yahoo.co.jp
PING edge12.g.yimg.jp (182.22.28.252) 56(84) bytes of data.
64 bytes from 182.22.28.252 (182.22.28.252): icmp_seq=1 ttl=57 time=1.30 ms
64 bytes from 182.22.28.252 (182.22.28.252): icmp_seq=2 ttl=57 time=1.46 ms
64 bytes from 182.22.28.252 (182.22.28.252): icmp_seq=3 ttl=57 time=1.54 ms
64 bytes from 182.22.28.252 (182.22.28.252): icmp_seq=4 ttl=57 time=1.45 ms
^C
--- edge12.g.yimg.jp ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 1.309/1.445/1.549/0.094 ms

VPC -> VDC

[root@tok1-vpc ~]# ping 192.168.100.2
PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data.
64 bytes from 192.168.100.2: icmp_seq=1 ttl=51 time=139 ms
64 bytes from 192.168.100.2: icmp_seq=2 ttl=51 time=139 ms
64 bytes from 192.168.100.2: icmp_seq=3 ttl=51 time=139 ms
64 bytes from 192.168.100.2: icmp_seq=4 ttl=51 time=139 ms
^C
--- 192.168.100.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 139.286/139.452/139.548/0.099 ms

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up