オンプレからVPN経由でPower Systems Virtual Serverへの通信を行う


2021/11/30追記

Power VSに対するIPSec接続は、下記のVPNaaSも利用可能になっていますので、併せてご検討ください。
https://qiita.com/y_tama/items/5e0ff7f50731d88a1c04

はじめに

オンプレミスからPower Systems Virtual Serverに通信するための構成です。
実現したいのは図の赤い矢印の通信で、オンプレミスの10.132.222.86から、IBM Cloud上のAIX 192.168.150.195の通信です。なお、当記事の目的は、どのような構成要素があるかと、利用者が何をする必要があるかの整理となっており、冗長化は考慮していません。本番環境で構成する際は、適宜、冗長化も検討ください。また、実装時に参考になるようなるべく具体的な設定内容も載せますが、各種パラメータが最適な値とは限らない点はご了承ください。
case対応はそれほど長時間待つ事なく処理されましたが、Advanced SupportのSeverity 3で起票したためかもしれません。サポートレベルにより、待ち時間が変わる可能性があります。

オンプレミスのサーバーからIBM Cloud上のAIXまでの通信は、ネットワークの観点で、下記3つの構成要素から成り立っています。それぞれ解説します。

  1. オンプレミスのルータとIBM Cloud上のVRAの間のIPSec
  2. x86 NetworkとPower Network間のDirect Link Connect
  3. 項目2のDirect Link Connect上に張ったGREトンネル

1. オンプレミスのルータとIBM Cloud上のVRAの間のIPSec

一般的なIPSecです。
今回は、IBM Cloudの別アカウントを疑似的なオンプレミス環境として使いました(図の左側)。その中に、vyosを立て、図の右側のアカウントにあるVRAとの間にIPSecを貼っています。

例えば、下記のように設定します。

VRA
set security vpn ipsec esp-group ESP1 lifetime 3600
set security vpn ipsec esp-group ESP1 proposal 1 encryption aes256
set security vpn ipsec esp-group ESP1 proposal 1 hash sha1
set security vpn ipsec ike-group IKE1 lifetime 28800
set security vpn ipsec ike-group IKE1 proposal 1 dh-group 2
set security vpn ipsec ike-group IKE1 proposal 1 encryption aes256
set security vpn ipsec ike-group IKE1 proposal 1 hash sha1
set security vpn ipsec site-to-site peer 169.56.x.x authentication pre-shared-secret '********'
set security vpn ipsec site-to-site peer 169.56.x.x default-esp-group ESP1
set security vpn ipsec site-to-site peer 169.56.x.x ike-group IKE1
set security vpn ipsec site-to-site peer 169.56.x.x local-address 161.202.x.x
set security vpn ipsec site-to-site peer 169.56.x.x tunnel 1 local prefix 192.168.150.0/24
set security vpn ipsec site-to-site peer 169.56.x.x tunnel 1 remote prefix 10.132.222.64/26
vyos
set vpn ipsec esp-group ESP1 lifetime '3600'
set vpn ipsec esp-group ESP1 proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP1 proposal 1 hash 'sha1'
set vpn ipsec ike-group IKE1 lifetime '28800'
set vpn ipsec ike-group IKE1 proposal 1 dh-group '2'
set vpn ipsec ike-group IKE1 proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE1 proposal 1 hash 'sha1'
set vpn ipsec ipsec-interfaces interface 'eth1'
set vpn ipsec site-to-site peer 161.202.x.x authentication pre-shared-secret '********'
set vpn ipsec site-to-site peer 161.202.x.x default-esp-group 'ESP1'
set vpn ipsec site-to-site peer 161.202.x.x ike-group 'IKE1'
set vpn ipsec site-to-site peer 161.202.x.x local-address '169.56.x.x'
set vpn ipsec site-to-site peer 161.202.x.x tunnel 1 local prefix '10.132.222.64/26'
set vpn ipsec site-to-site peer 161.202.x.x tunnel 1 remote prefix '192.168.150.0/24'

2. x86 NetworkとPower Network間のDirect Link Connect

下記を参考に、Direct Link Connect 2.0をオーダーします。x86とPower VS間のDirect Linkは、1DCあたり2本までは無償です。
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-ordering-direct-link-connect#help

Direct Link 2.0は自動払い出しなので、すぐにパラメータが確認できます。
caseを起票してこの情報をPower VSのチームに連携すると、Power側のルータを設定してくれます。

Use CIDRがPower VS側、IBM CIDRがx86 IaaS側です。

その際は、上記キャプチャにある情報と、docsの手順11で指示された情報に加え、AIXのVLAN番号も伝えます。(Power VSの各サーバーのプロパティページで確認可能)

