IPsec VPN の切断対策手順｜切れるタイミングから原因を絞り、DPD・再キー・NAT・自動再接続を設定する

IPsec VPN が切れる問題は、「いつ切れるか」を記録すると原因をかなり絞り込めます。通信が少ない時間に切れるなら DPD や NAT のタイムアウト、接続から一定時間後に切れるなら再キー（リキー）時の設定の食い違い、回線やルーターの再起動後に戻らないなら自動再接続の設定不足が主な原因です。この記事では、strongSwan（swanctl）を例に、ログの読み方、原因ごとの確認と対策、AWS Site-to-Site VPN を相手にする場合の注意点を扱います。VPN を新しく構築する手順は別記事の範囲とし、ここでは「動いていた VPN が切れる」状態への対策に絞ります。

まず切断のパターンを記録する

設定を変える前に、何回か切断を観察して次の点を書き留めます。

• 切れた時刻と、復旧した時刻（自然に戻ったか、手動で再接続したか）
• 接続してから切れるまでの時間が毎回ほぼ同じか
• 切れた時間帯の通信量（夜間や休日など、通信がない時間か）
• 同じ時刻に回線の切断、ルーターの再起動、プロバイダーのメンテナンスがなかったか

接続から 1 時間後や 8 時間後のように「毎回同じ長さ」で切れるなら再キーの問題、通信がない時間に限って切れるならアイドル時の問題、と分けて考えると、以降の確認が速く進みます。

状態とログを確認する

strongSwan を swanctl で運用している場合、現在の SA（セキュリティアソシエーション）の状態は次のコマンドで確認できます。

# 確立している IKE_SA と CHILD_SA、再キーまでの残り時間など
sudo swanctl --list-sas

# 読み込まれている接続設定
sudo swanctl --list-conns

# ログをリアルタイムで表示（デーモンに接続して流す）
sudo swanctl --log

systemd 管理のログは journalctl で見られます。サービス名はディストリビューションや起動方式で異なり、swanctl 方式なら strongswan、従来の ipsec.conf 方式なら strongswan-starter などになっています（2026年10月現在）。systemctl list-units | grep -i strongswan で確かめてから指定してください。

sudo journalctl -u strongswan --since "2 hours ago"

ログでは、次のような語が手がかりになります。

• retransmit が続いた後に giving up after と出る: 相手から応答がなく、DPD や再キーの要求が届いていません。回線、NAT、ファイアウォールを疑います
• NO_PROPOSAL_CHOSEN: 暗号方式の組み合わせが合っていません。再キーのタイミングで出る場合は、後述する PFS の食い違いが典型です
• TS_UNACCEPTABLE: 通信するネットワークの範囲（トラフィックセレクター）が両側で一致していません
• AUTHENTICATION_FAILED: 事前共有鍵や証明書、ID の不一致です。切断ではなく再接続の失敗として現れることがあります

相手側の機器（ルーターやクラウドの VPN）のログも同じ時刻で突き合わせると、どちらが先に SA を削除したかが分かります。

原因1：通信がない時間に切れる（DPD・NAT のタイムアウト）

通信がしばらくないと、途中の NAT 機器やファイアウォールが UDP の対応表を破棄し、相手からのパケットが届かなくなることがあります。また、相手側の DPD（Dead Peer Detection、相手の生存確認）の設定によっては、無通信の状態を障害と判断して SA を削除します。

対策は、定期的に生存確認のパケットを流すことです。strongSwan では、接続ごとの dpd_delay で DPD の間隔を設定できます。NAT を越える場合（NAT-T、UDP 4500 番を使う構成）は、strongSwan が NAT の対応表を維持するための keepalive を送ります。間隔は strongswan.conf の charon.keep_alive で調整でき、既定では数十秒程度です。

それでも切れる場合や、相手側の機器が無通信時に SA を閉じる仕様の場合は、トンネル越しに定期的に ping を送る監視を入れると安定することがあります。監視のパケットは「切断に早く気づく」役割も兼ねるので、失敗時に通知する仕組みとあわせて設定すると運用が楽になります。

原因2：一定時間ごとに切れる（再キーの食い違い）

IPsec は一定時間ごとに鍵を作り直します（IKE_SA と CHILD_SA の再キー）。この時点で両側の設定が食い違っていると、接続直後は問題なく、最初の再キーで切れるという症状になります。

特に多いのが PFS（Perfect Forward Secrecy）の設定の食い違いです。IKEv2 では、最初の CHILD_SA は認証と同時に作られるため、ESP 側の Diffie-Hellman グループの設定は使われません。そのため、片側だけ PFS を有効にしていても接続はでき、再キーで初めて NO_PROPOSAL_CHOSEN になって切れます。ESP の提案（strongSwan の esp_proposals）に DH グループを含めるかどうか、どのグループを使うかを両側で揃えてください。

