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

# 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と連携できることを確認したいと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/7e479dbb-298c-fbcd-7fb1-950951d82341.png)


過去の記事はこちら。

- [01. IBM Cloud: VMware as a Service（VMWaaS)の概要](https://qiita.com/testnin2/items/d39ba856f70fc14ea719) 
- [02. IBM Cloud: VMware as a Service（VMWaaS) - VDCの注文](https://qiita.com/testnin2/items/a3630d5a532a6ce48720)
- [03. IBM Cloud: VMware as a Service（VMWaaS) - VDCの追加注文](https://qiita.com/testnin2/items/666a8a03db85f983f56a) 
- [04. IBM Cloud: VMware as a Service（VMWaaS) - 外部接続のためのネットワークとNAT/Firewallを構成する](https://qiita.com/testnin2/items/3575b27c2ec2b6242ee6) 
- [05. IBM Cloud: VMware as a Service（VMWaaS) - RHELをプロビジョニングして疎通確認を行う](https://qiita.com/testnin2/items/56901ef332ee060fcf2f) 
- [06. IBM Cloud: VMware as a Service（VMWaaS) - 検証: IBM Cloud private networkへの通信におけるSNATの必要性](https://qiita.com/testnin2/items/5add312256d1e264e31f)
- [07. IBM Cloud: VMware as a Service（VMWaaS) - 検証: isolated networkとの通信](https://qiita.com/testnin2/items/9bc1b57b9636071b7239)
- [08. IBM Cloud: VMware as a Service（VMWaaS) - 検証: routed network間の通信](https://qiita.com/testnin2/items/fa9426df262368ddc2ef) 
- [09. IBM Cloud: VMware as a Service（VMWaaS) - Data Center Groupの構成](https://qiita.com/testnin2/items/f940550d7564db526531) 
- [10. IBM Cloud: VMware as a Service（VMWaaS) - Distributed Firewallの構成](https://qiita.com/testnin2/items/26dd06d28effbd83ff9e) 
- [11. IBM Cloud: VMware as a Service（VMWaaS) - VDC間のVM/vApp Migration](https://qiita.com/testnin2/items/381c5e6db4fdd7ed64d6)
- [12. IBM Cloud: VMware as a Service（VMWaaS) - VMWaaS APIの実行例](https://qiita.com/testnin2/items/3e0e86a25bfd06a165bf)
- [13. IBM Cloud: VMware as a Service（VMWaaS) - VMware Cloud Director OpenAPIの実行例](https://qiita.com/testnin2/items/420e55a06255d626a471) 
- [14. IBM Cloud: VMware as a Service（VMWaaS) - 検証: VIP切り替えによる高可用性構成の確認（手動切替）](https://qiita.com/testnin2/items/fead2339a999242ecae9) 
- [15. IBM Cloud: VMware as a Service（VMWaaS) - 検証: VIP切り替えによる高可用性構成の確認（keepalived）](https://qiita.com/testnin2/items/2a5c9660ccfab74faa49) 
- [16. IBM Cloud: VMware as a Service（VMWaaS) - Transit Gateway接続](https://qiita.com/testnin2/items/1ec6223b6713eb58e156) 
- [17. IBM Cloud: VMware as a Service（VMWaaS) - Veeam Backup and Replication service連携](https://qiita.com/testnin2/items/69fd29db9f8cc313e353) 

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

- 参考docsは[こちら](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-tgw-adding-connections&locale=en)。
- 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`のタブに移動する。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/d428fbde-842a-a163-07ab-22e667a4b9cd.png)
- 上記画面にてLearn Moreを選択すると、以下の画面が現れる。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/598f3562-9b0e-3b4b-a15d-f3136fd56ade.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/d33984fa-7592-aeb7-c429-4ae62fc58b5c.png)

# 3. VDCとのTransit Gateway接続

- 今回利用しているVDC/VMware Cloud DirectorがDALにあるため、DALにTransit Gatewayを作成しておく。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/b9f7dfaa-309d-8a50-dd70-b30ae9d51509.png)
- VDCの詳細画面における`Interconnectivity`のタブにて、`Add connection group`を押下。 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/7f3c7434-a12d-fd65-8788-b0fe43c31711.png)
- 上記のTransit Gateway IDを入力して`Add`。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/6f23f475-02cb-5054-7d08-d3adc7614afd.png)
- 仕掛かり中。パラメーターを生成している。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/bff1b8cd-c27e-e1f9-be1a-ec629e401ed2.png)
- パラメーター生成が完了した。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/9df7219c-432d-0b80-0467-aa5bdceb99e1.png)
- 上記で表示されたパラメーターを１つ１つコピーしながらTransit Gatewayにコンソールから設定しても良いのだが、、、、6つもconnectionがあるので大変である。よって、以下のように、`Generatet CLI command`からコマンドを実行させた方が良い。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/c96ab2e1-7fb8-9bc1-11e0-65a6c4719b4c.png)![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/dd494ade-d951-3e6a-a5ba-c4f6ca7344b2.png)

:::note warn
今回の検証において、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と**同じリージョン**である必要がありそうです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/38be9f59-3f8b-a19e-d971-21e7fca37fca.png)
:::

- 上記のCLIを実行した結果。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/92e131ae-86ce-3240-ba3e-2b294b6b7449.png)
- Transit Gateway側でも同様に構成がされている。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/21e4dfb3-8923-643c-43c3-c2ce54aa7386.png)

:::note warn
6つのGRE Connectionのうち１つでも非接続状態の場合は、以下のような警告が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/b6ad412c-4d7f-ed12-fa24-bdeb1c3012f3.png)
:::


# 4. Transit Gatewayへの経路広告

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/5c32e225-11d7-679a-f9db-011caa7cf848.png)![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/24e5a026-f3a2-4f34-e0aa-f5702891d1bf.png)

VDCからの経路広告を実施するためには、[VDCにて経路広告の設定](https://docs.vmware.com/en/VMware-Cloud-Director/10.5/VMware-Cloud-Director-Tenant-Guide/GUID-6DEC4DF7-2168-4162-8BD1-42BCD555DBF9.html)を行う必要があります。

- Edge Gatewayにおける、`Routing` -> `Route Advertisement`に移動し、`EDIT`を押下。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/a292c441-df47-16bd-b4a7-c1e39b2a9bf2.png)
- 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の広告対象とする。 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/bb22ba24-4a49-5fbe-2ea6-df692ecc8b0b.png)
- 追加された。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/6d5367a6-4eab-4ef7-d283-2b1ae620b76d.png)
- Transit Gatewayにて経路情報レポートを生成すると、以下のように複数経路から`192.168.100.0/24`宛の経路が広告されていることがわかる。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/59cd4919-a716-6176-398b-8682b802370e.png)


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

# 5. VPCとの接続確認

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

## 5-1. Transit GatewayにVPCを追加。
東京リージョンにあるVPCをTransit Gatewayのconnectionに追加します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/bdb0b027-fc95-2f59-c11d-b7f49eda0a16.png)

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

今回は、RFC1918で定めるprivate network(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)をすべて許可しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/b4d5fdab-e466-675d-b4df-a36ab42c4ec4.png)

## 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`![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/f56e9850-3ccd-16a9-d105-55fe40d65cb5.png)
- 該当のsubnetを追加して`SAVE`![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/1baa0e4e-914e-29e5-e280-66a696a7ee07.png)
- 結果。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/0aff12a5-02f2-f4ea-ee02-8ab9cc4098ae.png)



