IBM Cloud: Transit VPCの構成例

# 1. はじめに
IBM Cloud VPCでTransit VPCを構成してみた。Transit VPCを利用することで、オンプレミスのユーザーは対象のVPCに直接接続するのではなく、中継のVPC（Transit VPC, Hub VPC, Landing Zone VPC, Edge VPCなど色々な呼ばれ方がある)を必ず経由し、そこで一旦セキュリティーチェックなどを実施してから転送される、といった構成が可能となる。今回はPower Systems Virtual Server(AIX)をオンプレミス相当と見做して接続を試行する（今回の例は単純化のためにALBなどは利用していない）。今回の構成では、NGFWとしてはPalo AltoやCheckPointのような途中経路でIPアドレスを変更しない透過型Firewallを想定している。

なお、以下のリンクが参考になる。
-  https://cloud.ibm.com/docs/vpc-journey?topic=vpc-journey-vpc-advanced-elements
-  https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-transit1
-  https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-transit2


# 2. VPC(Spoke)のVSIに接続する構成例

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/5dc1f2a4-5ad7-69e5-c174-78b09cb073aa.png)



## 2-1. 構成のポイント

1. on-premiseとTransit VPC(Hub)はDirect Linkで接続する。**その際に、Transit VPC(Hub)にはSpoke側のVPCを包括するようなaddress prefix(この例では`172.17.0.0/16`)を構成する。このaddress prefixにはsubnetを定義してはいけない。あくまでオンプレミスにSpoke宛の経路をBGP広告をするためのダミーのaddress prefixである**。これにより、例えば上図の`172.17.0.5`宛の経路は、Direct Link経由でオンプレミスに広告されるため、Transit VPC(Hub)にパケットは到達可能となる。
2. このSpoke宛のパケットは、Custom route table(Ingress)を使って、NGFWである`10.0.0.10`に転送する。
3. NGFWに到達したパケットは、セキュリティーチェックを実施した後、再度宛先である172.17.0.5への転送が行われる。パケットのsourceは`192.168.50.223`、destinationは`172.17.0.5`のままである。
    - 今回は、透過型ファイアウォールのNGFWに見立てて、`/proc/sys/net/ipv4/ip_forward`を1にしたLinuxサーバーを利用している。
    - NGFWが保持していないIPアドレスに対しての送受信が行われるので、`Allow IP Spoofing`を有効にする。
4. [IBM Cloud: Transit Gatewayに接続するVPC間で、prefixが重複している際の挙動](https://qiita.com/testnin2/items/5aa3e5313aa638613b7d)でも解説した通り、VPC間でaddress prefixが重複していても接続先のVSI側にあるVPCのaddress prefix長の方が短く、しかも接続対象のVSIのsubnetを接続元VPC側で保持していないのであれば、Prefix Filteringの設定なしでTransit Gateway経由で接続可能である。そのため、VPC2(Spoke)のVSI(172.17.0.5)にパケットは到達可能である。
5. 戻りのパケットもTransit VPC経由で返ってほしいため、オンプレミス宛のパケットはTransit VPCのNFGWを経由するようにVPC2(Spoke)側のCustom route table(Egress)で、next hopがNGFWになるように構成する。


## 2-2. 構成の画面キャプチャー（一部）

- Transit VPC(Hub VPC): NGFWにおけるIP Spoofingの構成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/8c563563-37cf-bd96-c68d-7a64e62b4b7f.png)

- Transit VPC(Hub VPC): NGFWにおけるIP Forwardingの構成
```txt:NGFWでIP Forwardingを有効にする（この設定は再起動したら無効になるが、今回はテストなのでこのように構成する）
[root@syasuda-ngfw-transit1 ~]# echo 1 > /proc/sys/net/ipv4/ip_forward
```
- Transit VPC(Hub VPC): Custom Route table(Ingress)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/37953629-66ab-3682-bc10-839b8a2ed998.png)

- Spoke VPC: Custom Route table(Egress)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/b70419be-658e-6145-7377-2155787ec60a.png)


## 2-3. 接続テスト