人間系のやり取りなので、こちらもタイムリーにcaseを確認し、追加情報を求められた時は対応する必要がありますが、スムーズに進めば1日あればx86とPowerの間が疎通すると思います。(Advanced SupportのSeverity 3で起票しました)

また、今回はPower VSからDirect Linkを介してClassicネットワークと接続したいので、Classicへの仮想接続を追加します。

また、VRAに対し、AIXのサブネットへの通信はBCRに渡すよう静的経路を設定します。(※疎通確認のため設定しますが、GRE経由にするので、後ほど書き換えます)

VRA
set protocols static route 192.168.150.0/24 next-hop 10.132.163.193

AIX側にも、10.x.x.xへの通信は自分がいるサブネットのゲートウェイに渡すよう静的経路を設定します。

AIX
10/8               192.168.150.1     UGS       0     17013 en1      -      -

これにより、VRAとAIXの間が疎通します。

3. 項目2のDirect Link Connect上に張ったGREトンネル

ここまでの設定で、オンプレからIPSecを通ってVRAに来て、さらにDirect Link Connectを通りAIXまでパケットが到達する状態になっています。しかし、今は戻りの通信が戻れないため、オンプレからAIXへのpingなどでの疎通は確認できません。戻れない理由は、オンプレから来たパケットは送信元IPがオンプレのIPになっていますが、Power側のルータはオンプレのセグメントへの経路情報を持っていないためです。

戻りのパケットが戻れるようにするためには、オンプレから来たパケットを、VRAでSource NATしてAIXに渡すか、VRAとPower間でGREを張ってGRE経由でパケットをやり取りするか、いずれかの対処が必要となります。今回はGREを張る方法で実現します。
GREの依頼については下記Docsに情報があります。
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-configuring-power#gre-tunneling

DocsにはPower側のGRE終端のアドレスとして、「GRE Tunnel source (Power VS) IP」の項目がありますが、分からなかったので空欄で出したらPower側で指定してくれました(最初の図の172.16.0.37。このIPとVRAの間でGREを張ります)。デフォルトだとVRAから172.16はルーティングされないかもしれないので、その場合はこのIPに対する静的経路をBCRに向けてください。
下記のようなcaseを起票しました。

  • Customer NameとAccount IDは、下記で確認できます。
    https://cloud.ibm.com/account/settings

  • GRE Tunnel interfaceのIPは、GREトンネル内だけで使われる設定項目なので、任意に指定できます。他とかぶっていない172.16台にしました。

  • Private Network IDは、Power側ルータの設定として、どのセグメントへの通信はGREトンネルを通してVRAに渡すか?という項目です。オンプレのセグメントへのパケットをGREトンネル越しにVRAに渡したいので、「Private Network ID (1): 10.132.222.64/26」を指定しています。

  • case起票後、どのデータセンターのPower VSか確認されたので、起票時に書いておくとcaseを1往復節約できると思います(今回の場合はTOK04)。

case起票
Hello,
I'm refferring this docs.
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-configuring-power#gre-tunneling

Could you configure the Power VS side for the GRE tunnel?
I'm not sure "GRE Tunnel source (Power VS) IP".  Where can I find this IP address?

Customer name: xxxxxx
Customer account ID: xxxxxxxxxxxx
GRE Tunnel source (Power VS) IP: ??????
GRE Tunnel destination (IBM Cloud VRA) IP: 10.132.163.242
GRE Tunnel interface (Power VS) IP: 172.16.100.6/30
GRE Tunnel interface (IBM Cloud VRA) IP: 172.16.100.5/30
Private Networks to be routed over GRE:
Private Network ID (1): 10.132.222.64/26

Thanks,

caseを起票すると、半日程度でPower側の設定をしてくれました。(Advanced SupportのSeverity 3で起票しました)
VRA側でもGREの設定をします。172.16.0.37が、caseで教えてもらったPower側のGRE終端です。(デフォルトだとVRAから172.16はルーティングされないので、このIPに対する静的経路をBCRに向けてください)

VRA
set protocols static route 172.16.0.37/32 next-hop 10.132.163.193

set interfaces tunnel tun0 address 172.16.100.5/30
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 local-ip 10.132.163.242
set interfaces tunnel tun0 remote-ip 172.16.0.37

さらに、先ほどはBCRに向けていたAIX宛の通信をGREを通るように変更します。(一旦先ほどのを消します)

VRA
delete protocols static route 192.168.150.0/24
set protocols static route 192.168.150.0/24 next-hop 172.16.100.6

以上で、Power側からオンプレのセグメントへもGRE越し・VRA経由でパケットを戻せるようになるので、end to endで疎通するようになります。

以上です。