VPNが「沈黙」した瞬間に備える──IPsecの守護神「DPD」の仕組みを紐解く
ネットワークエンジニアの皆さん、こんにちは。現場で設計や運用をしていると、「VPNのトンネルは繋がっているはずなのに、なぜか通信が通らない」という悪夢のような状況に遭遇したことはありませんか？
VPNは、インターネットという荒波の中に専用の「秘密のトンネル」を掘る技術です。しかし、このトンネルは物理的なパイプではないため、相手がどこか遠くでプツンと切れてしまっても、こちら側からは「まだ繋がっているつもり」でパケットを送り続けてしまうことがあります。
そんな「見えない断絶」をいち早く察知し、壊れたトンネルを再構築するために欠かせないのが、今回解説する DPD（Dead Peer Detection） という仕組みです。
—
DPDを「郵便配達」でイメージしてみよう
専門用語の前に、ちょっと日常的な例え話をしましょう。
あなたが海外の友人に重要な手紙を送るとします。あなたは「郵便局（VPNゲートウェイ）」を通じて手紙を出しますが、もし相手の住所が何らかの理由でなくなっていたらどうでしょう？ あなたはいつまでも返事が来るのを待ってしまいますよね。
ここで、「定期的に『元気ですか？』という短い手紙を送り、返事がなければ『あ、もうこの人いないんだな』と判断する仕組み」があったらどうでしょうか？
これがまさに DPD（Dead Peer Detection） の役割です。
- R-U-THERE（お前はそこにいるか？）： こちらから相手に「生きてる？」と問いかけるパケットを送ります。
- I-AM-ALIVE（私は生きています）： 相手が「生きてるよ！」と返事を返します。
- 沈黙（Dead）： 何度問いかけても返事がない。ここで初めて「相手は死んだ（Dead Peer）」と判定します。
—
DPDの動作ロジック：しつこさと諦めが肝心
DPDがいつ「あ、こいつはもうダメだ」と判断するか、そのロジックは主に2つのパラメータで決まります。
1. Interval（間隔）： 「どれくらいの頻度で問いかけるか」。例えば10秒に1回。
2. Retries（リトライ回数）： 「何回返事がなかったら諦めるか」。例えば3回。
この設定だと、相手が反応しなくなってから「3回×10秒＝30秒」経過した時点で、ようやく「トンネルは死んだ！」と判定し、古くなった接続セッションを強制的に破棄します。これによって、新しいトンネルを張り直すための準備が整うわけですね。
—
現場で役立つ！Ciscoルーターでの設定例
では、実際に現場でよく使われるCiscoルーターのコマンド設定を見てみましょう。設定は非常にシンプルですが、この数字一つでネットワークの「気付き」の速さが変わります。
! DPDの設定は crypto isakmp プロファイルの中で行います
crypto isakmp profile VPN_PROFILE
! 10秒ごとに確認パケットを投げ、3回連続で失敗したら「死んだ」とみなす
keepalive 10 3
! 日本語解説:
! 最初の10は「インターバル(秒)」、次の3は「リトライ回数」です。
! ネットワークが不安定な環境なら少し長めに、
! 高速な切り替えが必要なら短めに設定するのがコツです。設定時の注意点
「じゃあ、1秒間に100回送るようにすれば最強じゃない？」と思うかもしれませんが、それは間違いです。あまりに頻繁に確認パケットを投げると、VPNゲートウェイのCPU負荷が上がり、本来の通信を圧迫してしまいます。「現実的な監視頻度」を見極めるのが、凄腕エンジニアの腕の見せ所です。
—
なぜ「DPD」の設定が重要なのか？
最近のゼロトラストアーキテクチャにおいても、VPNは依然として重要な入り口の一つです。DPDがないと、以下のような泥沼のトラブルに直面します。
- ブラックホール化: 通信ができないのにセッションが残り続け、PCやサーバーが「通信できるはずだ」と思い込んでタイムアウト待ちを繰り返す。
- 再接続の遅延: トンネルが死んでいると認識されるまで、新しいトンネルが張れず、業務が長時間停止する。
DPDは、単なる「死活監視」ではありません。「異常をいち早く正常に検知し、自動的に復旧プロセスへ繋ぐための自動修復スイッチ」なのです。
—
まとめ：ネットワークの健康診断を忘れずに
DPDは地味な機能ですが、これがあるおかげで私たちのネットワークは「壊れてもすぐに立ち上がる」という強さ（レジリエンス）を保っています。
初めてインフラに触れる皆さんは、まずは構築したVPN設定の中に keepalive や dpd といった単語が含まれているか確認してみてください。もし見当たらないなら、それは「相手が死んでいることにも気づけないトンネル」かもしれません。
トラブルが起きてから焦るのではなく、平時のうちに「いざという時にどうやって切断を検知するか」を設計しておくこと。それが、現場で信頼されるネットワークエンジニアへの第一歩です。
それでは、また次回の技術解説でお会いしましょう！
コメント