IPsecの心臓部を暴く：IKEv1 フェーズ2（クイックモード）の全貌と現場のトラブルシューティング
こんにちは。ネットワークとセキュリティの現場を渡り歩いてきたシニアエンジニアの私です。
これまで幾度となく、クラウドとオンプレミスを繋ぐ拠点間VPNの構築や、深夜の障害対応に立ち会ってきました。「なんだかVPNのトンネルが上がらない」「IKEフェーズ1は通るのに、肝心のデータが流れない」。そんな修羅場でエンジニアたちが頭を抱える原因の多くは、今回解説するIKEv1 フェーズ2（クイックモード：Quick Mode）のネゴシエーションミスにあります。
教科書を開けば「フェーズ1で確立したISAKMP SA上で、IPsec SAを確立するプロセス」と一言で片付けられますが、パケットキャプチャの生データや実際のルーターの設定ファイルを見ると、そこには暗号アルゴリズムの不一致や、プロポーザルのすれ違いといった「泥臭い現実」が広がっています。
今回は、Web API設計やインフラ運用でネットワークの底支えを意識せざるを得なくなったエンジニアの皆さんに向けて、IKEv1フェーズ2の仕組みを丸裸にし、実務で即戦力となる設定例やデバッグ手法を伝授しましょう。
—
1. なぜ「クイックモード」が必要なのか？（フェーズ1との違い）
私たちがセキュアなIPsecトンネルを通すとき、通信は2つのステップを踏みます。
1. IKEv1 フェーズ1（メインモード / アグレッシブモード）
- 目的：お互いの機器が「信頼できる相手か」を確認し、制御用の安全なトンネル（
ISAKMP SA）を掘る。
2. IKEv1 フェーズ2（クイックモード）
- 目的：実際にユーザーのデータ（パケット）を暗号化して流すための実データ用トンネル（
IPsec SA）を確立する。
フェーズ1で築いた強固な要塞（ISAKMP SA）の内部を通る形で、クイックモードのメッセージがやり取りされます。すでに暗号化と認証が完了しているチャネルの上で動くため「クイック」と呼ばれるわけですが、実務ではこのクイックモードのパラメータ一致が非常にシビアです。
—
2. クイックモードの通信フロー（3メッセージ交換の裏側）
クイックモードは、 initiator（発信側）と responder（応答側）の間で、計3つのメッセージ（Message 1 〜 Message 3）が交換されて完了します。
[Initiator] [Responder]
| |
|--- (1) HASH, SA, Ni, [IDci, IDcr] ------>| ※プロポーザル提示 ＆ 乱数生成
| |
|<-- (2) HASH, SA, Nr, [IDci, IDcr], SPI --| ※プロポーザル合意 ＆ 鍵素材生成
| |
|--- (3) HASH ---------------------------->| ※確認応答（これ以降IPsec通信開始）
| |各メッセージの役割を、現場のパケットキャプチャを見る視点で紐解いてみましょう。
Message 1（Initiatorからの提案）
発信側は、フェーズ1ですでに共有されている鍵素材と、今回新たに生成した乱数（Ni）を混ぜ合わせ、以下の情報を暗号化して送信します。
- SA（Security Association）プロポーザル: どんな暗号アルゴリズム（AES-GCMやAES-256など）やハッシュ（SHA-256など）を使うかの一覧。
- IDci / IDcr: 通信を許可するトラフィックの識別子（セレクター）。「どこのネットワークからどこのネットワークへ通信を通したいか」というサブネット情報（例:
192.168.10.0/24から10.20.30.0/24）が含まれます。
Message 2（Responderからの承諾と返答）
応答側は、受け取ったプロポーザルの中から自分がサポートできる最適なものを一つ選び、自身の乱数（Nr）と、IPsec SAを一意に識別するための SPI（Security Parameter Index）を添えて返します。
Message 3（Initiatorの確認）
発信側が最終的な確認ハッシュ（HASH）を返すと、両者の中で IPsec SA が生成され、いよいよ実際のトラフィックが暗号化されて流れ始めます。
—
3. 実務で直面するパラメーターの罠と設定例
インフラ運用において、IKEv1フェーズ2が失敗する原因の9割は「パラメータのミスマッチ」です。ここでは、Cisco IOSルーターを例に、実務でそのまま使える堅牢な設定サンプルを見てみましょう。
Cisco IOSにおけるIPsec（IKEv1）設定例
! --- 1. IPsec Transform Set（フェーズ2の暗号・認証方式の定義） ---
! 暗号にAES-256、整合性確認にSHA-256を使用する（ESPトランスポート/トンネルモード）
crypto ipsec transform-set MY-TRANSFORM-SET esp-aes 256 esp-sha256-hmac
mode tunnel
! --- 2. アクセスリスト（興味深いトラフィック / Interest Traffic の定義） ---
! このACLにヒットする通信を検知した瞬間にクイックモードがトリガーされる
ip access-list extended VPN-TRAFFIC-ACL
permit ip 192.168.10.0 0.0.0.255 10.20.30.0 0.0.0.255
! --- 3. Crypto Map（フェーズ1、フェーズ2、ピアを紐付ける設定） ---
crypto map MY-CRYPTO-MAP 10 ipsec-isakmp
set peer 203.0.113.50 ! 対向先のパブリックIPアドレス
set transform-set MY-TRANSFORM-SET
match address VPN-TRAFFIC-ACL
! インターフェースへの適用
interface GigabitEthernet0/0
crypto map MY-CRYPTO-MAP運用時の重要ポイント：ライフタイム（Lifetime）の罠
フェーズ2のパラメータには、暗号鍵の有効期限（ライフタイム）を設定する項目があります。
- 時間ベース（例:
86400秒（24時間）） - データ量ベース（例:
4608000KB）
【実務のTips】
クラウドサービス（AWS VPNやAzure VPN Gatewayなど）とオンプレミスルーターを接続する場合、AWS側が強制するライフタイム（例: フェーズ2は3600秒など）と、オンプレ側が無期限やデフォルト（86400秒）のままでズレが生じ、「1時間経つとピタッと通信が途絶え、しばらくすると勝手に復旧する」という嫌らしいトラブルがよく起きます。両者のライフタイム設定は必ず一致させましょう。
—
4. 現場で役立つデバッグ手順とトラブルシューティング
夜間作業中、VPNがどうしても繋がらないとき、シニアエンジニアは何を見るべきでしょうか。コマンドの実行例を交えて解説します。
ステップ1: フェーズ1が本当に健全か確認する
フェーズ2はフェーズ1の上でしか動きません。まずは ISAKMP SA が QM_IDLE（安定状態）になっているか確認します。
Router# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
203.0.113.50 198.51.100.10 QM_IDLE 1 ACTIVE*state が QM_IDLE になっていなければ、フェーズ1（メインモード等）の事前共有鍵（PSK）やアドレス設定に誤りがあります。*
ステップ2: クイックモードのネゴシエーションログを採取する
Cisco機であれば、リアルタイムでIKEの挙動を追うためにデバッグを有効にします。
Router# debug crypto ipsec
Router# debug crypto isakmpコンソールに流れるログの中で、以下のようなエラーが出た場合の対処法です：
NO-PROPOSAL-CHOSENが返される場合- 原因: 自局と対向局で、暗号化アルゴリズム（AESや3DES）やハッシュ関数（SHA-1, SHA-256）、あるいはPFS（Perfect Forward Secrecy）の有効/無効の組み合わせが食い違っています。両者の
Transform-setを1字一句見直してください。 IPsec SA establishedと出るのに通信が流れない場合- 原因: プロポーザルは一致したものの、プロキシID（暗号化対象のサブネット範囲）が対向側と鏡写し（逆転）になっていません。オンプレの送信元/宛先と、クラウド側のルーティング/ポリシーベースVPNの設定値が正しく対になっているか確認しましょう。
—
5. おわりに：ゼロトラスト時代のIPsecの立ち位置
現代のゼロトラストアーキテクチャにおいては、社内ネットワーク全体を信頼するのではなく、アプリケーションやユーザー単位でアクセス制御を行うのが主流です。しかし、異なる企業間を安全に結ぶB2B通信や、クラウドとオンプレミスを堅牢に直結する基盤として、IPsec VPN（そしてその根幹を支えるIKEv1/IKEv2）は今なお現役バリバリの基幹技術です。
「なぜパケットが弾かれているのか」「どのパラメータの食い違いが原因なのか」。
仕組みの本質を理解していれば、目の前のブラックボックスだったルーターが、まるで自分の身体の一部のように見えてくるはずです。
皆さんのインフラ運用・ネットワーク構築の現場が、少しでもスムーズになることを願っています。それでは、また次回の技術コラムでお会いしましょう！
コメント