あわせて、両側の寿命（ライフタイム）を確認します。寿命が大きく違うと、片側が古い SA を削除した直後にもう片側が送信してパケットが失われることがあります。一般には、再キーを始める側の時間を相手の寿命より短くしておくと、切り替えがなめらかになります。

原因3：回線の切断や再起動の後に戻らない（自動再接続）

回線の一時的な切断、相手側ルーターの再起動、こちらのサーバーの再起動の後に VPN が戻らない場合は、再接続の設定が不足しています。strongSwan の swanctl では、起動時に接続を始める start_action、DPD で相手の応答がなくなったときの動作を決める dpd_action、接続の試行回数を決める keyingtries などで制御します。

次は、DPD と自動再接続を含む設定の例です。アドレス・ID・鍵・暗号方式は環境に合わせて書き換え、相手側の設定と一致させてください。事前共有鍵は推測されにくい十分な長さの値にし、設定ファイルの権限を root のみに絞ります。

# /etc/swanctl/conf.d/site-b.conf（例）
connections {
  site-b {
    version = 2
    local_addrs = 198.51.100.20
    remote_addrs = 203.0.113.10
    proposals = aes256-sha256-modp2048
    dpd_delay = 30s
    keyingtries = 0          # 0 は再試行の回数を制限しない
    local {
      auth = psk
      id = site-a.example.com
    }
    remote {
      auth = psk
      id = site-b.example.com
    }
    children {
      net {
        local_ts = 192.168.1.0/24
        remote_ts = 10.20.0.0/16
        esp_proposals = aes256-sha256-modp2048   # 相手と PFS の有無・グループを揃える
        start_action = start     # 起動時に接続を開始する
        dpd_action = restart     # 相手が応答しなくなったら張り直す
      }
    }
  }
}

secrets {
  ike-site-b {
    id = site-b.example.com
    secret = "your-pre-shared-key"
  }
}

設定を変える前に現在の設定ファイルをバックアップし、sudo swanctl --load-all で読み込み直します。両側が同時に再接続を始めると SA が重複することがあるため、どちらを主に接続を始める側にするかを決めておくと安定します。start_action や dpd_action に指定できる値は strongSwan の版によって変わった部分があるため、使っている版の swanctl.conf の公式ドキュメントで確認してください。

原因4：相手の IP アドレスが変わる・NAT 越しの経路

片側が動的 IP の回線で、アドレスが変わったタイミングで切れる場合は、固定 IP の回線にするか、IP ではなく ID（FQDN など）で相手を識別し、動的側から接続を始める構成にします。途中のファイアウォールでは、IKE の UDP 500 番、NAT-T の UDP 4500 番、NAT を越えない場合は ESP（IP プロトコル番号 50）を両方向で許可しているかを確認します。

切断に見える別の問題：MTU とフラグメント

「ping は通るのに、ファイル転送や Web の表示だけ途中で止まる」場合は、切断ではなく MTU の問題であることが多いです。IPsec はヘッダーを追加するため、元のパケットが大きいとトンネル内で分割が必要になり、途中で破棄されることがあります。トンネルを通る TCP の MSS を小さめに調整する（MSS クランプ）と改善します。値は暗号方式や回線で変わるので、まず次のように経路 MTU に合わせる方法から試します。

# 例: 転送される TCP の SYN で MSS を経路 MTU に合わせる
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

AWS Site-to-Site VPN を相手にする場合

AWS の Site-to-Site VPN は 1 つの接続に 2 本のトンネルがあり、AWS 側のメンテナンスでは片方ずつ更新されます（2026年10月現在）。1 本しか設定していないと、メンテナンスのたびに切断として現れるため、2 本とも設定し、経路の切り替え（BGP を使う構成なら自動、静的ルーティングなら機器側の設定）が動くことを確認します。トンネルのオプションには DPD のタイムアウトとその後の動作、接続を開始する側の指定などがあり、カスタマーゲートウェイ側の設定と揃える必要があります。無通信時にトンネルが落ちる場合の推奨事項も含め、項目名や既定値は AWS の公式ドキュメントで確認してください。

まとめ

• まず切れる時刻と間隔を記録し、無通信時・一定時間ごと・回線障害後のどれかに分ける
• swanctl --list-sas とログの retransmit、NO_PROPOSAL_CHOSEN、TS_UNACCEPTABLE などで原因を絞る
• 無通信で切れるなら DPD・NAT keepalive・監視 ping で生存確認を流す
• 一定時間ごとに切れるなら PFS（ESP 側の DH グループ）と寿命を両側で揃える
• 障害後に戻らないなら start_action、dpd_action、keyingtries で自動再接続を設定する
• 転送だけ止まる場合は MTU を疑い、MSS クランプで調整する

• IPsecとstrongSwanでサイト間VPNを構築する方法
• NAT越えで通信できないときの対処法