```txt:Power Systems Vitual Server(192.168.50.223)からのping
bash-4.3# ping 172.17.0.5
PING 172.17.0.5 (172.17.0.5): 56 data bytes
64 bytes from 172.17.0.5: icmp_seq=0 ttl=54 time=2 ms
64 bytes from 172.17.0.5: icmp_seq=1 ttl=54 time=2 ms
64 bytes from 172.17.0.5: icmp_seq=2 ttl=54 time=2 ms
64 bytes from 172.17.0.5: icmp_seq=3 ttl=54 time=2 ms
64 bytes from 172.17.0.5: icmp_seq=4 ttl=54 time=2 ms
64 bytes from 172.17.0.5: icmp_seq=5 ttl=54 time=2 ms
```

```txt:NGFW(10.0.0.10)でのtcpdump
[root@syasuda-ngfw-transit1 ~]# tcpdump -i any icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
02:15:20.369549 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 0, length 64
02:15:20.369575 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 0, length 64
02:15:20.370200 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 0, length 64
02:15:20.370205 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 0, length 64
02:15:21.369498 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 1, length 64
02:15:21.369521 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 1, length 64
02:15:21.370165 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 1, length 64
02:15:21.370169 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 1, length 64
02:15:22.369610 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 2, length 64
02:15:22.369635 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 2, length 64
02:15:22.370399 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 2, length 64
02:15:22.370403 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 2, length 64
02:15:23.369607 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 3, length 64
02:15:23.369630 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 3, length 64
02:15:23.370318 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 3, length 64
02:15:23.370323 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 3, length 64
02:15:24.369651 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 4, length 64
02:15:24.369674 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 4, length 64
02:15:24.370298 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 4, length 64
02:15:24.370303 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 4, length 64
02:15:25.369706 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 5, length 64
02:15:25.369729 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 5, length 64
02:15:25.370344 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 5, length 64
02:15:25.370349 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 5, length 64
```

```txt:接続先VSI(172.17.0.5)でのtcpdump
[root@syasuda-spoke-target1 ~]# tcpdump -i any icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
02:15:20.369793 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 0, length 64
02:15:20.369822 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 0, length 64
02:15:21.369756 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 1, length 64
02:15:21.369787 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 1, length 64
02:15:22.370027 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 2, length 64
02:15:22.370055 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 2, length 64
02:15:23.369946 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 3, length 64
02:15:23.369978 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 3, length 64
02:15:24.369924 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 4, length 64
02:15:24.369956 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 4, length 64
02:15:25.369963 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 5, length 64
02:15:25.369992 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 5, length 64
```

# 3. VPC(Spoke)のALB/NLBに接続する構成例
[docsでの例](https://cloud.ibm.com/docs/vpc-journey?topic=vpc-journey-vpc-advanced-elements)にあるように、以下のように構成することも可能。これは、オンプレミスから見た接続先VSIがALB/NLBに変わっただけなので、上記構成と本質的には構成は変わらない。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/470466e0-c733-6be9-eb38-476039f4fba5.png)



## 3-1. Spoke側にALBを配置する場合

ALBが`172.17.0.0/24`に配置されていれば、特に追加設定なしで通信可能。ALBのバックエンドサーバーがどのAZに配置されていても良い。

```txt:VPC(hub)でALB利用時のテスト結果
bash-4.3# curl http://xxxxxxxx-jp-tok.lb.appdomain.cloud
tokyo1-web1
bash-4.3# curl http://xxxxxxxx-jp-tok.lb.appdomain.cloud
tokyo2-web1
```

## 3-2. Spoke側にNLBを配置する場合

NLBが`172.17.0.0/24`に配置されていれば、そのバックエンドサーバーがどのAZに配置されていても、そのAZからのcustom route（egress)でのオンプレミス宛（`192.168.50.0/24`)へのnext hopがNGFW(`10.0.0.10`)に設定されていれば、通信可能（NLB はDirect Server Returnになることに注意）。

