【テクニカル・上級編】 Internet Key Exchange Version 1 (IKEv1) のフェーズ2（クイックモード） – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

終わりの始まり、あるいは聖域の構築：IKEv1 クイックモードの深淵に触れる

VPNの設計に携わっていると、しばしば「なぜこのセッションが確立されないのか」という問いと向き合うことになる。特にIKEv1のフェーズ2、いわゆる「クイックモード（Quick Mode）」は、トラブルシューティングの墓場とも言える場所だ。

多くのエンジニアは「メインモードで鍵交換して、その後にクイックモードでIPsec SAを作るんでしょ？」と教科書通りの理解で止まっている。だが、その裏で何が起きているのか。パケットレベルの挙動と、現場で血を流しながら得たチューニングの知見を紐解いていこう。

IKEv1 クイックモード：保護されたチャネル内での「再交渉」

フェーズ1で確立されたIKE SA（ISAKMP SA）という名の「聖域」の中で、クイックモードは産声を上げる。ここでは、実際のデータプレーンを保護するためのIPsec SA（SPI: Security Parameter Indexを持つ双方向の鍵）が生成される。

クイックモードは、以下の3つのメッセージ交換で構成される。

1. 第一メッセージ（イニシエータ→レスポンダ）: 提案（Proposal）とnonce、そしてトラフィックセレクタ（ローカル/リモートサブネット）の提示。
2. 第二メッセージ（レスポンダ→イニシエータ）: 選択された提案とnonce、そしてIPsec SAのパラメータ確定。
3. 第三メッセージ（イニシエータ→レスポンダ）: 確認応答（ACK）。

この交換において、もし設定した Proxy-ID（ローカル/リモートネットワークの定義）が双方でビット単位まで一致しなければ、即座に暗闇の中へ消える。これが現場で最も頻発する「理由なき切断」の正体だ。

パフォーマンスのボトルネックとRTTの呪縛

WAN越しのIPsec構築において、クイックモードの完了までにかかるRTT（Round Trip Time）は、そのままVPNの「体感速度」に直結する。特に、IKEv1はUDP/500を叩くが、パケットロスが1%でもあればTCPのハンドシェイク以上に再送処理が足を引っ張る。

TCPバッファとMTUチューニングの最適解

IPsecはパケットにESPヘッダーを追加するため、必然的にペイロードサイズが減少する。MTUの計算を怠ると、断片化（Fragment）が発生し、LinuxカーネルのIPスタックで無駄なCPUサイクルを消費することになる。

現場で推奨されるのは、以下のカーネルパラメータの最適化だ。

# カーネルレベルでのTCP窓サイズ調整とMTU最適化
# ネットワークのスループットを最大化するためにバッファを拡張
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

# MSSクランプによるパケット断片化の回避
# 1400バイト程度に絞るのが安全。オーバーヘッドを考慮する
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

TCPMSS を設定することで、IPsecトンネル内でのパケット断片化を防ぐ。これは地味だが、高負荷時にパケットロス率が劇的に改善する鉄板のテクニックだ。

セキュリティの「死角」を塞ぐ：PFSという選択

IKEv1のクイックモードにおいて、最も議論されるのが PFS (Perfect Forward Secrecy) だ。

デフォルトのIPsec SA鍵は、フェーズ1の鍵から派生（導出）されることが多い。もしフェーズ1の鍵が漏洩すれば、過去にキャプチャしたすべてのパケットが解読されるリスクがある。これを防ぐのがPFSだ。クイックモードで再度Diffie-Hellman交換を行うことで、SAごとに鍵の独立性を担保する。

# StrongSwan (ipsec.conf) でのPFS設定例
conn enterprise-vpn
    ike=aes256-sha256-modp2048!      # フェーズ1: 強固な暗号化アルゴリズム
    esp=aes256-sha256-modp2048!      # フェーズ2: PFSを有効化 (modp2048でDH交換)
    pfs=yes                          # これが重要：SAごとに鍵を更新

この設定を投入すると、クイックモード内で再度DH計算が行われる。CPU負荷は増大するが、ゼロトラストの観点では「鍵の寿命を短くし、かつ独立させる」ことは譲れない防衛線だ。

トラブルシューティングの極意：ログの「先」を読む

もしクイックモードが失敗したら、まずは tcpdump でパケットをキャプチャし、ISAKMPヘッダーの Notify メッセージを探せ。

NO_PROPOSAL_CHOSEN: 提案不一致。暗号アルゴリズムか、Proxy-ID が食い違っている。
INVALID_ID_INFORMATION: セレクタの不一致。ACLのレンジを再確認せよ。

現代のインフラ構築では、IKEv1は「レガシー」の烙印を押されがちだ。しかし、ミッションクリティカルな環境では、依然としてIKEv1が稼働し続けている。フェーズ2の挙動を理解することは、単なる設定作業ではなく、暗号化の境界線がどう動いているかを可視化することに他ならない。

ネットワークエンジニア諸君、パケットは嘘をつかない。ログが語る不整合の理由を、カーネルの奥底まで潜って解明してほしい。そこには、教科書には載っていない「ネットワークの真実」が眠っているのだから。