IPsec とは — トンネル/トランスポートモードと IKE 鍵交換 のサムネイル

IPsec とは — トンネル/トランスポートモードと IKE 鍵交換

⏱ 約 17 分 view 159 like 0 LOG_DATE:2026-05-10
目次 / TOC

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」と言われる理由。本稿は AH / ESP / IKE / Transport / Tunnel / SA・SPD・SAD・SPI / IKEv2 / NAT-T / 認証 / 攻撃面 を順に整理する。

▸ ネットワーク初学者へ — まずこの 3 つだけ

難しく見えても本質は次の 3 つだけ。(1) IPsec は 「OS のネットワークの足元で動く、丸ごと暗号化の仕組み」。HTTP や SSH が自分で暗号化するのではなく、下の IP 層が全部包んでくれるので、アプリは何も知らずに暗号化される。(2) 拠点と拠点をつなぐ 「会社のサーバ同士の専用線」(Site-to-Site VPN) や、iPhone の Always On VPN として、現代でも事実上の標準。(3) 中身は 「ESP (封印して運ぶ)」+「IKEv2 (鍵を渡し合う)」の 2 役だけ覚えれば、9 割の場面はカバーできる。— ここを土台に各章を順に開いていけばいい。

01

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

IPsec は単一プロトコルではなく AH / ESP / IKE という 3 つの登場人物の集合。役割が綺麗に分かれている。

▸ かみ砕いて言うと — 3 つの登場人物は「配達会社の役割分担」

IPsec の 3 人組は、宅配会社の役割分担とそっくり。AH = 改ざんチェック担当 (中身は読めるけど開封済みかは分かる、現代ではほぼ廃止)。ESP = 暗号化封筒に入れる担当 (中も外も見せず、改ざんも検出する。現代の IPsec の主役)。IKE = 鍵を渡し合う代理人 (実際の荷物を運ぶ前に、両方の倉庫の鍵を電話で交換する)。覚えるべきは 「現代 = ESP + IKEv2」の 2 人だけ、と頭に入れておけばよい。

略号 正式名 役割 プロトコル番号 / ポート
AH Authentication Header (RFC 4302) 認証 + 完全性のみ (暗号化なし) IP プロトコル 51
ESP Encapsulating Security Payload (RFC 4303) 暗号化 + 認証 + 完全性 IP プロトコル 50
IKE Internet Key Exchange (RFC 7296, IKEv2) 鍵交換 + 認証 + SA 管理 UDP 500 (NAT-T 時 4500)
▸ 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 スタックの基本ループ。

02

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

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

▸ かみ砕いて言うと — 「中身だけ封筒」vs「箱ごと封筒」

2 つのモードの違いは、宅配で言えば 「中身だけビニールでパッキングして発送する」か 「箱まるごと新しいダンボールに入れて発送する」かの違い。Transport mode = 中身だけ封印 → 外側の宛先 (元の IP) は丸見え。同じ会社内のサーバ同士のような 「ホスト ↔ ホスト直結」で使う。Tunnel mode = 箱ごと封印 → 外からは 「VPN GW から VPN GW へ何か送ってる」しか見えない。これが VPN としての IPsec の本命で、Site-to-Site も iPhone の Always On VPN もこっち。迷ったら Tunnel と覚えればよい。

元のパケット → Transport mode → Tunnel mode → NAT-T
# 元のパケット (IPsec を通す前) [ IP hdr 10.0.0.5→.20 ][ TCP hdr 443 ][ App data ]

# Transport mode — 元の IP hdr はそのまま, ペイロードだけ ESP で包む # 用途: ホスト ⇔ ホスト の point-to-point (L2TP/IPsec の中, Windows AuthIP) [ IP hdr (proto=ESP) ][ ESP hdr SPI/Seq ][ TCP hdr + App data (暗号化) ][ ESP trailer ][ ICV ] ▲ 認証範囲: ESP hdr 〜 ICV 直前 / 暗号化範囲: TCP hdr + App data + trailer