```txt:VPC(hub)でNLBのテスト結果
bash-4.3# curl http://172.17.0.8
tokyo1-web1
bash-4.3# curl http://172.17.0.8
tokyo2-web1
````

# 4. VPC(hub)におけるNGFWを冗長化した構成例

既存の構成では、NGFWがSingle Point of Failure(SPOF)になっているため、冗長化したい。そのためには、NFGWを2台配置し、NLB(route mode)を利用する。
以下に構成図を記載する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/53cb4d50-f2f6-b081-304c-6ffd6e2df29b.png)



## 4-1. 構成のポイント

- 単にNLBを利用すると、DNATが発生してしまうため、透過型Firewallとしての体をなさない。NLB(route mode)を利用することで、パケットの宛先・送信元を変更することなく、ActiveなNGFWに転送が可能である。
- NLB(route mode)の詳細については、[IBM Cloud: VPCで透過的ファイアーウォールを作る方法(2)](https://qiita.com/testnin2/items/d4897b3d292282a25aae)を参照のこと。
- on-premiseからのパケットはNGFWに転送するのではなく、NLB(route mode)に転送する必要がある。そのためVPC(hub)のIngress route tableにおける、`172.17.0.0/24`宛のパケットはNLB(route mode)をnext hopとしている。同様の理由で、VPC(spoke)においても、next hopはNLB(route mode)である。
- VPC(hub)のIngress route tableにも、新たにVPC(Spoke)のEgress route tableと全く同じ内容が追加されているのが特徴。これがなくても一見稼働するように見えるが、実はNLB(route mode)のメンテナンス時の挙動を考慮すると必要な設定である。
    - 普通のNLBはVIPが割り当てられているが、NLB(route mode)はActive/Standbyそれぞれに別のIPアドレスが割り当てられている。
    - NLB(route mode)を利用しているVPC内で、NLB(route mode)のActive側のIPアドレスをnext hopとするようなCustom Routeを構成した場合に、もしそのNLB(route mode)にメンテナンスが発生した場合はどうなるだろうか？実は、NLB(route mode)にメンテナンスが発生した場合は、新たにActiveとなる方のIPアドレスがnext hopになるように、既存のcustom routeが自動的に更新される仕組みになっている。 
     - よって、VPC(hub)側だけであればNLB(route mode)にメンテナンスが発生しても利用可能だが、このroute tableの更新はVPC(hub)のroute tableに対してのみしか行われないことに注意が必要である。つまり、VPC(spoke)側のroute tableは更新されないため、その手当てが別途必要になる。この設定をVPC(hub)のingress route tableに追加することにより、VPC(spoke)側のroute tableが更新されなくてもActiveなNLB(route mode)にパケットが転送されるようになる。



（参考1） https://cloud.ibm.com/docs/vpc?topic=vpc-config-custom-routes&locale=en 
> If the NLB fails over to the other node, the custom routes are automatically updated to hop to the new NLB IP address.

（参考2） https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-vnf&interface=ui&locale=en
> - NLB route mode has two IP addresses (Active/Standby).
> - NLB route mode is designed to be transparent. When a failover occurs, route mode updates all routing rules created under the same VPC with the next_hop of the Standby appliance IP. As a result, both IPs may be used during the lifetime of your NLB with route mode.
> - In the case of a Transit VPC configuration, you may want to deploy the NLB in vpc-hub and configure the egress route in vpc-spoke. This will force data back to the NLB with route mode in vpc-hub. Ensure that you also add the equivalent ingress rules of the vpc-spoke egress rules to vpc-hub so that the egress rules do not need to be changed. Once the traffic reaches vpc-hub, the ingress routing rule will overwrite the next_hop and send it to the primary appliance.



## 4-2. 構成の画面キャプチャー（一部）

- VPC(hub)のingress route table
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/c4ae88f4-a0ee-86d0-20ae-bed68e532775.png)

- VPC(spoke)のegress route table
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/43158d4a-8055-a823-ce80-40e401dbb16b.png)

- NLB(route mode)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/f0bfdf7e-86af-0414-b430-7178a5f0027e.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/5b473fb9-aeac-0486-cf7f-53764cb3f4d1.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/b7bbbcf0-44f9-ba1a-1453-08d033b4f3ed.png)

## 4-3. 接続テスト

```txt:Power Systems Vitual Server(192.168.50.223)からのテスト結果
bash-4.3# curl http://xxxxxxxx-jp-tok.lb.appdomain.cloud
tokyo1-web1
bash-4.3# curl http://xxxxxxxx-jp-tok.lb.appdomain.cloud
tokyo2-web1
```

```txt:VPC(hub)におけるNGFWでのtcpdump
[root@syasuda-ngfw-transit1 ~]# tcpdump -i any port 80 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
05:05:17.164404 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [S], seq 766707901, win 65535, options [mss 8960,nop,wscale 3,nop,nop,TS val 1720349635 ecr 0], length 0
05:05:17.164425 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [S], seq 766707901, win 65535, options [mss 8960,nop,wscale 3,nop,nop,TS val 1720349635 ecr 0], length 0
05:05:17.165161 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [S.], seq 3780808846, ack 766707902, win 31856, options [mss 1460,nop,nop,TS val 3321979038 ecr 1720349635,nop,wscale 9], length 0
05:05:17.165166 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [S.], seq 3780808846, ack 766707902, win 31856, options [mss 1460,nop,nop,TS val 3321979038 ecr 1720349635,nop,wscale 9], length 0
05:05:17.166748 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [.], ack 1, win 32761, options [nop,nop,TS val 1720349635 ecr 3321979038], length 0
05:05:17.166752 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [.], ack 1, win 32761, options [nop,nop,TS val 1720349635 ecr 3321979038], length 0
05:05:17.166759 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [P.], seq 1:99, ack 1, win 32761, options [nop,nop,TS val 1720349635 ecr 3321979038], length 98: HTTP: GET / HTTP/1.1
05:05:17.166761 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [P.], seq 1:99, ack 1, win 32761, options [nop,nop,TS val 1720349635 ecr 3321979038], length 98: HTTP: GET / HTTP/1.1
05:05:17.177312 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [P.], seq 1:273, ack 99, win 63, options [nop,nop,TS val 3321979050 ecr 1720349635], length 272: HTTP: HTTP/1.1 200 OK
05:05:17.177315 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [P.], seq 1:273, ack 99, win 63, options [nop,nop,TS val 3321979050 ecr 1720349635], length 272: HTTP: HTTP/1.1 200 OK
05:05:17.179074 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [F.], seq 99, ack 273, win 32761, options [nop,nop,TS val 1720349636 ecr 3321979050], length 0
05:05:17.179083 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [F.], seq 99, ack 273, win 32761, options [nop,nop,TS val 1720349636 ecr 3321979050], length 0
05:05:17.179713 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [F.], seq 273, ack 100, win 63, options [nop,nop,TS val 3321979053 ecr 1720349636], length 0
05:05:17.179717 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [F.], seq 273, ack 100, win 63, options [nop,nop,TS val 3321979053 ecr 1720349636], length 0
05:05:17.181143 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [.], ack 274, win 32761, options [nop,nop,TS val 1720349636 ecr 3321979053], length 0
05:05:17.181146 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [.], ack 274, win 32761, options [nop,nop,TS val 1720349636 ecr 3321979053], length 0
```


# 5. VPC(Spoke)のVPEに接続する構成例


- ここでは、VPC(Spoke)に存在するIBM Cloud Databases for PostgreSQLへの接続を試みてみる。VPEは、172.17.0.0/24内のIPアドレスを利用する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/e1185b4c-f4bc-2f9b-3a4d-c186925c68c8.png)
- どのようにVPC(Spoke)におけるFQDNをオンプレミス側から名前解決させるのかというDNS構成上の検討が別途必要なのだが、それは既に解決されているという前提とする。

```txt:上記構成前の接続試行。名前解決はできている。
[root@power-rhel8 ~]# ping xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxx.private.databases.appdomain.cloud
PING xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxx.private.databases.appdomain.cloud (172.17.0.10) 56(84) bytes of data.
^C
--- xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxx.private.databases.appdomain.cloud ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
```


## 5-1. 構成のポイント
特に上記4の構成から変更なく、以下のような構成でもアクセスできそうなものだが、実は接続できない。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/aa40e047-c124-6bc2-e7c8-8fe30eb2e821.png)



```txt:Power Systems Virutal Servers(192.168.50.224)からのPostgreSQL接続
[root@power-rhel8 ~]# PGPASSWORD=${PGPASSWORD} PGSSLROOTCERT=631b75c3-4296-4ce9-b0f2-426423c5b0e6 psql "host=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxx.private.databases.appdomain.cloud port=31269 dbname=ibmclouddb user=admin sslmode=verify-full"
（失敗）
```
```txt:NGFWでのパケットキャプチャー
[root@syasuda-ngfw-transit1 ~]# tcpdump -i any port 31269 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
00:21:03.574212 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606330792 ecr 0,nop,wscale 10], length 0
00:21:03.574238 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606330792 ecr 0,nop,wscale 10], length 0
00:21:04.635689 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606331854 ecr 0,nop,wscale 10], length 0
00:21:04.635710 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606331854 ecr 0,nop,wscale 10], length 0
00:21:06.715791 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606333934 ecr 0,nop,wscale 10], length 0
00:21:06.715813 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606333934 ecr 0,nop,wscale 10], length 0
```

上記のように、NGFWまではちゃんと届いており、VPEへの送信までは行われているが、返りのパケットがNGFWに届いていないことがわかる。実は、**VPEではegress route tableが使われないという制約が現時点で存在する**。そのため、戻りのパケットがVPC(hub)に返ってきていないのである。
暫定の回避策としては、on-premise(Power Systems Virtual Server)への経路がVPC(hub)に戻るようにVPC(hub)にオンプレミス用のダミーのaddress prefixを構成することである。しかし、この方法ではVPC(hub)のどれか1つのゾーンにしかパケットを戻せないという制約が残ることに注意。なお、VPC(hub)にさえパケットが戻ってこれば、その後はIngress route tableでNLB(route mode)に転送できる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/a8c77381-b171-4e6f-b496-a30360d86656.png)


## 5-2. 構成の画面キャプチャー（一部）

新規に追加したダミーのAddress Prefix
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/d6b22a29-abea-8511-c4de-c5e1d8a13e23.png)


## 5-3. 接続テスト

```txt:Power Systems Virutal ServersからのPostgreSQL接続
[root@power-rhel8 ~]# PGPASSWORD=${PGPASSWORD} PGSSLROOTCERT=631b75c3-4296-4ce9-b0f2-426423c5b0e6 psql "host=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxx.private.databases.appdomain.cloud port=31269 dbname=ibmclouddb user=admin sslmode=verify-full"
psql (12.12, server 12.11)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

