IPsec (IP Security) #

IPsec (IP Security, RFC 4301 ほか) は 「IP パケットそのものを L3 で暗号化・認証する」 ための一連のプロトコル群である。TLS や SSH が「アプリごとに自分で上乗せする暗号」であるのに対し、IPsec は OS のネットワークスタックの中で IP の上に被さるため、TCP / UDP / ICMP どのアプリの通信も書き換えなしに守られる。これが「Site-to-Site VPN は IPsec が事実上の標準」「iPhone の Always On VPN も IPsec」と言われる理由になっている。

「IPsec」は単一プロトコルではなく AH / ESP / IKE という 3 つの登場人物の集合で、さらに Transport mode / Tunnel mode という 2 つの使い方、SA / SPD / SAD / SPI という状態管理の語彙が絡む。用語が多くて掴みにくいのは IPsec を学ぶときの最初の壁なので、本稿はその地図を先に描き、次に「実際にパケットがどう変形するか」と「IKE が 2 往復でどう鍵まで降りるか」という具体に降りる。VPN プロトコル全体の選定や WireGuard との比較は VPN 記事で扱っているので、ここでは IPsec の中身に集中する。

1. IPsec の地図 — 3 つのプロトコル #

IPsec を構成する主要プロトコルは 3 つあり、役割が綺麗に分かれている:

AH は現代ではほぼ使われない。理由は 2 つ — (1) NAT を通れない (送信元 IP も認証対象にしているため、NAT で IP を書き換えられると整合性が壊れる)。(2) 暗号化しないので AEAD ESP で暗号 + 認証を一括で済ませる現代設計と機能が被る。現代の IPsec = ESP + IKE と思っておけば、99% の場面で間違わない。

それぞれの SA (Security Association) — 「この方向のこの暗号ストリーム」 — は SPI (Security Parameter Index, 32-bit) で識別され、ESP ヘッダの先頭にこの番号が乗る。受信側はこの SPI を使って SAD (SA Database) を引き、「どの鍵で復号して、どの順序まで進んでいたか」を取り出す。

「この通信は IPsec で守るのか, 平文で出すのか, 落とすのか」という方針は SPD (Security Policy Database) に書く。SPD が「守れ」と言ったら、SAD から該当 SA を取り出し、なければ IKE を起動して新しく作る — というのが IPsec スタックの基本ループ。

2. 2 つのモード と ESP パケットの中身 #

IPsec の同じ ESP でも、何を暗号化するか によって Transport mode と Tunnel mode の 2 つの使い方がある。用途が違うだけでなく、できあがるパケットの形そのものが違う。

ポイント:

• Transport mode — 元の IP ヘッダはそのまま外を走り、TCP ヘッダから先だけが ESP の中に入って暗号化される。ホスト同士が直接喋る ときの形 (Windows ドメインの IPsec / L2TP の中身として使われる)。
• Tunnel mode — 元のパケット全体 (元の IP ヘッダ含む) を 新しい IP ヘッダで包む。新しい IP ヘッダは VPN GW 同士の宛先になるため、外から見ると「VPN GW 間の ESP 通信」しか見えない。これが VPN としての IPsec の本命。
• 暗号化範囲と認証範囲は別 — AEAD (AES-GCM, ChaCha20-Poly1305) を使えば 1 回で両方処理されるが、内部的には「暗号化はペイロード, 認証は ESP ヘッダ + ペイロード + トレーラ」という違いがある。
• ICV (Integrity Check Value) が末尾に付く。AEAD の 認証タグ で、ここが合わなければ受信側はパケットを黙って捨てる (改ざん検出)。

ESP のシーケンス番号は 再送・順序復元のためではない (それは中の TCP がやる)。リプレイ攻撃を防ぐためにあり、受信側は ウィンドウ内に来た番号しか受け付けない (RFC 4303 §3.4.3)。

3. SA / SPD / SAD / SPI — 状態管理の語彙 #

IPsec は 「鍵を握ったあと、その鍵をどう管理するか」 がプロトコルの半分を占めている。用語が一気に出るので一度整理する:

• SA (Security Association) — 片方向の暗号化ストリームの「契約」。鍵 / 暗号アルゴリズム / モード / シーケンス番号 / ライフタイムの塊。双方向通信なら 2 つの SA が必要 (送信用と受信用)。
• SPI (Security Parameter Index) — SA を識別する 32-bit 番号。ESP ヘッダの先頭 に乗る。受信側はこれで「自分宛のどの SA か」を引く。
• SAD (Security Association Database) — 現在張られている SA の一覧と内部状態。Linux なら ip xfrm state で覗ける。
• SPD (Security Policy Database) — 「送信元 X / 宛先 Y / プロトコル Z の通信は IPsec で守れ / 平文で出せ / 落とせ」のルール表。Linux なら ip xfrm policy。

実際の流れを 1 セッション分で追うと:

1. アプリが 10.0.0.5 → 10.0.0.20 に TCP/443 で送信
2. カーネルが SPD を引く → 「この通信は protect」
3. SAD にマッチする SA があるか? → なければ IKE を呼ぶ
4. IKE が相手と鍵交換 → 完了したら 2 つの SA を SAD に登録
5. 送信側 SA でパケットを ESP にカプセル化 → 送信
6. 受信側はパケットの SPI で SAD を引く → 鍵を取り出して復号 → 順次 SPD で「これは正当か」を再チェック

# Linux で現在の SA / SP を見る (ip-xfrm)
sudo ip xfrm state                    # SAD (鍵・SPI・暗号 alg・seq#)
sudo ip xfrm policy                   # SPD (どの通信を IPsec で守るか)

# strongSwan の状態確認
sudo swanctl --list-sas               # IKE_SA と Child_SA の現在状態
sudo swanctl --list-conns             # 設定された接続定義

ip xfrm state で出てくる spi, auth/encrypt alg, replay-window, lifetime が、上で説明した SAD のフィールドそのもの。「IPsec が繋がっているのに通信が流れない」 ときは、SPD と SAD の片方しか張れていない か 方向が片方しか合っていない という診断パスがほとんどここに落ちる。

4. IKEv2 のハンドシェイク — 2 往復で鍵にたどり着く #

IKE (Internet Key Exchange) は IPsec の中で 鍵を握る役割。IPsec が現代の暗号要件を満たしながら使えているのは、第 2 版に作り直された IKEv2 (RFC 7296, 2014) のおかげ。たった 2 往復 (4 メッセージ) で IKE SA と Child SA (= ESP の鍵) まで揃う設計が、IKEv1 の冗長さ (Main Mode 3 往復 + Quick Mode 1.5 往復) を一掃した。

押さえどころ:

• 1 往復目 (IKE_SA_INIT) は平文 だが、DH 鍵交換だけで意味のある秘密情報は何も流れない。盗聴者が見られるのは「この組合せの暗号スイートを提案・受諾した」という事実だけ。
• 2 往復目 (IKE_AUTH) は暗号化済み ({...} で表記)。ここで初めて 「お前は誰か」 (ID + 証明書 + AUTH) と 「ESP の Child SA をこの暗号で張る」 が決まる。
• AUTH の中身: PSK の場合は「SK_pi(ハッシュ(共有メッセージ))」、証明書の場合は「秘密鍵で署名(ハッシュ(共有メッセージ))」。事前共有鍵モードでも、PSK そのものはネットワーク上に流れない。
• CREATE_CHILD_SA は IKE SA を流用して「鍵だけ更新」(rekey) や「別の通信範囲用に追加 Child SA を作る」場面で動く。IKE SA を毎回張り直さなくていいので長時間稼働の VPN に向く。

4.1 IKEv1 と IKEv2 — なぜ作り直したか #

IKEv1 (RFC 2409, 1998) は Main Mode 6 メッセージ + Quick Mode 3 メッセージ = 9 メッセージ で同じことをしていた。冗長だっただけでなく、IKEv1 には致命的な落とし穴があった:

• Aggressive Mode — Main Mode の代わりに 3 メッセージで済ませる「軽量」版。だが 「PSK の HMAC が平文で 1 往復目に乗る」 ため、PSK のオフライン辞書攻撃を許す。
• 設定の組合せ爆発 — 暗号 / DH group / 認証方式 / モード が独立に組み合わさり、ベンダー間の interop が地獄。
• NAT 越え が後付けで、実装ごとに振る舞いが違う。

IKEv2 はこれらを 「シンプルな 2 往復に統一 + NAT-T を仕様内に取り込む + メッセージごとに ID を付けて再送と消失を区別」 で一掃した。新規構築で IKEv1 を選ぶ理由はない が、Cisco ASA や古い Fortinet では IKEv1 が今も動いている ので、運用引継ぎで遭遇したら IKEv2 への移行を計画するのが正しい姿勢。

5. NAT-T — IPsec が NAT を通れない理由と回避 #

ESP は IP プロトコル番号 50 で動く。一方、家庭用ルータの NAPT (PAT) は TCP/UDP のポート番号でセッションを多重化 している。ESP には「ポート番号」という概念がない ため、NAPT は ESP セッションを正しく区別できず、1 つの ESP しか通せない / 全部潰れるということが起きる。

これを回避するのが NAT-T (NAT Traversal, RFC 3948):

1. IKE_SA_INIT の中で NAT-D ペイロードを交換 — お互いの IP ハッシュを送り合い、経路上で IP が書き換えられているかを検出
2. NAT が検出されたら、IKE 自体の通信先を UDP/500 → UDP/4500 に切替
3. ESP パケットを UDP/4500 で包んで送る (上の SVG の最下段)

これにより NAPT 越しでも 「外側 UDP のポート番号で多重化, 中身は ESP」 という形で複数セッションが共存できる。ファイアウォールに ESP 用の特別な穴を空けなくても、UDP/500 と UDP/4500 さえ通れば動く ことから、現代の IPsec 実装は基本 NAT-T を有効にしている (forceencaps=yes で常時 UDP encap という設定もよく使う)。

6. 認証方式 — PSK / 証明書 / EAP #

IKE_AUTH の AUTH ペイロードを何で計算するかで、認証方式が決まる。3 つあり、向き不向きが綺麗に分かれている:

Aggressive Mode + PSK の脆弱性 は IPsec 運用で最も古典的な落とし穴。攻撃者は IKE 提案の 1 往復目を盗聴 (場合によっては能動的にトリガー) するだけで、PSK のハッシュをオフラインで辞書攻撃できる。ike-scan -A でこのモードに弱い VPN GW を探し、psk-crack (or John the Ripper) で解析するのが古典手順。Main Mode (IKEv1) または IKEv2 を強制するだけで防げる。

# IKE GW のフィンガープリント / Aggressive Mode 検出 (権限あるネットワーク内のみ)
ike-scan -M <target>          # Main Mode で probe / 受諾 SA を表示 → ベンダー特定
ike-scan -A <target> -id=test # Aggressive Mode で probe → 応答が返れば PSK 抽出可能

7. 現実の場面 — どこで IPsec が動いているか #

IPsec は「企業の裏側にひっそり」というイメージだが、実際にはあらゆる場所で動いている:

• AWS Site-to-Site VPN — Customer Gateway (オンプレ) と AWS 側の Virtual Private Gateway / Transit Gateway を IKEv2 + IPsec ESP で結ぶ。AWS 側の対応暗号スイートは 公式ドキュメントに列挙されている
• Azure VPN Gateway / GCP Cloud VPN — 同じく IKEv2/IPsec が標準
• Apple iOS / macOS Always On VPN — 設定アプリの「VPN タイプ: IKEv2」がそのまま IPsec
• Windows AlwaysOn VPN — IKEv2/IPsec または SSTP (TLS) が標準オプション
• Cisco / Juniper / Fortinet / Palo Alto / Check Point — エンタープライズ FW の Site-to-Site は IKEv2/IPsec が事実上唯一の互換軸
• Linux 実装: strongSwan (現代の主流), libreswan (Red Hat 系のデフォルト), Linux カーネルの XFRM スタックがその下で動く