# Tunnel mode — 元のパケット全体を新しい IP hdr で包む (= VPN の本命) # 用途: Site-to-Site VPN, リモートアクセス VPN [ 外側 IP hdr GW→GW ][ ESP hdr ][ 元の IP hdr + TCP hdr + App data (暗号化) ][ ESP trailer ][ ICV ] ▲ 外から見ると「VPN GW 同士の ESP 通信」しか見えない

# NAT-T 時 — ESP を UDP で包む (NAT 越え用, RFC 3948) [ 外側 IP (proto=UDP 17) ][ UDP hdr dst=4500 ][ ESP packet (= 上の Tunnel mode 全体) ]

ポイント:

  • 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 シーケンス番号の本当の役割

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

03

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

IPsec は「鍵を握ったあと、その鍵をどう管理するか」がプロトコルの半分を占めている。

▸ かみ砕いて言うと — 4 つの用語は「契約書 / ルール集 / 名簿 / 番号札」

SA / SPD / SAD / SPI と頭文字略号が並ぶと圧倒されるが、中身は事務的なもの。SA = 「この方向のこの暗号で運ぶ」という 1 回ごとの契約書 (双方向通信なら送信用と受信用で 2 通必要)。SPD = 「どの通信を IPsec で守る / 平文で出す / 落とす」を書いた ルール集。SAD = 今動いている契約書を全部しまった 名簿。SPI = 各契約書に貼られた 番号札 (32 bit) で、ESP パケットの先頭に付く。受信側はこの番号札で名簿を引いて、どの鍵で開ければいいか分かる、というのが全体の流れ。

  • 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. アプリが TCP/443 で送信
10.0.0.5 → 10.0.0.20 へ通常のソケット送信。
2. カーネルが SPD を引く
「この通信は protect」というポリシーにマッチ。
3. SAD に該当 SA があるか
なければ IKE を呼んで鍵交換する。
4. IKE が相手と鍵交換
完了したら送信用・受信用の 2 つの SA を SAD に登録。
5. ESP にカプセル化して送信
送信側 SA で暗号化 → ESP パケットとして出す。
6. 受信側は SPI で SAD を引く
鍵を取り出して復号 → 順次 SPD で「これは正当か」を再チェック。
Linux で SA / SPD を覗く
# ip-xfrm — カーネルの IPsec 状態を直接見る $ 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 の片方しか張れていない、または 方向が片方しか合っていない という診断パスがほとんどここに落ちる。

04

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

IKE (Internet Key Exchange) は IPsec の中で鍵を握る役割。IKEv2 (RFC 7296, 2014) はたった 2 往復 (4 メッセージ) で IKE SA と Child SA (= ESP の鍵) まで揃う設計で、IKEv1 の冗長さ (Main Mode 3 往復 + Quick Mode 1.5 往復) を一掃した。

▸ かみ砕いて言うと — IKEv2 は「2 段階の挨拶」

本題に入る前に握手する流れ。1 往復目 (IKE_SA_INIT) = 「使う暗号はこれで、私の公開鍵はこれです」 — 平文だが盗み聞きされても秘密は流れない (Diffie-Hellman の不思議)。2 往復目 (IKE_AUTH) = 「私は○○で、ここに身分証 (証明書) があります」 — ここは 1 往復目で作った鍵で暗号化済みなので、誰がいつ何で接続してきたかも外からは見えない。たった 2 往復でデータ転送開始まで辿り着く、というのが IKEv1 (9 メッセージ) からの大きな進化。新規構築で IKEv1 を選ぶ理由はない。

IKEv2 シーケンス — IKE_SA_INIT → IKE_AUTH → ESP データ転送
# 1 往復目: IKE_SA_INIT (平文 — DH 鍵交換) Initiator → Responder: HDR, SAi1, KEi, Ni 提案する暗号 (SAi1) / 自分の DH 公開値 (KEi) / 乱数 (Ni) Responder → Initiator: HDR, SAr1, KEr, Nr [, CERTREQ] 受諾した暗号 (SAr1) / 相手の DH 公開値 / 乱数 (Nr) ▲ ここで両者は SKEYSEED を計算 → IKE SA の鍵が出来る (PFS 達成)

