オンプレミスからVPCのsite-to-site VPN経由でPowerVSに接続する（NAT不要）

:::note info
2024年5月追記
VPCに新機能が追加され、VPCにオンプレミス側ネットワークのprefixを作らなくても、PowerVSにオンプレミス側ネットワークへの経路情報を広告できるようになりました。当ページの方法でも問題ありませんが、今後はこちらの新機能を使ったほうが容易に構成できると思います。
https://qiita.com/y_tama/items/d772901c17528c1e9c43
:::

# はじめに
~~Power Systems Virtual Server（以下PowerVS）にはVPNaaSがありますが、下記に記載されているように、いくつか制約があります。
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-VPN-connections~~
追記：PowerVSのVPNaaSはdeprecationが発表されました。

今回は、PowerVSのVPNaaSではなく、VPCで使える[site-to-site VPN](https://cloud.ibm.com/docs/vpc?topic=vpc-using-vpn)を使って、PowerVSにアクセスする方法を考えたいと思います。
VPC側に仮想サーバーを立ててNATを行う方法は下記に書きましたが、今回はNAT無しでアクセスする方法です。
https://qiita.com/y_tama/items/1689f2500f43c89af713

最初にポイントを書くと下記となります。
- 特別なこと（今回の記事に書く内容）を考えずに構成すると、PowerVSはオンプレミスのIPアドレス範囲へのルーティング情報を知らないのでPowerVSからオンプレミスにパケットを送ることはできない。　
- 今回の設定の肝になる設定として、VPCのprefixとしてオンプレミスのIPアドレス範囲を定義する。この定義により、オンプレミスのIP範囲へのルーティング情報がVPCとPowerVS間のCloud Connections（Direct Link 2.0）経由でPowerVS側に広告され、PowerVSがオンプレミスのIP範囲へのパケットをVPCに送ることができるようになる。
- PowerVSからVPCに届いたパケット（宛先はオンプレミスのIP）がVPN Gatewayにルーティングされるよう、VPCのingress routing tableに定義する。
- VPN GatewayはVPNトンネル経由でオンプレミスにパケットを渡し、end-to-endで通信が可能となる。

:::note info
2024年1月追記
下記Docsに、この記事と同じ考え方を用いた接続構成が載っています。
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-VPN-connections#vpc-vpn
:::

概要イメージは下記となります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59627/d149854d-4025-80e8-bd32-13d97f4aaf72.png)

# オンプレミスとVPCをsite-to-site VPNで接続
オンプレミスとVPCをsite-to-site VPNで接続します。留意点として、policy based VPNで接続してください。

:::note info
route based VPNだと今回の構成はうまく動きません。
:::

Local IBM CIDRsには、VPCのサブネットでなく、PowerVSのサブネットを指定します。
Peer CIDRsは普通にオンプレミスのサブネットを書けばOKです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59627/bb64a4ad-7716-0fbc-bd61-906c36d59764.png)

なお、対向となるオンプレミスのVPNルータでも、Peer CIDRにはVPCのサブネットでなく、PowerVSのサブネットを指定してください。

# PowerVSでCloud Connectionsを作成
PowerVSでCloud Connections（Direct Link 2.0）を作成します。今回は、Transit Gatewayタイプで作成します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59627/56bf040d-358a-b82c-027e-8b662fd6119b.png)

PowerVSのLPARでパブリックIPアドレスを有効にしていると、デフォルトゲートウェイがパブリック側を向いています。オンプレミス宛の通信がプライベート側ゲートウェイにルーティングされるようAIXに静的経路を設定します。

```
# netstat -r
Routing tables
Destination        Gateway           Flags   Refs     Use  If   Exp  Groups

Route tree for Protocol Family 2 (Internet):
default            192.168.179.25    UG        6   6207270 en0      -      -   
10.50.50/24        172.16.42.1       UGS       0      1184 en1      -      -   
127/8              localhost         U         4    945769 lo0      -      -   
...
```