## 5-4. Edge Firewallの設定
`VDC-> VPC`および`VPC -> VDC`の通信を許可するために、`RFC1918-private-network`から`RFC1918-private-network`への通信をすべて許可します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/aa955b92-1276-b122-6a45-01e0fdece9e5.png)


## 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が発生してはいけない**

というところが、ポイントです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/0636c17b-e2f4-a515-d0f7-a47612ebf195.png)




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

1. （今回のVPC上のVSIのnetworkは10.0.0.0/8上に存在するので、10.0.0.0/8宛の通信は`NO SNAT`にするようなNATを追加する。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/b99bfafb-cf26-38c7-0975-480e1f3b8272.png)
2. 既存のSNATルールについて、SNATルールの`Priority`を100に下げる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/3f25a38e-c8cb-d64c-69e9-2e9c92f197ea.png)
3. 確認![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/bf598985-aebe-e348-8a4f-9ff8a6f8c4e8.png)
4. とはいっても、このままでは本当に`Priority`値が正しく設定されているのかを一目で見れないので、左下のカラム編集ボタンを押下し、`Priority`を追加![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/37aacdbe-5041-50fa-32eb-68d458986746.png)
5.　最終確認。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/4fc16738-e768-1933-3c35-eb5044755120.png)


::: note
複数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間のすべての通信が可能になりました。

```txt: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
```
```txt: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
```
```txt: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
```
```txt: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
```