IKEv2の裏側を覗く：CREATE_CHILD_SAとINFORMATIONAL交換が支える強靭なIPsecトンネルの正体
インフラエンジニアなら誰もが一度は頭を悩ませるIPsec VPNの構築とトラブルシューティング。
「Phase 1はサクッと上がったのに、なぜかトラフィックが流れない」「数時間放置すると、気づいたらトンネルがデッドになっている」――そんな修羅場をくぐり抜けてきた読者なら、IKEv2（Internet Key Exchange Protocol Version 2）がいかに前身のIKEv1に比べて洗練されているかを痛感していることでしょう。
IKEv2の真骨頂は、ネゴシエーションの簡素化（SAの確立にかかるラウンドトリップ数の削減）だけではありません。トンネルが確立した“その先”の維持管理、すなわち「追加のセキュリティアソシエーション（Child SA）の動的な生み出し」と「沈黙するピアを見極めるLiveness確認（INFORMATIONAL交換）」において、バックグラウンドで緻密なドラマを繰り広げている点にあります。
今回は、パケットキャプチャの海を渡り歩いてきたシニアネットワークエンジニアの視点から、IKEv2の屋台骨を支える CREATE_CHILD_SA と INFORMATIONAL 交換のメカニズムを、現場のリアルな知見と共にお届けします。
—
1. IKEv2交換プロセスの全体像と、今回の主役たち
IKEv2は、初期のセキュリティアソシエーションを確立する IKE_SA_INIT と IKE_AUTH のペア（いわば「親の契り」）が終わると、すべての制御メッセージやデータ用のSA作成を、確立済みの暗号化チャネル（IKE SA）の内部で行うようになります。
ここで登場するのが以下の2つの交換（Exchange）です。
1. CREATE_CHILD_SA 交換: 既存のIKE SAを親として、新しいIPsec SA（Child SA）を追加作成、あるいは既存のIKE SA自体のリキーイング（Rekeying）を行う。
2. INFORMATIONAL 交換: トンネルの生存確認（Liveness / DPD）、エラー通知、SAの削除（DELETE）など、運用管理の雑務をすべて引き受ける。
これらがネットワーク上でどのように振る舞うのか、実務的な設定例とともに深掘りしていきましょう。
—
2. CREATE_CHILD_SA: トンネルの中にトンネルを紡ぐ仕組み
マルチクラウド環境（AWSのVPCとオンプレミスのデータセンターなど）を接続していると、複数の異なるサブネット間ルーティングをひとつのIKE SA配下でさばきたくなるシチュエーションに出くわします。また、暗号化の鍵（Key）を一定時間やデータ転送量で定期的に更新する「リキーイング」は、セキュアな通信を維持する上で避けて通れません。
これらを担うのが CREATE_CHILD_SA です。
通信シーケンスのリアル
ピア間で新しいChild SAが必要になると、 initiator（仕掛け人）側から CREATE_CHILD_SA リクエストが飛びます。
Initiator Responder
| |
|--- HDR, SA, Ni, TSi, TSr -> | (新しいChild SAの提案、乱数、トラフィックセレクタ)
| |
|<- HDR, SA, Nr, TSi, TSr --- | (応答、承認、乱数、トラフィックセレクタ)
| |ここで渡される TSi（Traffic Selector Initiator）と TSr（Traffic Selector Responder）が肝心です。ここに「どの送信元IPから、どの宛先IP・ポートへ向かうトラフィックをこのChild SAで保護するか」というルールが明記されます。
StrongSwan (libreswan) での設定例
実際のLinuxルーター（StrongSwan等）における ipsec.conf の設定を覗いてみましょう。ここで定義されたトラフィックセレクタが、のちに CREATE_CHILD_SA によって動的にネゴシエーションされます。
# /etc/ipsec.conf の設定例
conn aws-to-onprem
auto=start
keyexchange=ikev2
left=203.0.113.10 # 自拠点のグローバルIP
leftid=203.0.113.10
leftsubnet=192.168.100.0/24 # 自拠点のプライベートサブネット
right=198.51.100.20 # クラウド側のゲートウェイIP
rightid=198.51.100.20
rightsubnet=10.0.0.0/16 # クラウド側のプライベートサブネット
ike=aes256gcm16-prfsha384-ecp384!
esp=aes256gcm16-ecp384! # IPsec SA（Child SA）の暗号アルゴリズム
lifetime=1h # Child SAのリキーイング間隔現場のTIPSとして、クラウド側とオンプレ側でサブネットの定義（leftsubnet / rightsubnet）が1bitでもズレていると、CREATE_CHILD_SA の段階で TS_UNACCEPTABLE エラーを吐いて華やかに沈没します。ログ（journalctl -u strongswan など）でこのエラーを見かけたら、双方のルーティングとトラフィックセレクタを真っ先に疑ってください。
—
3. INFORMATIONAL 交換: ゾンビ接続を防ぐ番人
「夜間バッチが走り出すとなぜかVPNが切断される」「回線が一時的に瞬断した後、いつまで経ってもVPNが復旧しない」。
こうしたインフラエンジニアの悪夢の多くは、死んだはずのピアが生きていると勘違いし続ける「半死半生のゾンビ状態（Half-Open SA）」が原因です。
IKEv2の INFORMATIONAL 交換は、こうしたトラブルを未然に防ぐためのLiveness（生存確認）機能（Dead Peer Detection: DPD）や、セッション切断時のDELETEペイロードの送信を担っています。
通信シーケンスのリアル
通信がないアイドル状態が続くと、ルーターは相手がまだ生きているか確認するため、空っぽの（あるいは空に近い） INFORMATIONAL リクエストを投げます。
Initiator Responder
| |
|--- HDR, [N(NOTIFY: SESSION_REESTABLISHED)] ----> | (生存確認や削除通知)
| |
|<- HDR [Empty] ------------------------------------| (応答：生きてまっせ)
| |もし、この INFORMATIONAL リクエストに対して一定回数（例: 3回リトライ）、一切の応答がない場合、StrongSwanなどのデーモンは「相手は死んだ」と断定し、古いIKE SAおよびChild SAを強制破棄して再接続シーケンスに移行します。
また、意図的にVPNを切断する場合も、この INFORMATIONAL 交換の中で DELETE ペイロードを相手に送りつけます。これによって、無駄なタイムアウトを待たずに即座にリソースが解放されるため、お行儀の良いクリーンナップが可能になります。
—
4. 実務で役立つデバッグとパケット解析の勘所
現場でIPsecの挙動が怪しいとき、シニアエンジニアが真っ先に開くのは tcpdump や Wireshark です。IKEv2は標準でUDPポート501（NAT-Tの場合はUDP 4500）を使用するため、次のようなコマンドでパケットの往来をキャプチャします。
パケットキャプチャのコマンド例
# UDP 500番ポート（IKE）のパケットをリアルタイムでキャプチャし、ASCIIで覗き見する
sudo tcpdump -i eth0 -nnvvXs 0 udp port 500Wiresharkで解析する際のフィルター例も覚えておくと便利です。
- IKEv2のメッセージ種別を絞り込むフィルタ:
ikev2 - CREATE_CHILD_SAを見たいとき:
ikev2.exchange_type == 36 - INFORMATIONALを見たいとき:
ikev2.exchange_type == 37
Wiresharkのパケット詳細ツリーで Next Payload: Notify (41) や Exchange Type: INFORMATIONAL (37) が綺麗に見えていると、なぜかエンジニアとしてのドーパミンが分泌されますよね。もしここに何も流れていない、あるいはリクエストを投げているのに返答（ACK）がない場合は、OSのファイアウォール（iptables / nftables / firewalld）や、クラウド側のセキュリティグループ（UDP 500/4500の穴あけ忘れ）が犯人であるケースが9割です。
—
まとめ：仕組みを知れば、VPNトラブルは怖くない
今回は、IKEv2の裏側を支える CREATE_CHILD_SA と INFORMATIONAL 交換の役割について、実務の現場感を持ってお届けしました。
CREATE_CHILD_SAは、既存の信頼関係（IKE SA）をベースにして、新しいトラフィックのための暗号通路（IPsec SA）をダイナミックに増築・維持するためのもの。INFORMATIONALは、静寂なネットワークのなかでピアの脈拍を測り（Liveness）、不測の事態や切断時に迅速な後始末（DELETE）を行うためのもの。
この2つの交換が裏でいかにスマートに連携しているかを知っていれば、ログやパケットキャプチャを見た瞬間に「今、何が行われているのか（あるいはどこで詰まっているのか）」が手に取るように分かるはずです。
複雑怪奇に見えるプロトコルも、突き詰めれば「機械同士の丁寧な挨拶と生存確認」の積み重ね。ぜひ、皆さんの現場でのトラブルシューティングや設計の引き出しに役立ててください。
コメント