「VPNが死んでるのに気づかない」を卒業する――IPsec DPD(Dead Peer Detection)の現場的解釈
ネットワークエンジニアとして現場に立つと、時折「VPNのトンネルが上がっているはずなのに、パケットがブラックホールに吸い込まれる」という悪夢のような現象に直面します。特に、ルーターが対向機器の沈黙を検知できず、セッションをゾンビのように維持し続けてしまうケースは、運用担当者にとって最も頭の痛いトラブルの一つです。
今日は、そんな「接続断の検知」を司る影の功労者、DPD(Dead Peer Detection)について深掘りします。教科書的なRFCの定義をなぞるだけではなく、なぜこの機能が重要なのか、そして実務でどうパラメーターをチューニングすべきか、現場の視点から解説しましょう。
—
1. DPDは「ネットワークの心拍確認」である
IPsecにおけるDPDは、一言で言えば「対向ピアが生きているかを確認するための定期的なヘルスチェック」です。
本来、IPsecはSA(Security Association)が確立されると、データが流れない限り沈黙し続けます。しかし、中間のISPで経路障害が発生したり、対向のルーターが電源断を起こしたりしても、こちら側はそれを知る術がありません。そこでDPDの出番です。
DPDは R-U-THERE というメッセージを投げ、対向から R-U-THERE-ACK が返ってくるかを監視します。このやり取りがない場合、ピアが死んでいると断定し、無駄になったSAを廃棄して再接続を試みるのです。
—
2. 現場を救うパラメーター設計の勘所
DPDの挙動は、主に以下の3つのパラメーターで制御されます。ここを適当に設定していると、障害時の復旧が遅れたり、逆に過剰なパケットを投げて帯域を圧迫したりします。
interval(送信間隔):R-U-THEREを送る秒数。timeout(リトライ待ち時間): 応答がない場合、再送を待つ時間。retries(リトライ回数): 応答がない場合、何回再送を試みるか。
実務での設定例(Cisco IOSの場合)
現場でよくある設定ミスは、この値を短くしすぎることです。不安定なインターネット回線上で極端に短い interval を設定すると、一瞬のパケットロスでVPNが再構築ループに陥り、かえって通信品質を低下させます。
! DPDの設定例
! 10秒ごとに確認し、3回応答がなければセッションを破棄する
crypto isakmp keepalive 10 3
—
3. シーケンスを理解する:パケットはどう流れるか
DPDの内部挙動を理解するために、パケットのシーケンスを追ってみましょう。
1. 通常時: 設定した interval ごとに、暗号化されたメッセージが往復します。
2. 障害発生: R-U-THERE を送っても、対向から反応がありません。
3. 再送フェーズ: timeout 秒待機してもACKが来ない場合、リトライを行います。
4. 切断判定: retries 回数分繰り返しても応答がなければ、ローカル側でSAを削除し、再確立(IKEフェーズ1/2の開始)へと移行します。
この「再確立」のタイミングで、VPNが再開されるわけです。もしログに DPD failure の文字が踊っていたら、それは対向側のルーターが死んでいるか、物理的に経路が完全に切断されている証拠です。
—
4. デバッグと運用の心得
運用中に「VPNが繋がっているはずなのに疎通がない」という報告を受けた際、私は必ず以下の手順でデバッグを行います。
ステップ1: ログの確認
まずはルーターのログを debug コマンドで追います。
# Ciscoの場合:DPDのイベントをリアルタイム監視
debug crypto isakmp keepalive
ステップ2: パケットキャプチャによる検証
もし debug で情報が足りなければ、tcpdump 等でUDP 500番(IKE)のパケットを確認します。Pythonを使って簡易的にパケットのヘッダーを確認するスクリプトを書くのも手です。
# Scapyを用いた簡易確認イメージ
from scapy.all import sniff
# UDP 500番ポート(IKE)のパケットをキャプチャし、DPDの兆候を探る
def detect_dpd(packet):
if packet.haslayer('UDP') and packet['UDP'].dport == 500:
print(f"IKE Packet detected: {packet.summary()}")
sniff(filter="udp port 500", prn=detect_dpd, count=10)
—
執筆後記:自動化の罠に陥らないために
ゼロトラスト全盛の今、境界防御としてのIPsec VPNの重要性は依然として変わりません。しかし、DPDのような「枯れた技術」ほど、いざという時の設定値が運用の明暗を分けます。
「ネットワークは繋がっているのが当たり前」ではありません。
DPDの設定を適切に行い、自律的に障害を検知し、復旧する――この泥臭い積み重ねこそが、エンタープライズなインフラエンジニアの矜持です。もし皆さんの環境でVPNの安定性に不安があるなら、一度この interval と retries の値を見直してみてください。
「繋がらない」を「自動で治る」に変える。その小さな工夫が、週末の呼び出しを減らす一番の近道になるはずです。
コメント