NEC IX 2015で IPsec通信 (VPNトンネル) がすぐに切れてしまう件

実は最近、友人と IPsecを使用したVPNトンネルを友人宅と接続して、CIFSでファイル共有したりしているのだけど、かなりの頻度でブチブチとトンネルが切れていて、どうしてなんだろうといろいろとIPsecについて調べていた。今回、なんとか原因がわかったので備忘録もかねて公表したいと思います。

ここでの原因判明は、NECの IXシリーズに共通することです。ほかのネットワーク機器メーカーでは当てはまらない場合があります。あらかじめ、ご注意ください。

いきなり結論を書こうとしたんだけど、かなり頭がこんがらがっちゃうので一般的な知識として IPsecの通信がどのように行われているのかを簡単に書くことにする。

IPsec SAと IKE SA

IPsecはプロトコルやポート番号などによって複数の暗号化方式や暗号鍵、セキュリティプロトコルを使用することができる。この際、実際に通信で使用され双方で共有するパラメータを SA (Security Association) と言い、このSAには IPsec SAと IKE SAの2つがある。それぞれのSAには寿命があり、寿命が尽きる前に鍵を更新する必要がある。

またそれぞれのSAは使用されるフェースが異なり、それぞれにフェーズ1，フェーズ2を経て、通信が行われる。
以下に各フェーズで行われることを自分なりにまとめてみた。

フェーズ1 : IKE SA

