🎯 結論ファースト：IKEセッション復旧の最適解
IKEセッションがダウンした場合、以下の2つの設定を組み合わせることで自動復旧を実現できます。
答え①
DPDタイムアウトアクション = Restart
DPDがピアのダウンを検出したら、IKEセッションを自動的に削除→再確立する「Restart」を設定する。これにより、手動介入なしでトンネルが再構築されます。
答え②
トラフィックは顧客側（CGW）から開始
AWS VPNエンドポイントではなく、顧客側のカスタマーゲートウェイ（CGW）からトラフィック（=興味あるトラフィック）を送信してIKEネゴシエーションをトリガーする。
🏢 たとえ話：「2つのオフィスビルを結ぶ秘密の専用通路」
あなたの会社（オンプレミス）と取引先のビル（AWS）が、外部の人には入れない秘密の専用通路（VPNトンネル）で繋がっています。この通路を使うには、まず身分証明と合言葉の確認（IKE Phase 1）を済ませてから、書類の暗号化ルールを決める（IKE Phase 2）必要があります。定期的に警備員が「通路の向こう側に人いますか？」と確認電話（DPD）を送りますが、応答がなくなったら…通路をどうするか？が今回のテーマです。
📐 セクション1：Site-to-Site VPN の基本構成
オンプレミスとAWS VPCをIPsecトンネルで安全に接続する構成
Site-to-Site VPN 接続の全体像
オンプレミス
カスタマーゲートウェイ
(CGW)
(CGW)
🔒 IPsec VPNトンネル 🔒
インターネット経由の暗号化通信
IKE Phase 1 → Phase 2 → データ転送
IKE Phase 1 → Phase 2 → データ転送
AWS VPC
仮想プライベートゲートウェイ
(VGW)
(VGW)
たとえ話：秘密の専用通路
🏢 あなたの会社ビル = オンプレミス
🏢 取引先のビル = AWS VPC
🚪 あなた側の入口 = CGW
🚪 取引先側の入口 = VGW
🔒 秘密の通路 = VPNトンネル
📞 確認電話 = DPD
⟷
AWS の実際の構成
🏢 カスタマーデータセンター
☁️ AWS VPC（仮想ネットワーク）
📡 Customer Gateway (CGW)
🌐 Virtual Private Gateway (VGW)
🔐 IPsec VPNトンネル
📡 Dead Peer Detection (DPD)
🔑 セクション2：IKEプロトコルの2フェーズ
VPNトンネルを確立するための鍵交換プロトコル「IKE」の仕組み
IKE ネゴシエーションの流れ
🤝
IKE Phase 1
IKEセキュリティアソシエーション確立
① 相互認証：お互いが正当な通信相手であることを確認
② 暗号アルゴリズムのネゴシエーション：どの暗号化方式を使うか合意
③ 共有秘密鍵の生成：安全な通信チャネルの基盤を構築
② 暗号アルゴリズムのネゴシエーション：どの暗号化方式を使うか合意
③ 共有秘密鍵の生成：安全な通信チャネルの基盤を構築
💡 たとえ：「身分証明書を見せ合い、合言葉を交換する」ステップ。通路に入る前の本人確認フェーズ。
➡️
📦
IKE Phase 2
IPsecセキュリティアソシエーション確立
① IPsec SA確立：実際のデータを保護するためのルールを決定
② 暗号化パラメータの合意：データの暗号化・認証方式を確定
③ トンネル開通：安全なデータ転送が可能に
② 暗号化パラメータの合意：データの暗号化・認証方式を確定
③ トンネル開通：安全なデータ転送が可能に
💡 たとえ：「書類をどんな暗号で送るかルールを決める」ステップ。通路を通る荷物の保護方法を決定。
⚠️ IKEセッションがダウンすると何が起きる？
IKEセッションがダウンすると、Phase 1で確立した信頼関係とPhase 2で決めた暗号化ルールが全て無効になります。つまり、VPNトンネルを介したすべての通信が完全に中断します。たとえ話でいえば「通路の鍵が壊れて、通行証も失効した」状態です。復旧するには、Phase 1から再度やり直す必要があります。
📡 セクション3：デッドピア検出（DPD）の仕組み
「相手はまだ生きている？」を確認する監視メカニズム
📞 たとえ話：通路の警備員の「定期確認電話」
警備員は定期的に通路の向こう側に電話をかけます。「もしもし、そちらにまだ人いますか？（R-U-THERE）」と。向こうから「はい、います！（R-U-THERE-ACK）」と返事があれば安心。しかし、何度電話しても応答がない場合、警備員は「向こう側のビルは閉鎖された」と判断し、あらかじめ決められたアクション（None / Clear / Restart）を実行します。
DPD メッセージ交換の仕組み
✅ 正常時：ピアが応答する場合
CGW（自分側）
VGW（AWS側）
❌ 異常時：ピアが応答しない場合
CGW（自分側）
VGW（ダウン）
⚙️ セクション4：DPDタイムアウトアクション 3つの選択肢
「相手が応答しなくなった時、通路をどうするか？」の3パターン
None（何もしない）
IKEセッションを維持したまま何もしない。相手が復帰するまで「死んだトンネル」が残り続ける。
💡 たとえ：電話に出ないけど、通路の鍵はそのまま。復旧に最も時間がかかる。
Clear（掃除して放置）
IKEセッションを削除するが、自動再確立はしない。復旧には手動またはトラフィック開始が必要。
💡 たとえ：通路を閉鎖して鍵を回収。再開するには誰かが改めて申請しに行く必要がある。
⭐ 推奨設定
Restart（自動再起動）
IKEセッションを削除し、即座に新しいセッションの確立を開始する。最も迅速な自動復旧。
💡 たとえ：通路を閉鎖→即座に新しい鍵を発行して再開。警備員が自動で全て対応する。
| 項目 | 😴 None | 🧹 Clear | 🔄 Restart |
|---|---|---|---|
| IKEセッション削除 | しない | する | する |
| 自動再確立 | しない | しない | する |
| 復旧速度 | 最遅 | 中程度 | 最速 |
| 手動介入の必要性 | 状況による | 必要/トラフィック待ち | 不要 |
| AWS推奨 | — | — | ⭐ 推奨 |
📤 セクション5：トラフィックの開始方向
IKEネゴシエーションを「誰から」トリガーすべきか？
💡 なぜトラフィックの方向が重要なのか？
AWS Site-to-Site VPNでは、AWSのVGW側はIKEネゴシエーションを開始できません。VGWはリスポンダー（応答者）としてのみ動作します。つまり、トンネルの再確立をトリガーするには、必ず顧客側のCGWからトラフィック（＝興味あるトラフィック/interesting traffic）を送信する必要があります。
トラフィック開始方向の図解
CGW（顧客側）
IKEイニシエーター
（セッション開始側）
（セッション開始側）
✅ ここからトラフィックを送信！
➡️
Interesting Traffic
トンネル経由で送るべき
トラフィックを送信
VGW（AWS側）
IKEリスポンダー
（応答側のみ）
（応答側のみ）
⚠️ VGWからは開始できない
📞 たとえ話：「電話を掛けるのは、いつもあなたの側から」
取引先のビル（AWS）には「かかってきた電話には出るが、自分からは電話しない」というルールがあります。通路が閉鎖された後に「もう一度通路を開けましょう」と提案するのは、必ずあなたの会社側から電話する（＝CGWからトラフィックを送る）必要があります。取引先側は「どうぞ、開けましょう」と応答するだけです。
🔄 セクション6：IKEセッション復旧の全体フロー
DPD Restart + CGWからのトラフィック開始による自動復旧プロセス
復旧フロー（DPD Restart 設定時）
❌ Step 1：IKEセッションがダウン
ネットワーク障害やピアの問題でIKEセッションが切断
⬇️
📡 Step 2：DPDがダウンを検出
R-U-THEREメッセージへの応答がない → タイムアウト判定
⬇️
🔄 Step 3：Restartアクション発動
古いIKE SAを削除し、新しいIKEネゴシエーションを自動開始
⬇️
📤 Step 4：CGWからトラフィックを送信
顧客側CGWから興味あるトラフィックを送信 → IKEネゴシエーション開始をトリガー
⬇️
✅ Step 5：VPNトンネル復旧完了
IKE Phase 1 → Phase 2 → IPsecトンネル再確立 → 通信再開
🏢 たとえ話：通路の復旧プロセス
① 通路が突然使えなくなる → ② 警備員が電話で確認「応答なし！」 → ③ 警備員が自動で古い鍵を破棄し、新しい鍵の準備を開始（Restart） → ④ あなたの会社側から「通路を使いたいです」と通知を送る（CGWからのトラフィック） → ⑤ 新しい鍵と通行証が発行され、通路が復旧！
⌨️ セクション7：実際の設定例
CGW側のDPD設定とトラフィック開始の実装
CGW側 DPD設定例（Cisco IOS）
! DPDを有効化（10秒間隔、3回リトライ後にRestart） crypto isakmp keepalive 10 3 periodic ! IPsecプロファイルでDPDアクションを設定 crypto ipsec profile AWS-VPN-PROFILE set isakmp-profile AWS-ISAKMP set transform-set AWS-TS ! DPDタイムアウト時にセッションをRestart set security-association lifetime seconds 3600
CGW側 DPD設定例（strongSwan / Linux）
# /etc/ipsec.conf conn aws-vpn left=%defaultroute leftid=203.0.113.1 # CGWのパブリックIP right=52.xx.xx.xx # AWS VPNエンドポイントIP type=tunnel auto=start # 自動でトンネル確立を開始 dpdaction=restart # ★ DPDタイムアウト時にRestart dpddelay=10s # 10秒ごとにDPDチェック dpdtimeout=30s # 30秒応答なしでタイムアウト keyexchange=ikev2 # IKEv2を使用
AWS CLI — VPN接続作成時のオプション
# Site-to-Site VPN接続を作成 aws ec2 create-vpn-connection \ --type ipsec.1 \ --customer-gateway-id cgw-0123456789abcdef0 \ --vpn-gateway-id vgw-0123456789abcdef0 \ --options '{ "TunnelOptions": [ { "DPDTimeoutAction": "restart", "DPDTimeoutSeconds": 30, "Phase1LifetimeSeconds": 28800, "Phase2LifetimeSeconds": 3600 } ] }'
ベストプラクティスまとめ
✅ DPD設定
dpdaction = restart を設定して、検出後に自動再確立を行う
✅ トラフィック方向
必ずCGW（顧客）側からトラフィックを開始してIKEをトリガー
✅ DPD間隔
10秒間隔がAWSの推奨値。短すぎると誤検知、長すぎると検出が遅れる
✅ IKEv2の使用
IKEv1よりもIKEv2を推奨。再ネゴシエーションが効率的で、NATトラバーサルも標準サポート
❓ よくある質問（FAQ）
Q: DPDの「None」を選んだら、トンネルはどうなりますか？
A: IKEセッションが「死んだ状態」のまま残り続けます。通信はできませんが、リソースは占有し続けます。復旧するには、手動でセッションをクリアするか、IKEのライフタイム期限が切れてからトラフィックを再送信する必要があり、復旧に最も時間がかかります。
Q: DPDの「Clear」と「Restart」の実用上の違いは何ですか？
A: 「Clear」はIKEセッションを削除するだけで止まります。トンネルを再確立するには、CGW側から新しいトラフィックを送信してIKEネゴシエーションをトリガーする必要があります。「Restart」は削除後に自動で再確立を試みるため、CGW側のトラフィック送信と組み合わせることで最速の復旧が可能です。
Q: AWS側（VGW）からIKEネゴシエーションを開始できないのはなぜ？
A: AWSのVGWはセキュリティ上の設計として「リスポンダーモード」で動作します。イニシエーション（接続開始）は常に顧客側のCGWが担当します。これはAWSマネージドサービスの設計方針であり、顧客側が接続のコントロールを持つためです。
Q: 「Interesting Traffic」とは具体的に何ですか？
A: VPNトンネルの対象となるネットワーク宛のトラフィックです。例えば、オンプレミスの 10.0.0.0/16 から AWS VPC の 172.16.0.0/16 へのpingやHTTPリクエストなど。このトラフィックがCGWを通過すると、IPsecポリシーに一致し、IKEネゴシエーションがトリガーされます。
Q: 冗長化のために2本のトンネルがあると聞きましたが、DPD設定は両方に必要？
A: はい。AWS Site-to-Site VPNは各接続に2本のトンネル（高可用性のため）を提供します。それぞれが独立したIKEセッションを持つため、DPD設定は両トンネルに適用する必要があります。片方がダウンした場合にもう片方にフェイルオーバーするよう、BGPやスタティックルーティングと組み合わせて設定します。