VPN障害ログを読む前に知っておくべき前提知識
エラーログの解析を始める前に、VPN障害がどのレイヤーで発生しているかを切り分けることが効率的な対応の出発点です。ログの量は多くても、着目すべき情報は決まっています。
障害レイヤーの切り分け方
VPN障害は(1)物理・回線レイヤー、(2)IPsec/IKEのネゴシエーションレイヤー、(3)ルーティング・ポリシーレイヤー、(4)認証・証明書レイヤーの四つに分類できます。まず疎通確認（pingやtraceroute、回線ステータス確認）で物理・回線レイヤーを切り分け、次にVPN機器のログでIPsec/IKEのフェーズを確認する順序を徹底することで、調査の深さを無駄なく制御できます。
障害発生時刻の前後5分を絞り込み、重要度が「ERROR」「CRIT」「ALERT」のエントリだけをフィルタする習慣をつけることで、本質的な手がかりを見落とすリスクを減らせます。syslogを外部サーバーに転送している場合は、grepや時刻フィルタを活用してください。
IKEフェーズ1とフェーズ2の役割と障害の違い
IPsecによるVPN接続はIKE（Internet Key Exchange）の二段階ネゴシエーションで確立します。フェーズ1ではVPN機器同士が認証を行い、制御用のセキュアチャネル（IKE SA）を構築します。フェーズ2ではそのチャネルを使ってデータ転送用のトンネル（IPsec SA）をネゴシエートします。フェーズ1で失敗するとそもそもトンネルが確立せず、フェーズ2で失敗すると制御チャネルは生きているのにデータが流れないという状況に陥ります。この違いをログで区別できると、調査の方向性が一気に絞り込まれます。
IKEv1とIKEv2ではログの出力形式が異なります。IKEv1はMain Mode/Aggressive Mode、IKEv2はIKE_SA_INIT/IKE_AUTHというメッセージ名で処理が進むため、機器のプロトコルバージョンを最初に確認してからログを読み始めることが重要です。
IPsecフェーズ別エラーコードの読み方と対処手順
IPsec/IKEの障害ログには固有のエラーコードや状態メッセージが出力されます。代表的なコードの意味と、それぞれに対応した復旧手順を押さえておくことで、ログを見た瞬間に行動に移れます。
フェーズ1で頻出するエラーコードと対処
フェーズ1で最もよく見られるのは「NO_PROPOSAL_CHOSEN」です。暗号化アルゴリズム（AES/3DES）・ハッシュアルゴリズム（SHA-256/SHA-1）・DHグループのいずれかが両端で一致していないことを示します。両端のIKEポリシーを照合して統一し、変更作業はメンテナンスウィンドウを設けて実施してください。
「AUTHENTICATION_FAILED」はPSKの不一致・証明書の有効期限切れ・CRL取得失敗を示します。PSK確認時はコピー&ペースト時の末尾空白混入に注意し、証明書認証ではCRL配布ポイントへのアクセス経路も確認します。「INVALID_ID_INFORMATION」はIDタイプ（FQDN・IPアドレス等）の不一致で発生し、両端のIKEアイデンティティ設定を照合することで解消できます。
フェーズ2で頻出するエラーコードと対処
フェーズ2では「TS_UNACCEPTABLE」（トラフィックセレクタの不一致）が多く見られます。これは、保護するIPアドレス範囲やポート番号の設定（セキュリティポリシー）が両端で一致していない場合に発生します。対処は、双方のフェーズ2ポリシーでローカル・リモートのサブネット定義を突き合わせて一致させることです。
「CHILD_SA_FAILED」はフェーズ2の再確立に失敗したことを示します。フェーズ1のSAが有効でもフェーズ2のライフタイムが先に切れて再ネゴシエーションに失敗するケースがあります。この場合、両端のフェーズ2ライフタイム（バイト数または時間）を確認し、一方がより短い値で設定されていないか照合します。また「INVALID_KE_PAYLOAD」はPFS（Perfect Forward Secrecy）のDHグループが不一致の際に出るコードで、フェーズ2のPFS設定を両端で統一することで解消します。
VPN切断時の優先確認項目と段階的な復旧手順
障害発生時は推測で設定変更を始める前に、状態確認を順序立てて行うことが重要です。変更前後で状態が変わらなければ切り戻しのコストが増えるだけです。
ステップバイステップの状態確認手順
VPN切断が報告されたら、まず(1)回線疎通の確認（メイン回線・バックアップ回線それぞれにping）、(2)VPN機器のIKE SAおよびIPsec SAの確立状態確認（showコマンドまたは管理画面）、(3)エラーログの時刻フィルタリングと重要度別抽出、の三段階を順に実施します。(2)でSAが確立されているのにトラフィックが通らない場合は、ルーティングやファイアウォールポリシーの問題である可能性が高いため、ネットワークレイヤーに調査の焦点を移します。
SAの確認コマンドは機器ベンダーによって異なります。Cisco IOS系では「show crypto isakmp sa」や「show crypto ipsec sa」、FortiGateでは「diagnose vpn ike gateway list」や「diagnose vpn tunnel list」などが代表的です。管理画面でも確認できますが、CLIの方がより詳細な情報が得られるため障害時はCLIを優先してください。
SAクリアとトンネル再確立の実施手順
SAがPartialやエラー状態の場合はSAをクリアして再確立を試みます。Cisco IOS系では「clear crypto isakmp」（フェーズ1）と「clear crypto sa」（フェーズ2）、FortiGateでは「diagnose vpn ike restart」が利用できます。SAクリアは接続を一時的に断ち切るため、業務影響を確認して実施し、作業前後の時刻を記録してください。
SAをクリアしても再確立しない場合は、フェーズ別エラーコードの確認に戻ります。再確立後も数分で再切断される場合は、DPDタイムアウト設定・中間ファイアウォールによるUDP500/4500のブロック・NATトラバーサルの未設定を疑い、一つずつ切り分けてください。
ITトレンドでは、最新の製品・サービスを多数比較・掲載しています。まず資料を取り寄せて機能や特徴をさまざまな製品で比較してみてください。忙しい業務時間内でも、各社に問い合わせる手間なく、たった1回の入力（約60秒）でVPNの一括資料請求が可能です。浮いた時間で、じっくりと製品を比較検討し進めましょう。
フェイルオーバー切替後のIPsec再確立と動作検証
フェイルオーバー後も送信元IPアドレスが変わるためIPsec SAの再ネゴシエートが必要になり、VPNトンネルが自動再確立されないケースが発生します。
フェイルオーバー後にトンネルが再確立されない原因
バックアップ回線切替後にVPNが復旧しないケースで多いのは、(1)バックアップ側IPアドレスがVPN設定（ピアアドレス・IDタイプ）に反映されていない、(2)MTUサイズの差異でIKEパケットが断片化・ドロップされる、(3)バックアップ側ISPがUDP500を制限しているという三点です。MTU問題はMSS ClampingやMTU値の調整、Path MTU Discoveryの確認などで対処できます。
ルーターがフェイルオーバー後もメイン回線のルーティングエントリを優先し続ける「ルーティングの残留」が原因になるケースもあります。デフォルトルートが切り替わらない場合は静的ルートの距離値（Administrative Distance）やフローティングスタティックルートの設定を見直してください。動的ルーティング（OSPF・BGP）環境では障害検知タイマーの値がフェイルオーバー速度に直結するため、設定値を記録しておくことが重要です。
フェイルオーバー後の動作確認チェックリスト
フェイルオーバー完了後は(1)バックアップ回線のデフォルトルートが有効か、(2)IPsec SAがバックアップ側IPで再確立されたか、(3)業務システムへのログインなど実通信が正常か、の三点を順に確認します。(3)でエラーが出る場合はファイアウォールポリシーにバックアップ側IPが追加されていないケースが多く見られます。
定期的なフェイルオーバーテストでは、切替完了までの時間と切り戻し時間を計測して記録します。テストはファームウェア更新後やネットワーク構成変更後にも実施し、結果を担当者間で共有することで次回の障害対応速度を上げられます。
監視アラート設定とNTPログ管理で障害を早期検知する
障害が起きてから対応するだけでなく、兆候を早期に捉えてプロアクティブに動けるかどうかが、運用品質を左右します。監視アラートの設計とNTPを軸としたログ管理の整備が不可欠です。
VPN監視で設定すべきアラートの種類と閾値
VPN監視で最低限設定すべきアラートは、(1)IPsec SAのダウン検知、(2)VPN機器のCPU・メモリ使用率閾値超過（80%警告・90%クリティカル）、(3)回線帯域使用率（90%警告）、(4)フェイルオーバー発生検知の四つです。SNMPトラップやsyslogをZabbixやDatadog等の監視ツールで収集し、閾値超過時にメールやチャットへ通知する仕組みを構築します。
DPDの失敗イベントも監視ポイントに加えると、トンネル切断の予兆を早期に捉えられます。「5分以内に3回以上DPD失敗」のような条件をアラートルールに組み込むことで、誤検知を減らしながら早期検知の精度を維持できます。
NTP時刻同期とログ集約で障害調査を高速化する
複数の機器ログを突き合わせてエラー原因を追う際、機器間の時刻ずれがあるとタイムラインの再構成が正確にできません。すべての機器で同一のNTPサーバーを参照させ、NTP通信（UDP 123番）がファイアウォールでブロックされていないかを確認し、時刻同期の成否を監視アラートに含めることが基本です。
ログは各機器に分散させず、syslogサーバーやSIEMに集約することで横断的な検索と相関分析が可能になり、調査効率が向上します。保管期間は最低でも3か月分を即時参照できる状態に維持し、書き込み専用ストレージや署名付きログなど改ざん防止策を講じるとインシデント調査時の証拠としての信頼性も高まります。
VPN障害対応に関するよくある質問（FAQ）
VPN障害対応の実務で寄せられることの多い疑問をまとめました。設定見直しや運用フロー整備の参考にしてください。
- ■Q1：「NO_PROPOSAL_CHOSEN」が出た場合、どこから調べればよいですか？
- 両端のVPN機器でIKEフェーズ1のポリシーを確認し、暗号化アルゴリズム・ハッシュアルゴリズム・DHグループの三点が一致しているかを照合してください。IKEv1とIKEv2のバージョン混在でも同エラーが出るため、プロトコルバージョンの一致も確認します。ファームウェアバージョンによってデフォルト値が異なる場合があるため、マニュアルで推奨値を確認することも重要です。
- ■Q2：フェイルオーバー後にVPNトンネルが再確立されない場合、最初に確認すべきことは何ですか？
- バックアップ回線側のIPアドレスでVPN機器のピアアドレス設定が更新されているかを確認してください。次に、MTU値の差異によりIKEパケットが断片化してドロップされていないかをパケットキャプチャで確認します。UDPポート500と4500がバックアップ回線側のファイアウォールで許可されているかも合わせて確認してください。
- ■Q3：ログの時刻がずれていてエラーの前後関係が分からない場合、どう対処すればよいですか？
- 各機器のNTP設定を確認し、参照NTPサーバーのアドレスと同期ステータスを確認してください。UDP 123番ポートがファイアウォールでブロックされていないかも確認します。応急処置として各機器のズレ量を手動記録してログ時刻を補正し、恒久対策として全機器で同一NTPサーバーを設定して時刻同期の成否を監視アラートに追加することで再発を防ぎます。
まとめ
VPN障害対応では、エラーログのフェーズ別読み方・段階的な状態確認・フェイルオーバー後のIPsec再確立・監視アラートとNTPログ管理の四つを整備することが重要です。「NO_PROPOSAL_CHOSEN」「AUTHENTICATION_FAILED」「TS_UNACCEPTABLE」など代表的なエラーコードの対処手順を事前に把握しておくことで、障害時の初動速度が変わります。定期的なフェイルオーバーテストとログ集約環境の整備を進め、迅速に復旧できる運用体制を構築してください。