最小構成の strongSwan (swanctl.conf) — Site-to-Site の例:

connections {
    site-a-to-b {
        version = 2                         # IKEv2 強制
        local_addrs  = 192.0.2.10
        remote_addrs = 198.51.100.20
        proposals = aes256gcm16-sha384-modp3072
        local  { auth = pubkey; certs = my-cert.pem; id = a.example.com }
        remote { auth = pubkey;             id = b.example.com }
        children {
            net-net {
                local_ts  = 10.1.0.0/16
                remote_ts = 10.2.0.0/16
                esp_proposals = aes256gcm16
                start_action = trap         # 該当宛先への通信が来たら自動で起こす
            }
        }
    }
}

aes256gcm16-sha384-modp3072 の塊は 「AES-256-GCM (AEAD, 16-byte ICV) / SHA-384 / DH group 15 (3072-bit MODP)」 という意味。読み方を知っていると AWS / Cisco / Juniper のどの製品でも同じ語彙で設定できる。

8. 攻撃面と運用 — 2026 年の最低基準 #

IPsec は コンポーネントが多い ≒ 設定ミスの面が広い。よくある事故と現代の最低基準:

• IKE のフィンガープリント — ike-scan で ベンダーと IKE 実装が特定可能 (応答パターンや受諾する SA の優先順位で識別)。VPN GW を インターネット直結で晒す運用は、CVE が出た瞬間に世界中から探されると思っておく
• Aggressive Mode + PSK (前述) — 検出ツールが昔から豊富。今も古い VPN 装置には残っている
• 弱い暗号スイート / DH group — 3DES, MD5, SHA-1, DH group 1/2 (768/1024-bit MODP) は禁止。Logjam (2015) で 1024-bit MODP は国家規模で破れることが示された。最低 group 14 (2048-bit), 推奨 group 19 (P-256 ECDH) / 20 (P-384) / 21 (P-521)
• Cisco ASA CVE-2016-1287 — IKEv1 / IKEv2 の 未認証バッファオーバーフロー → RCE。CVSS 10.0、当時 数十万台が脆弱
• VPNFilter (2018) — ロシア系 APT がルータ系に仕掛けた MitM フレームワーク。ルータの IPsec/SSL 終端を握ると LAN 全体が見える ことを思い知らせた事件
• PSK の運用 — メールやチャットで配布された PSK は漏れていると思って扱う。全 peer が同じ PSK なら、1 拠点の流出で全部詰む。peer ごとに別 PSK か 証明書ベースへ移行
• Dead Peer Detection (DPD) を有効に — 相手が落ちたとき SA を掃除しないと、ゴミの SA が残って再接続できない問題が起きる
• ログ — IKE のネゴシエーション失敗は「何の暗号で提案して何で蹴られたか」がログに出る。これを読めるかどうかが運用力を決める

2026 年時点の最低構成: IKEv2 + AES-256-GCM (or ChaCha20-Poly1305) + DH group 15 以上 (or P-384 ECDH) + 証明書ベース認証 + PFS 必須 + DPD 有効 + Aggressive Mode は完全無効。これを満たしていない既存トンネルがあれば、計画的に移行する。

IPsec は 「IP の上に L3 で乗る暗号化レイヤ」 という発想を、ESP と IKEv2 という 2 つの現代版に絞れば、見た目ほど複雑なものではない。Tunnel mode の ESP + IKEv2 の 2 往復ハンドシェイク + UDP/4500 NAT-T がほぼ全ての現実の場面で起きていることで、SA / SPD / SAD / SPI はその状態を持つ語彙にすぎない。

WireGuard が 「設定の単純さ」 で IPsec を置き換えつつあるが、Site-to-Site の互換軸の厚さ と エンタープライズ機器の対応 で IPsec は依然として現役、特にクラウド事業者の VPN ゲートウェイは IKEv2/IPsec を標準として持ち続けている。プロトコルとしての寿命は、WireGuard と並走する形でまだ続くと見ていい。