IPsec の内部構造：AH/ESP・SA・トランスポート/トンネルモード

IPsec が「何を・どこまで」守るのか

IPsec（RFC 4301）は、IP 層でパケットに認証と暗号化を施す枠組みです。アプリやトランスポートを書き換えずに、IP パケット単位で保護をかけられるのが特徴で、/network/vpn/ の拠点間トンネルや、TLS が届かない L3 区間の保護に使われます。理解の鍵は 2つのプロトコル（AH/ESP） と、それを束ねる SA（Security Association） です。どのトラフィックをどう守るかは SA に集約され、パケット側はその SA を指す番号だけを運びます。

AH と ESP：保護範囲が違う2つのプロトコル

IPsec の保護は AH（Authentication Header） と ESP（Encapsulating Security Payload） のどちらかで実現します。両者の決定的な差は「暗号化するか」と「IP ヘッダまで認証に含めるか」です。

AH は IP ヘッダの不変フィールドまで認証範囲に含めるため、経路上で送信元 IP を書き換える /network/nat/ を通ると認証が壊れます。これが AH が廃れた最大の理由です。ESP は IP ヘッダを認証範囲に含めないため NAT と共存でき、暗号化も持つため、機密性が不要でも実務では ESP（暗号化なし＝null 暗号、または認証のみの構成）を選ぶのが通例です。

ESP のパケット構造

ESP は前後を自分のフィールドで挟み込み、ペイロードを暗号化します。認証（ICV）と暗号化で 適用範囲が異なる 点が要注意です。

[ IP ヘッダ ][ ESP ヘッダ ][      暗号化される範囲      ][ ESP 認証データ(ICV) ]
              SPI(4B)        元ペイロード(またはIPパケット)
              Seq(4B)        + ESP トレーラ
                               Padding / Pad長 / Next Header

暗号化の範囲: ペイロード + ESP トレーラ
認証(ICV)の範囲: ESP ヘッダ + 暗号化範囲（SPI/Seq を含む、IPヘッダは含まない）

Next Header は暗号化された末尾（トレーラ）に置かれ、内側の中身が TCP(6) なのか、トンネルモードなら IP(4) なのかを示します。これが暗号化される側に隠れるため、トンネルモードでは内側プロトコルの種別すら外からは読めません。Padding はブロック暗号の境界合わせと、平文長を隠す目的で入ります。

SA と SPI：保護方式の束ね方

SA（Security Association） は「この通信をどう守るか」の設定一式です。使用プロトコル（AH/ESP）、暗号・認証アルゴリズム、鍵、シーケンス番号カウンタ、モード（トランスポート/トンネル）などをひとまとめにします。重要な性質が2つあります。

• SA は片方向。双方向通信には行き用と帰り用で 2本 の SA が要る。
• SA は {SPI, 宛先IP, プロトコル} の3つ組 で一意に識別される。

受信側はパケットの ESP/AH ヘッダにある SPI（Security Parameter Index, 32ビット） を見て、自分の SA データベース（SADB）から該当 SA を引き当て、その鍵とアルゴリズムで処理します。SPI は受信側が SA 確立時に割り当てた「このパケットはこの設定で開けてくれ」という索引です。鍵やアルゴリズムをパケットに書く必要がないのは、SPI が SA への参照として働くからです。

受信パケット → ESPヘッダの SPI を読む
             → SADB を {SPI, dstIP, ESP} で検索
             → 一致した SA の鍵・アルゴリズムで ICV検証 → 復号

トランスポートモードとトンネルモード

同じ ESP/AH でも、どこに自分のヘッダを挿入し、元の IP ヘッダをどう扱うか が2モードで異なります。

元のパケット:
  [ IP ヘッダ ][ TCP ][ データ ]

トランスポートモード（ESP）:
  [ IP ヘッダ ][ ESP ][ TCP ][ データ ][ ESPトレーラ/ICV ]
   └ 元のIPヘッダを残し、その「中身」だけを保護

トンネルモード（ESP）:
  [ 新IPヘッダ ][ ESP ][ IPヘッダ ][ TCP ][ データ ][ ESPトレーラ/ICV ]
   └ 元のIPパケット「丸ごと」を暗号化し、新しいIPヘッダで包む

• トランスポートモードは元 IP ヘッダをそのまま使い、上位レイヤ（TCP/UDP のペイロード）だけを保護します。エンドツーエンド、つまりホスト自身が IPsec を終端する用途向きです。元の送信元・宛先 IP が露出するためオーバーヘッドは小さいですが、内部アドレスが見えてしまいます。
• トンネルモードは元パケット全体（IP ヘッダ含む）を ESP のペイロードとして暗号化し、外側に 新しい IP ヘッダ を付けます。ゲートウェイ間（拠点間 VPN）の標準で、内部トポロジ（元の送信元・宛先 IP）を外から隠せます。代わりに IP ヘッダが二重になり、オーバーヘッドは増えます。

トンネルモードでは内側の IP ヘッダごと暗号化されるため、外側ヘッダの宛先は対向ゲートウェイの IP になります。経路上の機器は「2つのゲートウェイ間の ESP 通信」しか見えず、内側で誰が誰と話しているかは分かりません。これが /network/vpn/ で社内ネットを丸ごと相手拠点へ届けられる仕組みです。カプセル化の積み重なり方は /network/protocol-encapsulation/ の視点でも捉えられます。

リプレイ防止ウィンドウ

ESP/AH ヘッダの シーケンス番号（32ビット、拡張で64ビット） は、送信ごとに1ずつ増えます。受信側はこれで リプレイ（傍受したパケットの再送） を弾きますが、IP は順序保証がないため「番号が連続していること」は要求できません。そこで スライディングウィンドウ を使います。

受信済み最大シーケンス番号 = T、ウィンドウ幅 = W（例 64）
  - seq > T            : 新規。受理し、ウィンドウを前進させる
  - T-W < seq <= T     : ウィンドウ内。ビットマップで既受信かを確認し、
                         未受信なら受理、既受信なら破棄（リプレイ）
  - seq <= T-W         : 古すぎる。無条件で破棄

受信側はウィンドウ幅ぶんのビットマップを持ち、受理済みの番号に対応するビットを立てます。これで「少々の順序入れ替わりは許容しつつ、同じ番号の二度目は確実に破棄」できます。重要なのは、リプレイ防止は受信側だけの判断で完結 し、送信側が同じ SA で番号を再利用しないことが前提になる点です。

まとめ：設計時に押さえる対応関係

IPsec を設計・トラブルシュートするときは、次の対応を押さえると迷いません。機密性が要るなら ESP、相手がゲートウェイならトンネルモード、NAT を越えるなら ESP-over-UDP、という具合に要件から一意に決まります。

鍵交換側の IKEv2 と前方秘匿性の考え方は /network/tls13-handshake-internals/ の ECDHE と通じます。AH/ESP が「守る側」、SA/SPI が「束ねる索引」、モードが「包み方」という3軸で捉えると、IPsec の挙動は一貫して説明できます。