IPsec — IPパケットそのものを暗号化して守る

IPsecの難所は「データを暗号化する前に、その鍵を安全に共有する」ことです。鍵を平文で送れば意味がありません。ここを担うのが IKEv2（Internet Key Exchange v2）で、2つのフェーズで慎重に進めます。

• フェーズ1 — IKE_SA_INIT — 公開鍵暗号 と同じ発想のDH鍵交換で、盗聴されても復元できない鍵素材とランダム値（nonce）を交換する。これで「IKE自身を守る安全な通り道」ができる
• フェーズ2 — IKE_AUTH — 先の安全な通り道の中で、証明書や事前共有鍵を使って相互認証し、実データ用の SA（Child SA）を確立する
• 以降は ESP で実データを暗号化して流す。使うのは 共通鍵暗号（速いから）で、その鍵をIKEが安全に配った、という分業

なぜ2段階に分けるのか。いきなり本人確認から始めると、そのやり取り自体が盗聴されます。まず暗号の通り道を作り（1）、その中で本人確認する（2）——この順序が、認証情報すら守るための必然です。

トンネルは同時に何本も張られます。届いたパケットが「どのSAのものか」を一瞬で見分ける必要があります。

• SPI（Security Parameter Index）— ESPヘッダに載る32ビットの識別子。受信側はこれをキーに、正しいSAを引く
• SAD（SAデータベース）— SPIごとに「暗号方式・鍵・シーケンス番号の状態」を保持する台帳
• 受信の流れは「SPIでSADを引く → その鍵で復号 → 完全性とシーケンス番号を確認」

暗号化されていても、盗んだ正規パケットをそのまま再送されると困ります（リプレイ攻撃）。IPsecはこう防ぎます。

• ESPはシーケンス番号を1ずつ増やして付ける
• 受信側は受信済みの番号と、古すぎる番号（スライディングウィンドウの外）を拒否する
• だから同じパケットの使い回しは弾かれる

家庭や社内の多くはNAT（アドレス変換）の内側にいます。ところがIPsecはNATと衝突しがちです。

• なぜ難しいか — AHは元のIPヘッダまで保護するため、NATがアドレスを書き換えると完全性チェックに失敗する。ESPも、ポート番号を持たないためNAT機器が経路を管理しづらい
• どう越えるか — NAT-T（NATトラバーサル）で、ESPパケットを UDP（ポート4500）でさらにカプセル化する。UDPヘッダのおかげでNATが扱えるようになり、NAT越しでもトンネルが張れる

• 拠点間では宛先が「ゲートウェイ」であり、本当の宛先（社内ホスト）は隠したい。元パケットごと包むトンネルモードが必然
• 端末どうしが直接IPsecで話す限られた場面だけがトランスポートモード
• 落とし穴 — Perfect Forward Secrecy（毎回新しい鍵素材を使う設定）を切ると、将来の鍵漏洩で過去の通信までまとめて復号される危険がある
• 落とし穴 — 弱い暗号方式や短い鍵寿命の放置は、いくらトンネルを張っても土台を崩す