# PowerVSからのDirect Link 2.0をTransit Gatewayに接続

上記で作成したPowerVSからのDirect Link 2.0をTransit Gatewayに接続します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59627/2958f204-106f-6c55-20b2-853b4eb7740e.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59627/afba4384-1ab1-7dfc-0cb9-02d92c419944.png)


# VPCのprefixとしてオンプレミスのIP範囲を定義
これが今回の肝になります。
この定義により、オンプレミスのIP範囲へのルーティング情報が、VPCとPowerVS間のCloud Connections（Direct Link 2.0）経由でPowerVS側に広告され、PowerVSがオンプレミスのIPアドレス範囲へのパケットをVPCに送ることが可能になります。
今回は10.50.50.0/24がオンプレミスのIPアドレス範囲なので、それをVPCのprefixに定義します。（10.50.50.0/24に対応するサブネットをVPC内に作る必要はありません。）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59627/ca3185a8-84e5-6344-9097-f0d4688388a3.png)


# Transit GatewayにVPCを接続

Transit GatewayにVPCを接続します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59627/26a58549-ebce-3369-147f-e8e4e75dd8a5.png)

ルートを確認すると、PowerVSからと、VPCから、経路情報が広告されていることが確認できます。
VPCでオンプレミスのIPアドレス範囲（今回は10.50.50.0/24）をprefixとして定義したので、その経路情報もVPCから広告されています。これがPowerVSに伝搬されるため、PowerVSから送られる10.50.50.0/24宛のパケットはVPCに届くようになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59627/d2003945-ebf8-4bb6-6905-d959258404a3.png)

# VPCのingress routing tableを定義
次に、PowerVSからVPCに届いたオンプレミス（今回は10.50.50.0/24）宛のパケットがVPNトンネルに送られるよう定義を行います。

VPCにIngress route tableが無い場合、作成します。
`Accepts routes from`でVPN gatewayを選択し、VPN Gatewayで設定した経路情報が自動的にroute tableに反映されるようにします。
今回の構成では、`Traffic source`にはTransit Gatewayを選択します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59627/4b5a6c33-32e1-e634-0336-cc81a9680c67.png)

route tableが作成され、VPN gatewayから経路情報が伝搬されます。
VPN設定でPeer CIDRとして設定した10.50.50.0/24宛のパケットについて、next hopが、VPN GatewayのIPアドレス（10.40.40.4）になっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59627/b80b03c8-80bd-63e9-51b2-4e1a7f7c6697.png)


VPN Gatewayまでパケットが届けば、VPN Gatewayはその先のオンプレミスまでのルートを知っていますので、VPNトンネルを通してオンプレミスにパケットを届けることができます。

これで、オンプレミスからPowerVSまでの通信が可能となります。

下記はオンプレミスのサーバー（10.50.50.6）からPowerVSのAIX（172.16.42.123）へのpingです。

```
[root@tamavsi01 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:00:06:11:ef:41 brd ff:ff:ff:ff:ff:ff
    inet 10.50.50.6/26 brd 10.50.50.63 scope global noprefixroute dynamic eth0
       valid_lft 235sec preferred_lft 235sec
    inet6 fe80::6ff:fe11:ef41/64 scope link 
       valid_lft forever preferred_lft forever
[root@tamavsi01 ~]# ping 172.16.42.123
PING 172.16.42.123 (172.16.42.123) 56(84) bytes of data.
64 bytes from 172.16.42.123: icmp_seq=1 ttl=241 time=143 ms
64 bytes from 172.16.42.123: icmp_seq=2 ttl=241 time=155 ms
64 bytes from 172.16.42.123: icmp_seq=3 ttl=241 time=146 ms
64 bytes from 172.16.42.123: icmp_seq=4 ttl=241 time=143 ms
^C
--- 172.16.42.123 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 143.775/147.450/155.514/4.778 ms
[root@tamavsi01 ~]# 
```

以上