# 2 往復目: IKE_AUTH (暗号化 — 認証 + Child SA 生成) Initiator → Responder: {HDR, IDi, [CERT,] AUTH, SAi2, TSi, TSr} ID / 証明書 / 認証データ (AUTH) / Child SA 提案 / 通信範囲 Responder → Initiator: {HDR, IDr, [CERT,] AUTH, SAr2, TSi, TSr} ▲ ここで IKE SA + Child SA (= ESP 用の鍵 2 つ) が完成 → データ転送開始可

# 以後: ESP でアプリデータ転送 (UDP/4500 中, NAT-T 時は UDP encap) ESP packet (SPI=X, Seq=1, encrypted)

# 必要に応じて: CREATE_CHILD_SA (鍵更新 / 追加トンネル) — 通信は無停止 {HDR, SAi, Ni, [KEi,] TSi, TSr}

押さえどころ:

  • 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 に向く

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

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

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

IKEv2 はこれらを「シンプルな 2 往復に統一 + NAT-T を仕様内に取り込む + メッセージごとに ID を付けて再送と消失を区別」で一掃した。新規構築で IKEv1 を選ぶ理由はない。

05

NAT-T — IPsec が NAT を通れない理由 #

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

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

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

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

06

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

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

▸ かみ砕いて言うと — 認証 3 方式は「鍵 / 印鑑 / ID 票」

相手が本物かを証明する手段の選び方。PSK (事前共有鍵) = 合鍵を 1 本コピーして渡しておく方式。シンプルだが 合鍵が漏れたら全員詰むので、ラボや小規模拠点限定。証明書 (X.509) = 役所が発行した実印。1 拠点の鍵が漏れても他は無事で、大規模 Site-to-Site の本命。EAP (RADIUS) = 社員証 + パスワード + MFA で 「個別の社員」を都度認証する方式。リモートアクセス VPN (社員が家から接続する形) で使う。用途で機械的に決まるので、悩むところは少ない。

方式 仕組み 向く場面 落とし穴
PSK (Pre-Shared Key) 両端で同じ秘密文字列を持つ ラボ / 小規模 Site-to-Site IKEv1 Aggressive Mode + PSK はオフライン解析を許す。漏洩したら全 peer 詰む
証明書 (X.509 + PKI) CA が発行した証明書を相互認証 大規模 Site-to-Site / 商用 VPN CA 運用 (rotation, CRL, OCSP) が要る
EAP (RADIUS 経由) リモートユーザを ID/PW + MFA で認証 リモートアクセス VPN (IKEv2 + EAP-MSCHAPv2 / EAP-TLS) RADIUS サーバが Single Point of Failure
▸ Aggressive Mode + PSK の古典的脆弱性

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

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

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

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

  • AWS Site-to-Site VPN — Customer Gateway (オンプレ) と AWS の Virtual Private Gateway / Transit Gateway を IKEv2 + IPsec ESP で結ぶ
  • 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 のどの製品でも同じ語彙で設定できる。

08

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

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

  • IKE のフィンガープリント — ike-scan でベンダーと IKE 実装が特定可能。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 は完全無効。これを満たしていない既存トンネルがあれば、計画的に移行する。

09

まとめ — IPsec と WireGuard の棲み分け #

▸ はじめての人向け — IPsec と WireGuard をどう使い分けるか

VPN を新しく作るとき、現代の選択肢は事実上 IPsec か WireGuard。個人 / 自宅サーバ / 小規模拠点なら WireGuard — 設定が短く、速く、省電力。大企業の拠点間 / クラウド (AWS / Azure / GCP) との接続なら IPsec (IKEv2) — ベンダー間の互換性が圧倒的で、エンタープライズ機器すべてが標準対応。iPhone の Always On VPN を会社用に使うなら IPsec — Apple 標準 VPN がそもそも IKEv2。「個人 = WireGuard / 企業 = IPsec」と覚えれば、選定で迷う場面は減る。

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 と並走する形でまだ続く。

𝕏 ポスト B! はてブ