ヤマハルータでは、この IKE Keepalive を [ ipsec ike keepalive use 1 on ] といったコマンドで実現します。 確かにこのコマンドをヤマハルータに設定したところ、IPsec トンネルが確立中のルータを再起動しても、復旧後は自動的にトンネルアップをしてくれるようになりました。 けれども……
早い話 Internet VPN では、男なら誰しもが大好きなサイト（僕含む） へアクセスするための回線と、まったく同じ回線を使って VPN を構築します。 そんな回線と一緒にしちゃさすがにマズイっしょ、ということで VPN トンネルには暗号化を張るのですよん。
↑図3：こうやって見るとインターネットって世紀末状態
それでは、以下に IPsec トンネルを張る流れをザックリと書きます。
図2 に書きました構成と Config をヤマハルータに設定することで、さっそく IPsec トンネルが確立する環境が構築します。 ただし、この状態だと双方のルータが IKE のトリガー処理を止めて ( ipsec auto refresh off) いることから、IPsec トンネルはアップしません。
そこで片方のルータ （図2でいう右側 LANb とします） に IKE のトリガー処理 ( ipsec auto refresh on ) を書き加えてあげると、LANb ルータから IKE 処理を開始し、その結果 IPsec トンネルがアップします。 ここでのポイントは、IPsec トンネルの正しい設定を施していても、IKE 処理を始めない限り IPsec トンネルは確立しない という点です。
ちなみに、この IKE 処理を始める側のルータ (LANb) を "Initiator" と呼び、IKE 処理を受ける側を "Responder" と呼びます。
↑図4： IPsec トンネルの確立は IKE によって始まる
「ところで IKE ってなに？」
という疑問につきましては、「IPsec トンネルを張る準備作業」 だと思ってください。 IKE を理解するには膨大な時間を （僕は） 要してしまうので、今回は準備段階という認識で大丈夫です。
とっても極端に書いてしまえば、オナゴにメールする経路が IPsec トンネル だとしたら、オナゴからメールアドレスを聞き出す作業が IKE だと思えばヨロシイかと。 ……というか、今はメールじゃなくて LINE の時代なんだっけ。。 僕はガラケーユーザーなので、それを理由に 「メアド持ってないんだよねー」 っていつもアドレス交換を拒否されるんだよね。 じゃぁスマホ持ってたら LINE 交換してくれるのか、っつー話。(´；ω；`)
さて、悲しい話は置いといて。 動作の話に戻りましょう。 OTL
今回の検証では諸事情により IKE トリガー処理を LANb ルータにしか施していませんが、双方のルータに IKE トリガー処理を設定しても問題ありません。 むしろ双方のルータに設定することが理想でしょうな。
IPsec トンネルが確立すると、Ping などを実行することで疎通確認が取れますが、これらトンネルの実体は SA と呼ばれる概念によって実現しています。 ヤマハルータでは [ show ipsec sa ] コマンドから、それらの情報を確認できます。
↑図5：SA が確認できれば、IPsec トンネルは確立している
「SA ってなにさ？」
という疑問につきましては、ここでは 「IPsec トンネルの実体」 だと思ってください。 厳密には少し違うのですが、本メモでは SA ＝ IPsec トンネル、といった認識で問題ありません。
図5 に show ipsec sa の結果を書きましたが "sa" という項目があります。 これが SA を意味しています。 １～3 まで sa が存在しますが、これは IPsec トンネルが 3本のトンネルで確立されている ためです。 IPsec トンネルは仮想的な１本のトンネルとして理解されがちですが、裏では 「鍵交換用トンネル (ISAKMP SA)」、「データ送受信トンネル (IPsec SA)×2」 の合計３本の仮想トンネルが確立されています。
次に、本題の IKE Keepalive に出会ったキッカケとなった 「ルータを再起動するとトンネルが再確立しない」 という問題について、またもや ザックリ とメモしていきます。
図5 でも書きましたが、IPsec トンネルが確立している相互のルータは SA を持ちます。 この SA はトンネルを認識する情報が入っていますが、お互いに 同じ値 （鍵と SPI） を持っている と思っていただいて大丈夫です。 この場合は、そういう モン だと思ってください。 ちなみに 「値」 （鍵と SPI） は [ show ipsec sa gateway 1 detail ] から確認ができます。
↑図7：お互いに同じ 「値」 を持ち合う
これらの SA を持ち合うことで IPsec トンネルは繋がりますが、言い換えれば SA が無ければ （SA の値が異なると） IPsec トンネルは繋がりません。 普通に IPsec トンネルを張っていれば SA が無くなることは少ないのですが、何か特別な動作を行うことで SA が削除されてしまうことがあります。 その例が今回の 「ルータ再起動」 です。
たとえば 図2 の LANa / LANb ルータ同士が IPsec トンネルを張り合っているとします。 このとき LANa ルータを再起動しますと LANa ルータは保持している SA を破棄します。 LANa ルータに IKE トリガーのコマンドが設定されていれば話は別ですが、今回は無効化しているため LANa ルータは IKE 処理を始められず、SA 無しの状態となり IPsec トンネルを張ることができません。 よって LANa ルータはトンネルダウン状態になります。 この状態を SA の消失 と呼びます。
一方 LANb ルータは、LANa ルータが再起動する前に保持していた SA を使って通信を継続します。 この SA は消失しているため既に使われていませんが、LANb ルータはそのことを知る由がないため、無効化された IPsec トンネルを使い続けてしまうのです。
もしこのように SA が消失してしまったときは、SA を新規生成 することで IPsec トンネルを再確立します。
ヤマハルータの場合は IKE トリガー処理 (ipsec auto refresh on) が設定されていることを前提として、LANb ルータの対向が存在しない SA を削除 (ipsec sa delete SA) すれば、自動的に IKE 処理が始まり IPsec トンネルが確立してくれます。 または SA の 「寿命 (Duration)」 が尽きる直前にも、新しい SA を確立するための IKE 処理を行なってくれますので、これでも大丈夫です。 ちなみにこの動作を "Re-key" と呼びます。
けれども SA が消失するたびに毎回 SA を手動で削除、もしくは SA の Duration が尽きて Re-key が始まるまで待つのはタマランので、本来は LANa / LANb 双方のルータに IKE トリガー処理を設定します。 こうすれば双方から IKE 処理を開始しますので、LANa / LANb どちらのルータを再起動させても IPsec トンネルが自動的にアップしてくれます。
さっそく以下から IKE Keepalive を動作させます。 環境につきましては 図2 と 図4 をベースにしており、加えて LANb ルータに以下の IKE Keepalive コマンドを追加した状態で、この検証を実施しています。
IKE Keepalive コマンド
ipsec ike keepalive use 1 on
先ほどと同様、この状態で LANa ルータを再起動 （または ipsec refresa sa コマンド） すると、前項の SA の消失により IPsec トンネルがダウンし、自動的にアップすることはありません。 なぜなら LANb ルータが古い SA を使い続けてしまうからですね。
けれども今回は自動的にトンネルアップしました。 どうやら IKE Keepalive が働いてくれたようです。
IKE Keepalive が正しく動作すると、内部的には通常どおり IKE 処理が始まりますが、このとき IKE 処理を開始する Initiator は IKE Keepalive 設定を施してある LANb です。 LANa は Responder として動作しますが、当たり前といえば当たり前ですね。
また、IKE Keepalive が動作中に LANb ルータのログを確認したところ、"heartbeat: dead peer detection" というメッセージが記録されていました。 この "Heartbeat" と "Dead peer Detection (DPD)" の2つが IKE Keepalive にとっての重要なキーワードになりますが、今は 「dead peer detection というメッセージがログに出てきたら IKE Keepalive が働くんだな」 程度に思ってください。
↑図11：IKE Keepalive はトンネルダウンを検知
では次に IKE Keepalive の細かな動きについて理解を深めていきますが、その前にひとつメモします。 今回はヤマハルータを使って IKE Keepalive を実現させていますが、ヤマハルータではこの仕組みを実現させるために、以下3種類のプロトコルのいずれかを使います。
基本的には今までのネットワーク構成と変わりありませんが、LANa ネットワークに PCa が1台追加されました。 この PCa の IP アドレスを 192.168.0.101 に設定し、それから LANb ルータの IKE Keepalive 設定コマンドに PCa の IP アドレスを指定しました。
これらの設定を有効化させたあと、PCa から Wireshark を起動させると…LANb ルータ発の Ping パケットが定期的に飛んできました。 どうやら ICMP echo の IKE Keepalive は、ルータのインターフェース以外の IP アドレスを指定しても問題ナイようですね。
そして PCa の LAN ケーブルを引っこ抜き、LANb に対する Ping レスポンスを停止します。 その結果……IPsec トンネルは正常に確立しているのに、LANb に有効化した IKE Keepalive が機能して 新しい SA が生成されました。 もちろん LAN ケーブルを外さなくとも、ファイアウォールなどでパケットを遮断させられれば同じ結果になります。
↑図15：古い SA が健在なのに新しい SA を作り始める
ということで、茶番タイムの結果は…
結論： ルータ以外の IP 機器に IKE Keepalive の Ping 宛先を指定しても大丈夫
…となりました。 どうやら本当に茶番だったようです。。
――と、横道にそれてしまった茶番タイムでしたが、まずはこれくらい動かすことができれば IKE Keepalive の掴みとしては十分だと思っています。
ちなみに今回は IKE Keepalive としてメモしていますが、前述もしましたが "Keepalive" という仕組みそのものはルータ以外にも色々なところで活用されています。 細かな動きは覚えなくても問題ないと思いますが、Keepalive の存在は知っておいて損はないですね。
このように IKE Heartbeat は規格化されていない、ということは言葉を変えればベンダーの数だけ IKE Heartbeat の種類が存在するともいえます。 となればその一つ、ヤマハルータの IKE Heartbeat を追うよりも DPD を追った方が効率が良い気がしてきたこともあり、今回は DPD についてのメモを残すことを決めた次第でした。
2．ここで LANb ルータの LAN ケーブルを抜きます。 すると IPsec トンネルは一時断絶状態になりますので R-U-THERE メッセージを送ることができません。 R-U-THERE-ACK レスポンスが受け取れない LANa ルータは、シーケンス番号に 1 を加算した R-U-THERE メッセージを再送し続けます。
3．R-U-THERE-ACK レスポンスを受け取れないと判断した LANa ルータでは IKE Keepalive の動作が始まります。 このときログでは "DPD: detected dead peer" というメッセージが残ります。 同時に保持していた SA をすべて解放し、Phase 1 からの IKE を開始します。
↑図19：タイムアウトから IKE 開始まで
以上、DPD についてのメモでございました。
今回は IKE Keepalive についてメモしましたが、振り返ってみるとダウン検知の仕組み自体は、なんらかのパケットを使って対向ルータの生存を定期的に確認し、それがタイムアウトを起こした状態をダウン検知とみなす、といったわりとシンプルな仕組みであることが分かりました。
もしかしたら上記以外の仕組みによる IKE Keepalive が存在するかもしれませんが、それらに関しては存在を発見したときに別途追究することにします。 今回はこのあたりでオシマイといたしますw (^ω^*)
