FJcloud実践
拠点間VPNゲートウェイを冗長化する方法
インターネットVPNを利用するには、拠点側にVPNルーターを設置し、拠点間VPNゲートウェイを利用する方法が多くのパターンで利用されます。
前回の記事では、拠点側のみ冗長化しましたが、クラウド環境側を冗長化するにはどうしたらよいかを考えてみました。
検証の構成
今回も、実際の拠点を構築する代わりに、FJcloud-V上にすべての環境を構築しています。
ネットワーク構成などは、前回の記事を参照してください。
今回は、拠点間VPNゲートウェイ故障時の経路切り替えに、IPCOMのmonitor route機能を利用しています。
機能・サービスの紹介
- IPCOM VE2V
長年に渡り企業のネットワーク基盤を支えてきた製品をFJcloud-V基盤に対応させたもので、FJcloud-V上の仮想マシンに対して高度なネットワーク機能を提供します。 - 拠点間VPNゲートウェイ
FJcloud-V上の自社環境にセキュアに接続可能な、インターネットVPNサービスです。 FJcloud-Vをお客様の社内ネットワークの延長線上にあるシステムとしてご利用いただけます。
検証
事前準備
以下を用意します。
| 要素 | 個数 | 用途 |
|---|---|---|
| 拠点間VPNゲートウェイ | 2 | FJcloud-V側VPN終端装置 |
| カスタマーゲートウェイ | 2 | 疑似ユーザ拠点とつなぐための設定 |
| プライベートLAN | 4 | 疑似ユーザ拠点、疑似グローバル、FJcloud-V側システム*2 |
| IPCOM VE2V SC | 2 | 疑似ユーザ拠点側のVPN終端装置相当 |
| 標準ディスク 100G | 2 | IPCOMの設定保存用 |
| 追加NIC | 2 | IPCOMの疑似ユーザ拠点側ネットワーク接続用 |
構築
以下の構成を作成します。IPCOMの設定以外は前回の記事と同じため、割愛します。
IPCOMに設定を投入します。
IPCOMへ以下の設定を投入します。
ポイントは、一つのipsec ruleのなかで二つの拠点間VPNゲートウェイをピアとして登録します。プライマリ側
cluster mode primary hostname ipcom01 ipcom02 cluster id 10 cluster secret-key ipcomclusterkey interface lan0.0 ip address 10.0.1.100 255.255.0.0 ip address primary 10.0.1.101 ip address secondary 10.0.1.102 cluster sync-interface priority 1 cluster vrid 10 ! interface lan0.1 ip address 192.168.20.1 255.255.255.0 ip address primary 192.168.20.2 ip address secondary 192.168.20.3 cluster sync-interface priority 2 cluster vrid 20 ip-ruting ! access-control default-accept class-map match-all ipsec match source-address ipv4 192.168.20.0/24 match destination-address ipv4 192.168.10.0/24 ! !----------------- ipsec option ping-reply-same-tunnel all ! !-------------- ike rule 10 set-peer ipv4 10.0.1.110 interface lan0.0 dpd-keep-alive idleonly ike-restart enable policy 10 authentication pre-share hash hmac-sha1 encryption aes128 lifetime time 8 hour group 2 ! ! ike rule 20 set-peer ipv4 10.0.1.111 interface lan0.0 dpd-keep-alive idleonly ike-restart enable policy 10 authentication pre-share hash hmac-sha1 encryption aes128 lifetime time 8 hour group 2 ! ! !----------------------- ipsec rule 100 set-peer ipv4 10.0.1.110 interface lan0.0 priority 1 set-peer ipv4 10.0.1.111 interface lan0.0 priority 2 class-map ipsec set-transform esp-hmac-sha1-aes128 set-pfs group2 lifetime time 1 hour ! !----------------------- ike pre-shared-key ipv4 10.0.1.110 key abcdefg ike pre-shared-key ipv4 10.0.1.111 key abcdefg commit- セカンダリ側
cluster mode secondary hostname ipcom01 ipcom02 cluster id 10 cluster secret-key ipcomclusterkey interface lan0.0 ip address 10.0.1.100 255.255.0.0 ip address primary 10.0.1.101 ip address secondary 10.0.1.102 cluster sync-interface priority 1 cluster vrid 10 ! interface lan0.1 ip address 192.168.20.1 255.255.255.0 ip address primary 192.168.20.2 ip address secondary 192.168.20.3 cluster sync-interface priority 2 cluster vrid 20 ip-ruting ! commit
- IPCOMの再起動
クラスタの設定を入れると、IPCOMは再起動が要求されます。
指示に従って再起動してください。 - VPNの接続確認
コントロールパネルより、無事VPNセッションが貼られたことを確認します。
これで構築作業は完了です。
動作確認
拠点間VPNゲートウェイの障害と、IPCOMの障害。二つのテストを実施します。
拠点間VPNゲートウェイの障害試験
障害発生後、利用する拠点間VPNゲートウェイが切り替わるか確認します。
本構成では、通信が通過する拠点間VPNゲートウェイが変更されるため、切り替わった後はサーバー側のルーティングに変更を加えないと通信が復帰しません。
今回は、pingターゲットサーバーにてtcpdumpを実行し、拠点間VPNゲートウェイが切り替わった後にどのぐらいの時間でパケットが届き始めるかを確認します。
- 通信を発生させるために、OfficeNetとCloudNetにサーバーを作成します。
通信テストのため、２台の間でpingが通過できるようにファイアウォールを設定します。 pingを連続で送信する。
OfficeNet側のサーバーから、CloudNet側のサーバーへpingを送信します。# ping 192.168.10.100 | gawk '{print strftime("%F %T ") $0}{fflush() }'
- CloudNet側のサーバーでtcpdumpを実行し、パケットの到着を確認します。
# tcpdump -i ens192 icmp - 拠点間VPNゲートウェイ1に、inルールにルールがないファイアウォールを設定し、疑似的な故障を再現します。
- 60秒程度でpingパケットの到着が再開されました。
左：CloudNet側のサーバー
右：OfficeNet側のサーバー
IPCOMの障害試験
障害発生後、拠点間VPNゲートウェイへのセッションが問題なく維持されるかを確認します。
今回の試験は、拠点間VPNゲートウェイの切り替えが起きないため、通信は維持されます。
- 通信を発生させるために、OfficeNetとCloudNetにサーバーを作成し、OfficeNet側のサーバーから、CloudNet側のサーバーへpingを送信します。
方法は、「拠点間VPNゲートウェイの障害試験」1) 2)に準じます。 IPCOM#1にて、「switch cluster stanby」を実行し、クラスタを切り替えます。
# switch cluster standby Do you switch the peer system to active state? (y![n]):y This system changed from the active state to the standby state.
- 30秒程度で通信の再開を確認できました。
まとめ
IPCOMから複数の拠点間VPNゲートウェイへ同時にセッションを張り、monitor routeによる経路切り替えを活用し、単体の拠点間VPNゲートウェイの障害に対処できました。
他の機器でも、同様の機能があれば本構成をとることが可能です。
しかし、本構成では拠点間VPNゲートウェイの障害時にサーバーのゲートウェイ切り替えを合わせて実施するまで、すべての通信は復旧しません。
本構成を本番で利用するには、サーバー上で拠点間VPNゲートウェイの障害を検知し、自動的にゲートウェイIPを変更する仕組み作りが必要です。
ただし、拠点間VPNゲートウェイは、物理サーバー障害による再起動が発生しても5分程度で起動してきます。 万が一機器障害が発生しても再作成が10分程度で完了することを踏まえると、本検証構成をとることの意味合いは薄いでしょう。
注意事項
- 本記事は、実現性の確認を目的としています。実際に利用する場合は実作業前にお客様にて検証および動作確認を実施し、問題なく移行できるか確認してください。
特に、今回は実機ではなく仮想インスタンスを利用しています。予期せぬ差分がある可能性を踏まえ十分に確認してください。 - 本記事の掲載時点の情報になります。最新の情報は各サービスのサービスページ、技術仕様ページを参照してください。
- 本記事に記載されている会社名、製品名等の固有名詞は各社の商号、登録商標または商標です。
- 本記事の他社サイトへのリンクにつきまして、リンク切れの際はご容赦ください。
