IPsecの寿命を握る「死んだ相棒」の検知学：DPD（Dead Peer Detection）のパケットレベル内部挙動と極限チューニング
ネットワークエンジニアの夜を最も憂鬱にするもののひとつが、「何の前触れもなく突如として沈黙する拠点間VPN」だ。
IKE（Internet Key Exchange）のSA（Security Association）が確立され、ESP（Encapsulating Security Payload）が流れていたはずのトンネルが、中間ルータのひそかなルーティング喪失や、ISPの気まぐれなステートフルファイアウォールのセッションタイムアウトによって、ある瞬間からただの「黒洞（ブラックホール）」と化す。
パケットを送り出しても、向こう側からの応答はない。しかし、送信側のIPsec実装は、相手が生きていると信じ込んでひたすら暗号化パケットを闇夜に放り投げ続ける。
この「ゾンビ状態のセッション」を検知し、速やかに死体撃ち（古いSAの破棄と再確立）を行うための救命救急プロトコルが、今回メスを入れる DPD（Dead Peer Detection） だ。
教科書には「接続断を検知するためのメカニズム」と一行で片付けられるこの機能だが、その下位レイヤーではどのようなパケットが飛び交い、どのようなタイマーとリトライのロジックが働いているのか。
今回は、パケットアナライザの向こう側に見えるIPsecの深淵を、徹底的に解き明かしていこう。
—
1. DPD不在の悪夢：なぜゾンビSAは放置されるのか
IPsecのデータプレーンであるESPは、本質的に「ステートレス」なUDPパケット（通常はポート500またはNAT-T用の4500）の海を泳ぐ。
TCPのようにコネクションの概念がないため、通信が途絶えても、エンドポイントのOSやVPNゲートウェイは「単にトラフィックが流れていないだけなのか、それとも対向ルータが電源ごと吹き飛んだのか」をデフォルトでは判別できない。
結果として何が起きるか。
対向側がリブートしてIKEのステートが完全に初期化されているにもかかわらず、自側だけが「古いIKE SA / IPsec SA」を大切に抱え続ける。
やがて自側からトラフィックが発生した際、古い暗号化キーでパケットを包んで送信するが、対向側は「そんなSA知らん」とばかりにICMPのエラーを返すか、無言でパケットをドロップする。
ユーザークライアントからは「社内システムに繋がらない」という苦情の嵐が飛び交い、管理者がCLIにログインして clear crypto isa sa を叩くまで、世界は静寂のまま停止し続けることになる。
この悲劇を防ぐためにRFC 3706で標準化されたのがDPDである。だが、その挙動は実装や設定によって巧妙かつ繊細に制御されている。
—
2. DPDのパケットレベル内部挙動とステートマシン
DPDの本質は、IKEのメッセージ交換を利用した「キープアライブ（死活監視）」だ。
ここで特筆すべきは、IKEv1とIKEv2でそのアプローチが根本的に異なる点にある。
IKEv1におけるDPD：R_U_THEREとR_U_THERE_ACK
IKEv1の仕様（RFC 2409）自体にはネイティブな死活監視が含まれておらず、CiscoやRFC 3706によって独自に拡張された。
IKEv1 DPDでは、独自のNotifyメッセージである R_U_THERE と R_U_THERE_ACK を用いる。
1. 無通信タイマーの起動:
設定されたアイドル時間（例: 10秒間）の間、対向からのESPパケットも含めて一切のトラフィックを受信しなかった場合、DPDステートマシンが目を覚ます。
2. プローブの送信:
自側から対向ピアに向けて、現在のIKE SAを識別するHashと、シーケンス番号を含む R_U_THERE パケット（IKE Notifyメッセージ）をUDP 500/4500で送出する。
3. 応答の待ち受けとリトライ:
対向が健在であれば、即座に同じシーケンス番号をエコーバックした R_U_THERE_ACK を返す。
もしタイムアウト時間内にこのAckが返ってこない場合、リトライカウンタがインクリメントされ、指数関数的または線形的な間隔で R_U_THERE が再送される。
4. 切断判定:
最大リトライ回数（例: 3回）を超過しても応答がない場合、ピアは「死亡（Dead）」と判定され、関連するすべてのIKE SAおよびIPsec SAが強制的に破棄（ teardown ）される。
IKEv2におけるネイティブな死活監視
次世代のIKEv2では、DPDはオプションではなく標準プロトコルに組み込まれている。
IKEv2では、専用のメッセージではなく、通常の IKE_INFORMATIONAL 交換を利用する。
中身が空の（あるいはNFAを含む）INFORMATIONALリクエストを送信し、対向がそれにINFORMATIONALレスポンスを返すことで生存を確認する。
構造が洗練された分、IKEv1特有のベンダ固有実装による互換性問題に悩まされるリスクが劇的に軽減されている。
—
3. 実務で直面するパラメーターチューニングと設計の罠
インフラアーキテクトが最も頭を悩ませるのが、DPDの「タイマー設定」のトレードオフだ。
「障害検知を早くしたいから、インターバルを短く、リトライを少なくしよう」という安易なアプローチは、往々にしてネットワーク全体の崩壊を招く。
代表的なパラメーターの構造（Cisco IOS-XEの例）
crypto isakmp keepalive 10 3
# 10秒間アイドル状態が続いた場合にDPD（R_U_THERE）を開始し、
# 3秒おきの応答がない場合に3回リトライ（合計約9秒の猶予）して切断判定を下すここで考慮すべき極限のパフォーマンスと安定性のバランスを挙げる。
1. アグレッシブすぎる設定の弊害:
例えば interval 2, retry 2 のような超高頻度設定にすると、瞬断レベルの遅延スパイクや、一時的なCPU高負荷によって正常なピアまで「死亡」と誤認され、SAの再確立（IKE Aggressive/Main Modeのハンドシェイク）が頻発する。
結果として、コントロールプレーンがIKEのパケット処理で埋め尽くされ、真の通信障害を引き起こす本末転倒な事態に陥る。
2. キャリア網やファイアウォールのステートタイムアウトとの兼ね合い:
多くの企業向けルータやクラウドの仮想ゲートウェイ（AWS VPN Gatewayなど）は、UDPセッションのタイムアウトを30秒〜60秒程度に設定している。
DPDのインターバルがこれよりも長い場合、ファイアウォール側がNAT/UDPセッションを勝手に忘れてしまい、DPDのプローブパケットが途中でドロップされるという最悪のループが完成する。
「DPDのインターバルは、必ず経路上の最短ステートフルタイマーよりも短く設定する」 これが鉄則だ。
—
4. Linuxカーネル（StrongSwan / Libreswan）におけるDPD実装とコンフィグ例
エンタープライズの現場やクラウドネイティブな環境で広く使われているLinuxベースのIPsec実装（StrongSwanなど）では、ipsec.conf においてDPDの挙動をきめ細やかに制御できる。
実際のプロダクション環境を想定したStrongSwanの設定ファイルを以下に示す。
# /etc/ipsec.conf
conn aws-dc-tunnel-01
keyexchange=ikev2
left=192.0.2.10 # 自側のパブリックIP
leftid=203.0.113.50 # 自側のアイデンティティ
right=198.51.100.20 # AWS側仮想ガゼットウェイのパブリックIP
rightid=198.51.100.20
leftsubnet=10.100.0.0/16 # 自側オンプレミスのプライベートセグメント
rightsubnet=172.16.0.0/16# AWS側のプライベートセグメント
auto=start
# --- DPD (Dead Peer Detection) の極限チューニング設定 ---
# 障害検知アクション: 接続断を検知した場合にクリアして再接続を試みる
dpdaction=restart
# DPDのチェック間隔 (秒): トラフィックが流れていない場合のプローブ送信間隔
dpddelay=15s
# 応答タイムアウト (秒): プローブを送信してから応答を待つ最大時間
# StrongSwanでは通常、遅延とリトライ回数を統合してタイムアウト値として扱う
timeout=30sこの設定が意味する現場の挙動
dpdaction=restart: ピアからの応答が途絶えた瞬間、カーネル内のXFRMフレームワークから古いSAが綺麗にパージされ、直ちに新しいIKE_SAの確立シーケンスがトリガーされる。これにより、人間が介入しなくても数秒以内に自動復旧が達成される。dpddelay=15s: 絶妙なバランス値。過剰なシグナリングトラフィックを発生させず、かつクラウド側のステートフルタイムアウト（通常30秒以上）に引っかからない最適なウィンドウサイズだ。
—
5. ゼロトラスト時代におけるDPDの立ち位置
境界防御の時代、VPNは「一度社内に入れば何でも許される安全地帯への直通特急」であり、そのセッションが切れないことこそが正義とされていた。
しかし、ゼロトラストアーキテクチャが主流となった現代において、VPNは単なる「リモートワーカーや拠点をつなぐ暗号化されたパイプ（トランスポート層のモート）」に過ぎない。
パイプそのものの信頼性を担保するのが、まさにDPDのようなメカニズムだ。
もし拠点側のネットワークが不安定になり、DPDが迅速に死活を検知できなければ、不正なパケットがブラックホールに吸い込まれるか、あるいは古い認証状態のままぶら下がり続けるゾンビセッションがセキュリティ上のアタックサーフェイス（攻撃対象領域）になりかねない。
パケットの1ビットの揺らぎを見逃さず、プロトコルのステートマシンの裏側で何が起きているのかを把握すること。
それこそが、複雑化するエンタープライズネットワークを統御し、真のレジリエンスを宿すインフラストラクチャを築くための唯一にして最短の道なのである。
コメント