1. はじめに
前稿までにRHELをプロビジョニングしていったんVDCへの通信が可能になったので、ここから少しずつ深掘りをしていきたいと思います。本稿では、この記事にて、
IBM Cloud private networkはVDC外部であるため、たとえIBM Cloud private networkへの通信であってもExternal IPを使ってSNATが必要になります。VDCにとって、外部接続用のIPアドレスとして認識されているIPアドレスは、IBM CloudポータルのVDC詳細画面に記載されていたIPアドレス範囲に限ります。
という記述を書いたので、その検証をしたいと思います。。
- 01. IBM Cloud: VMware as a Service（VMWaaS)の概要
- 02. IBM Cloud: VMware as a Service（VMWaaS) - VDCの注文
- 03. IBM Cloud: VMware as a Service（VMWaaS) - VDCの追加注文
- 04. IBM Cloud: VMware as a Service（VMWaaS) - 外部接続のためのネットワークとNAT/Firewallを構成する
- 05. IBM Cloud: VMware as a Service（VMWaaS) - RHELをプロビジョニングして疎通確認を行う
- 06. IBM Cloud: VMware as a Service（VMWaaS) - 検証: IBM Cloud private networkへの通信におけるSNATの必要性
- 07. IBM Cloud: VMware as a Service（VMWaaS) - 検証: isolated networkとの通信
- 08. IBM Cloud: VMware as a Service（VMWaaS) - 検証: routed network間の通信
- 09. IBM Cloud: VMware as a Service（VMWaaS) - Data Center Groupの構成
- 10. IBM Cloud: VMware as a Service（VMWaaS) - Distributed Firewallの構成
- 11. IBM Cloud: VMware as a Service（VMWaaS) - VDC間のVM/vApp Migration
- 12. IBM Cloud: VMware as a Service（VMWaaS) - VMWaaS APIの実行例
- 13. IBM Cloud: VMware as a Service（VMWaaS) - VMware Cloud Director OpenAPIの実行例
- 14. IBM Cloud: VMware as a Service（VMWaaS) - 検証: VIP切り替えによる高可用性構成の確認（手動切替）
- 15. IBM Cloud: VMware as a Service（VMWaaS) - 検証: VIP切り替えによる高可用性構成の確認（keepalived）
- 16. IBM Cloud: VMware as a Service（VMWaaS) - Transit Gateway接続
- 17. IBM Cloud: VMware as a Service（VMWaaS) - Veeam Backup and Replication service連携
2. ネットワーク設定の再掲
IBM Cloud: VMware as a Service（VMWaaS) - 外部接続のためのネットワークとNAT/Firewallを構成する で設定したネットワーク設定を再掲します。
- Network
| Name | Scope | Routed or Isolated | Distributed Routing | Gateway CIDR |
|---|---|---|---|---|
| nw1-routed-vdc01 | mt-vdc01 | Routed | Enabled | 192.168.100.1/24 |
- IP Sets
| IP Set name | Address range |
|---|---|
| IBM Cloud Private Network | 161.26.0.0/16, 166.8.0.0/14 |
| syasuda-homeaddress | 111.xx.xx.xx/24 |
- Edge Firewall
| rule | firewall rule name | protocol | source (IP Set等で指定） |
destination (IP Set等で指定） |
action |
|---|---|---|---|---|---|
| 1 | IBM Cloud Private Network | - | ANY | IBM Cloud Private Network | Allow |
| 2 | allow-from-syasuda | SSH | syasuda-homeaddress | ANY | Allow |
| default | default_rule | - | ANY | ANY | Drop |
- NAT
| NAT name | NAT Type | External IP (VDC外部との通信に利用するPublic IP) |
Internal IP (NATルールが適用されるVDC内のネットワーク） |
|---|---|---|---|
| snat-to-external | SNAT | 150.xx.xx.xx | 0.0.0.0/0 |
| dnat-to-jumpserver01 | DNAT | 150.xx.xx.yy | 192.168.100.2 （この後、プロビジョニングするサーバーに割り当てる予定のIPアドレス） |
3. 検証
元々、IBM Cloud Private Networkへの通信をする際には、IBM Cloud管理のProvider Gateway(T0)やその先のGatewayなどで暗黙的にMasquaradeが実施されるものだと私は思っていました。なのでユーザー側でわざわざEdge GatewayでSNATを構成する必要はないと思っていました。しかし、この考えは間違いであり、冒頭で述べたようにIBM Cloud Private Networkへの通信であってもSNATは必要です。
試しに、以下のようにSNATを無効にしてみます。
すると、jump serverにはSSHでログインできますが、IBM Cloud Private Networkへの接続はできなくなります。この結果は、明らかにSNAT設定時の結果と異なります。
[root@jumpserver ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 161.26.0.10
nameserver 161.26.0.11
[root@jumpserver ~]# ping 161.26.0.10
PING 161.26.0.10 (161.26.0.10) 56(84) bytes of data.
^C
--- 161.26.0.10 ping statistics ---
19 packets transmitted, 0 received, 100% packet loss, time 18411ms
[root@jumpserver ~]# dig s3.direct.jp-tok.cloud-object-storage.appdomain.cloud
; <<>> DiG 9.16.23-RH <<>> s3.direct.jp-tok.cloud-object-storage.appdomain.cloud
;; global options: +cmd
;; connection timed out; no servers could be reached
[root@jumpserver ~]# dig private.iam.cloud.ibm.com
; <<>> DiG 9.16.23-RH <<>> private.iam.cloud.ibm.com
;; global options: +cmd
;; connection timed out; no servers could be reached