ibmclouddb=>
```

```txt:NGFWでのパケットキャプチャー
[root@syasuda-ngfw-transit1 ~]# tcpdump -i any port 31269 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
00:57:02.382159 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [S], seq 4193277481, win 26880, options [mss 8960,sackOK,TS val 3608489600 ecr 0,nop,wscale 10], length 0
00:57:02.382185 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [S], seq 4193277481, win 26880, options [mss 8960,sackOK,TS val 3608489600 ecr 0,nop,wscale 10], length 0
00:57:02.400770 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [S.], seq 3058133977, ack 4193277482, win 65535, options [mss 1440,sackOK,TS val 4173787318 ecr 3608489600,nop,wscale 9], length 0
00:57:02.400790 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [S.], seq 3058133977, ack 4193277482, win 65535, options [mss 1440,sackOK,TS val 4173787318 ecr 3608489600,nop,wscale 9], length 0
00:57:02.402331 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 1, win 27, options [nop,nop,TS val 3608489620 ecr 4173787318], length 0
00:57:02.402336 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 1, win 27, options [nop,nop,TS val 3608489620 ecr 4173787318], length 0
00:57:02.407389 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 1:9, ack 1, win 27, options [nop,nop,TS val 3608489625 ecr 4173787318], length 8
00:57:02.407398 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 1:9, ack 1, win 27, options [nop,nop,TS val 3608489625 ecr 4173787318], length 8
00:57:02.412749 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [.], ack 9, win 128, options [nop,nop,TS val 4173787329 ecr 3608489625], length 0
00:57:02.412759 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [.], ack 9, win 128, options [nop,nop,TS val 4173787329 ecr 3608489625], length 0
00:57:02.412768 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 1:2, ack 9, win 128, options [nop,nop,TS val 4173787329 ecr 3608489625], length 1
00:57:02.412771 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 1:2, ack 9, win 128, options [nop,nop,TS val 4173787329 ecr 3608489625], length 1
00:57:02.414582 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 2, win 27, options [nop,nop,TS val 3608489632 ecr 4173787329], length 0
00:57:02.414591 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 2, win 27, options [nop,nop,TS val 3608489632 ecr 4173787329], length 0
00:57:02.417008 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 9:298, ack 2, win 27, options [nop,nop,TS val 3608489635 ecr 4173787329], length 289
00:57:02.417016 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 9:298, ack 2, win 27, options [nop,nop,TS val 3608489635 ecr 4173787329], length 289
00:57:02.420253 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 2:101, ack 298, win 131, options [nop,nop,TS val 4173787339 ecr 3608489635], length 99
00:57:02.420262 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 2:101, ack 298, win 131, options [nop,nop,TS val 4173787339 ecr 3608489635], length 99
00:57:02.422126 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 298:626, ack 101, win 27, options [nop,nop,TS val 3608489640 ecr 4173787339], length 328
00:57:02.422135 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 298:626, ack 101, win 27, options [nop,nop,TS val 3608489640 ecr 4173787339], length 328
00:57:02.433719 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 101:2928, ack 626, win 133, options [nop,nop,TS val 4173787352 ecr 3608489640], length 2827
00:57:02.433738 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 101:2928, ack 626, win 133, options [nop,nop,TS val 4173787352 ecr 3608489640], length 2827
00:57:02.435381 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 2928, win 32, options [nop,nop,TS val 3608489653 ecr 4173787352], length 0
00:57:02.435385 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 2928, win 32, options [nop,nop,TS val 3608489653 ecr 4173787352], length 0
00:57:02.435732 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 626:700, ack 2928, win 32, options [nop,nop,TS val 3608489654 ecr 4173787352], length 74
00:57:02.435735 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 626:700, ack 2928, win 32, options [nop,nop,TS val 3608489654 ecr 4173787352], length 74
00:57:02.435758 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 700:810, ack 2928, win 32, options [nop,nop,TS val 3608489654 ecr 4173787352], length 110
00:57:02.435759 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 700:810, ack 2928, win 32, options [nop,nop,TS val 3608489654 ecr 4173787352], length 110
00:57:02.442131 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 2928:3007, ack 810, win 133, options [nop,nop,TS val 4173787360 ecr 3608489654], length 79
00:57:02.442134 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 2928:3007, ack 810, win 133, options [nop,nop,TS val 4173787360 ecr 3608489654], length 79
00:57:02.442140 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3007:3086, ack 810, win 133, options [nop,nop,TS val 4173787361 ecr 3608489654], length 79
00:57:02.442142 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3007:3086, ack 810, win 133, options [nop,nop,TS val 4173787361 ecr 3608489654], length 79
00:57:02.443762 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 3086, win 32, options [nop,nop,TS val 3608489662 ecr 4173787360], length 0
00:57:02.443765 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 3086, win 32, options [nop,nop,TS val 3608489662 ecr 4173787360], length 0
00:57:02.445113 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3086:3121, ack 810, win 133, options [nop,nop,TS val 4173787363 ecr 3608489654], length 35
00:57:02.445120 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3086:3121, ack 810, win 133, options [nop,nop,TS val 4173787363 ecr 3608489654], length 35
00:57:02.446850 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 810:873, ack 3121, win 32, options [nop,nop,TS val 3608489665 ecr 4173787363], length 63
00:57:02.446858 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 810:873, ack 3121, win 32, options [nop,nop,TS val 3608489665 ecr 4173787363], length 63
00:57:02.451053 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3121:3468, ack 873, win 133, options [nop,nop,TS val 4173787370 ecr 3608489665], length 347
00:57:02.451061 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3121:3468, ack 873, win 133, options [nop,nop,TS val 4173787370 ecr 3608489665], length 347
00:57:02.495809 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 3468, win 35, options [nop,nop,TS val 3608489714 ecr 4173787370], length 0
00:57:02.495827 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 3468, win 35, options [nop,nop,TS val 3608489714 ecr 4173787370], length 0
```