1. IKEプロトコル同士の認証と暗号交換を行う。（ISAKMP SA交換）
2. この際に使用するプロトコルとポートがUDP 500番。
3. あらかじめ用意した pre-shared keyを使用して相手を認証する。
4. あらかじめ用意した暗号化方式 (3DESなどでパケットを暗号化する。
5. そしてそのパケットの改ざん検知にハッシュ(MD5など)を使用する。

フェーズ2 : Ipsec SA

1. IPsecSAを確立するために鍵の交換を行う。（IPsec SA交換）
2. この際も使用するプロトコルとポートは UDP 500番。
3. IPsec SAの鍵として使う乱数をInitiatorが送信する。
4. それを受け取ったResponderがAckを返し、InitiatorがAckを返すと、鍵の承認が終了。
5. パラメータ(SA更新間隔など)の交換。暗号化方式、ハッシュ方式、AH/ESP、TP/TNモードの決定が行われる。
6. IPsec SAが確立される。ここまでに作成したIPsec SAを使って、実際の暗号化通信が行われる。

IPsec SAと IKE SAの寿命(更新サイクル)

フェーズ2での処理で重要なものに、鍵の有効期限の更新がある。キュリティ上、同じ鍵を使い続けるのはパスワードを変えずに使い続けるのと同じ事で、ましてやインターネット上にトンネルを貼るわけだから、非常にリスクが高い。

そこでIPsecでは ReKey と呼ばれる処理を行なって、暗号鍵を自動的に更新する。キーの有効期限は、IPsec SAを確立してからの経過時間で設定でき、これを超える前に新たなIPsec SAが確立される。

それぞれに時間が決まっており、これはメーカーによって異なる。NEC IXの場合、

• IPsec SAは60秒
• IKE SAは30秒

になっている。
(普通はもっと長いような気がしますが・・・。）

IXで IPsec通信を行う上での問題点（というか仕様）

これ、本当にまいった。通常 IPsec SAと IKE SAではそれぞれにライフタイムがあって、通常であればこのライフタイム終了前に自動的に更新が行われ、ユーザーは継続してセキュアな通信を行うことができる。

ところが、NEC IXの場合、IPsec SAが生成されてからトンネル上でパケットが流れていない場合、前述の IPsec SAの更新をしないという仕様になっているため、60秒以上なにもパケットが流れない無通信状態が続くと、IPsecの通信が行われなくなり、結果としてVPNトンネルがダウンしてしまう。

何度か友人と試していて、頻繁にVPNが途切れてしまうので、何が悪いんだろうと設定事例集などを読み直しても何も書いていない。ほとほとまいってNECのサイトを見たら “Q.1-11 IPSec SAが常に存在する状態に維持したいのですが、方法は有りますか？” というのがあって、これだ！と思い投入してみたらビンゴ！ 以下の設定を投入したら、全然切れなくなりました。

IPsec SAを消失させない方法

この機能を使うにはネットワークモニタを使用する。あらかじめ、接続先ピアのIPアドレスを調べておくことが必要になるので注意。うちの場合だと、友人のIXのトンネルインターフェイスのアドレス 172.16.0.254 を設定している。従って、enable-config に入って、

watch-group host 10

ウォッチグループ(host)を作成します。

event 10 ip unreach-host 172.16.0.254 Tunnel0.0 source FastEthernet0/1.0

ホスト監視の宛先、出力インタフェース、送信元インタフェースを設定します。

probe-timer restorer 60

robe-timer variance 60

ホスト監視の監視周期を設定します(デフォルトは5秒)。

network-monitor host enable

ネットワークモニタ機能を有効にします。

で設定完了。

通信が正常に行えていなかったりする場合、show tunnel status というコマンドを使うけれど、各SAレベルでトラブルシューティングしたい、という場合には以下のコマンドを使用する。

フェーズ１ : show ike sa

Router(config)# show ike sa
ISAKMP SA - 1 configured, 1 created　←コンフィグ作成数/IKE SA生成数
Local address: 10.0.0.2　←トンネル始点アドレス（出力インタフェースアドレス）
Peer address: 10.0.0.1　←トンネル終端アドレス（ピアアドレス）
IKE policy name is ike-policy　←IKEポリシー名
Direction: Initiator　←ネゴシエーション開始側/受信側
Exchange type: Main mode　←モード：メイン/アグレッシブ
Auth method: pre-shared　←認証方式：事前共有鍵
Enc algorithm is 3des　←暗号アルゴリズム
Hash algorithm is sha1　←認証アルゴリズム
DH group modp768, Life time is 28795 seconds　←DHグループ、ライフタイム
State: establish　←ネゴシエーションの統計情報
#ph1 success: 1, #ph1 failure: 0
#ph1 hash err: 0, #ph1 timeout: 0, #ph1 resend: 0
#ph2 success: 1, #ph2 failure: 0
#ph2 hash err: 0, #ph2 timeout: 0, #ph2 resend: 0

フェーズ２ : show ipsec sa

Router(config)# show ipsec sa
IPSec SA - 1 configured, 2 created　←コンフィグ作成数/IPSec SA生成数
Interface is Tunnel0.0 ←トンネルインタフェース名
Key policy map name is ipsec-policy　←IPSecポリシー名
IPSec mode: Tunnel (4-over-4)　←トンネルモード
Local address: 10.0.0.2　←トンネル始点アドレス（出力インタフェースアドレス）
Remote address: 10.0.0.1　←トンネル終端アドレス（ピアアドレス）
Outgoing interface: FastEthernet0/1.0　←出力インタフェース
Interface MTU: 1446, Path MTU: 1500　←トンネルMTU
Key type: Autokey　←SA生成方式（手動/自動）
Inbound
ESP SPI: 0xd7b5139d(3618968477)　←受信用SPI（SA識別番号）
Transform: ESP-3DES-HMAC-SHA-96　←暗号/認証アルゴリズム
Remaining key lifetime is 3592 seconds　←ライフタイム
Replay detection support: Y　←アンチリプレイ機能の起動/停止
Outbound
ESP SPI: 0xbd4d7590(3175970192)　←送信用SPI（SA識別番号）
Transform: ESP-3DES-HMAC-SHA-96
Remaining key lifetime is 3592 seconds
Replay detection support: Y
PFS: OFF　←PFSの使用ON/OFF

今回ご紹介したコマンド投入後の観察

昨日から Expingを使ってずーっと pingバッチを流しているけど、全く切れていない スクリーンキャプチャは以下。（インターネットのゆらぎも考慮して、ring server プロジェクトにも pingを打っています。）　また一歩前進したぜ。

[View with PicLens]

 

参考にさせていただいたリンク

IPsec – Wikipedia

IX2000/IX3000シリーズ FAQ

NEC IX 2015 初期設定 その8 ホスト監視による冗長構成を構築する (ネットワークモニタとVRRP)

初めてこのページをごらんになった方や、PPPoEなどの基本的な設定はページ下部の関連記事や、サイト上部からサイトマップを見てください。

以前回線を止められましたという記事を書いたけど、そのときに簡単に説明していた回線の冗長化と、その回線が断になった際に自動でWANを切り替えているIXの設定をここで説明したい。

前提条件と簡単な説明

あらかじめIXに以下の設定をしていることが動作の条件になる。

• FE0/0.0をLAN側の設定とすること。
• FE0/1.1をWAN(PPPoE)の設定とすること。
• 前述を前提に、WAN(PPPoE)が正常に構成されていること。
• LANにNAPTが構成されており、クライアントPCからネットが閲覧できること。
• 以上をクリアしたIXが2台以上あること。

できてない、という場合は、ページ上部サイトマップから該当のページを参照に設定してみてください。

VRRPの設定

Router(config)# interface FastEthernet0/0.0
Router(config-FastEthernet0/0.0)# ip address 192.168.1.1/24
Router(config-FastEthernet0/0.0)# vrrp 10 ip 192.168.1.254
Router(config-FastEthernet0/0.0)# no shutdown

vrrp 10 ip 192.168.1.254

ここでは 192.168.1.1をFE0/0.0に設定していて、 実際にtelnetとかでログインするのはこのIPアドレス。そして今回設定したのが192.168.1.254のアドレスでこれが実際に使用するVRRPのアドレスになる。クライアントPCのデフォルトゲートウエイはこの値に設定し直す必要がある。ちなみにpriorityは10に設定した。

もう1台も同じ構成で構成する

Router(config)# interface FastEthernet0/0.0
Router(config-FastEthernet0/0.0)# ip address 192.168.1.2/24
Router(config-FastEthernet0/0.0)# vrrp 10 ip 192.168.1.254
Router(config-FastEthernet0/0.0)# no shutdown

このルーターでは192.168.1.2のIPを指定する。VRRPの設定は実はこれで終わり。今回はpreemptまでやらないので、基本的な構成であれば非常に簡単に構成することができる。

ネットワークモニタの設定

いよいよ楽しい部分。IXにはインターフェイスを監視してその断を検知するやりかたと、特定のホストにpingを飛ばして、一定条件で返信がない場合に断と判断する場合の2パターンある。今回はホストを監視するパターンでいきたいと思う。監視するアドレスはいろいろとあると思うけど、今回は192.168.2.1と仮定する。

Router(config)# watch-group host-watch 10
Router(config-watch-host-watch-10)# probe-counter watch 1
Router(config-watch-host-watch-10)# probe-counter variance 6
Router(config-watch-host-watch-10)# probe-counter restorer 6
Router(config-watch-host-watch-10)# probe-timer variance 10
Router(config-watch-host-watch-10)# probe-timer restorer 10
Router(config-watch-host-watch-10)# event 10 ip unreach-host 192.168.2.1 FastEthernet0/1.0 source FastEthernet0/0.0
Router(config-watch-host-watch-10)# action 10 shutdown-vrrp 10
Router(config-watch-host-watch-10)# exit
Router(config)# network-monitor host-watch enable

それでは１つ１つ解説したいと思う。

watch-group host-watch 10
probe-counter watch 1
probe-counter variance 6
probe-counter restorer 6
probe-timer variance 10
probe-timer restorer 10
event 10 ip unreach-host 192.168.2.1 FastEthernet0/1.0 source FastEthernet0/0.0
action 10 shutdown-vrrp 10

ホスト監視の設定になる。192.168.2.1 に対してFE0/0.0からICMP Echo パケットを10 秒間隔で送信し、6回連続で応答を受信しなかった場合に障害、応答を受信した場合に復旧と判定する。

また、障害検出時にVRRPインターフェイスをシャットダウンすることで、すべてのトラフィックがもう1台のルーターを通じて流れるようになる。

なお、1 回の監視で送出するICMP Echo パケットの設定(probe-counter watch 1)と、障害と判定するICMP Echo Reply 連続受信失敗数(probe-counter variance 6)はデフォルトと同じ値になるので、show running-config では表示されない。

network-monitor host-watch enable

ネットワークモニタ設定”host-watch”を有効にする。

NTTに回線を止められました – 静止した闇の中で

外出先から自宅にVPNがつながらないから、おかしいなぁと思って夜に帰宅。そうしたら郵便ポストになにやらメモ用紙が。

NTTからのお願い・・・!?

お客様宅の端末側の影響により外の集合装置が異常を来して他のお客様が使用できない(光電話とネット)状態なので、お客様の信号を止めてありますので宅内装置を点検の上、上記まで連絡くださるようお願いします。

どうもうちが原因で、マンション全体にご迷惑をおかけしてしまったようです。この場をお借りして、反省するとともに、深くお詫び申し上げます。

とはいえ、どうしたものかな。何が原因だったんだろう。

今度詳しく書こうと思いますが、うちの家ではネットワーク回線が正・副・予備の3系統あって、そのうちの正と副がNTTのBフレッツを使用しています。それぞれ個別のルーターが動いていまして、LAN側からみればVRRP(ヴァーチャルに存在するIPのようなもの)で1つのゲートウエイに見えます。

それぞれ個別のルーターは相互に監視をしていて、どちらかの回線に異常が発生すると、それを検知して異常が発生した回線に接続されているルーターを（LAN側の機器が）使わないように前述のVRRPから切り離します。

また、あらかじめ設定した条件により、正常に回線が復旧したとルーターが判断すると、回線をバックアップからメインへ自動的に切り戻します。

この機能により、仮に障害が発生したときでもLAN側からみれば「あれ、インターネット繋がらないなぁ … おっ、繋がった」と思うぐらいの時間の感覚でネットが使用できるのですが、今回のNTTからのお願いは、これが何か関係しているような気がします。

ともかくも、朝市で電話して、ほかの皆さんにご迷惑をおかけしないようにしたいと思います。

5月29日追記：

その後の調査で、ひかり電話のLANがなぜかWAN用のスイッチに接続されていることが発覚 NTTの方とお話ししまして、回線を復旧していただきました。ご迷惑をおかけしました。