パケットの暗号化要塞：IPsec ESP（Encapsulating Security Payload）の深淵と実務構築ガイド
やあ、エンジニア諸君。日々のAPI設計やインフラのオートスケーリング構築、お疲れ様。
クラウドネイティブな現代においても、オンプレミスとパブリッククラウドを安全につなぐ「最後の砦」として、IPsec VPNは今なお現役バリバリで稼働している。ゼロトラストの波が押し寄せようとも、拠点間接続やレガシーシステムとの安全な通信において、IPsecの堅牢性は揺るぎない。
だが、夜中に突然「拠点間の通信が途絶えた」「暗号化アルゴリズムのミスマッチでトンネルが上がらない」といったアラートを受け取ったとき、君たちは自信を持ってパケットキャプチャの海を泳ぎ切れるだろうか？
今回は、IPsecアーキテクチャの心臓部であり、パケットの機密性と完全性を一手に引き受ける ESP（Encapsulating Security Payload） の仕組みを、現場の泥臭い知見と共にとことん紐解いていこう。教科書をなぞるだけの説明はもう終わりだ。実際のパケットの挙動から設定ファイル、そしてトラブルシューティングの勘所まで、一気に解説する。
—
1. ESP（Encapsulating Security Payload）とは何か？
IPsecを語る上で避けて通れないのが、AH（Authentication Header）とこの ESP だ。
歴史的にはパケットの改ざん検知と送信元認証だけを行うAHというプロトコルもあったが、現代のインターネットにおいて「暗号化されていない通信」など存在価値がない。機密性（Confidentiality）、完全性（Integrity）、そして送信元認証（Authentication）を同時に提供するESPこそが、事実上のデファクトスタンダードである。
トランスポートモード vs トンネルモード
ESPを語る上でまず押さえるべきなのが、どの範囲を保護するかというモードの違いだ。
- トランスポートモード
- 元のIPヘッダーはそのままで、ペイロード（TCP/UDPセグメントなど）のみをESPで保護する。
- 主にホスト間（エンドツーエンド）の通信で使われるが、NAT越えの難しさやルーティングの複雑さから、実務で目にする機会は減っている。
- トンネルモード
- 元のIPパケット全体を丸ごとESPのペイロードとして包み込み、その外側に「新しいIPヘッダー」を付与する。
- 拠点間（Site-to-Site）VPNやクラウド（AWSのVGWやAzureのVPNゲートウェイ）との接続では、ほぼ100%このトンネルモードが使われる。
—
2. ESPパケットの構造：暗号化要塞の内部解剖
それでは、実際にワイヤー上を流れるESPパケットの構造を解剖してみよう。
ESPは、TCPやUDPのようなレイヤー4プロトコルではなく、IP層のすぐ上で動く（IPプロトコル番号 50）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \\
| Security Parameters Index (SPI) | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 暗
| Payload Data (Variable Length) | | 号
~ (Encrypted in Tunnel Mode) ~ | 化
| | | 対
+---------------+-------------------------------+---------------+ | 象
| | Padding (0-255 bytes) | Pad Length | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \\
| Next Header | | ^
+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication Data | | 完
| (Variable Length) | | 全
~ ~ | 性
| | v 保
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 護各フィールドの役割を、現場の視点で一つずつ解説する。
1. SPI (Security Parameters Index) [32ビット]
- 受信側が「どのセキュリティアソシエーション（SA）を使ってこのパケットを復号すればいいか」を特定するための識別子。ルーターはこの値を見て、内部のどのトンネル設定を適用すべきか判断する。
2. Sequence Number [32ビット]
- リプレイ攻撃（Replay Attack）を防ぐための単調増加するカウンター。受信側は、すでに受信した番号のパケットや古すぎるパケットを即座に破棄する。
3. Payload Data (可変長)
- トンネルモードであれば「元のIPパケット全体」、トランスポートモードであれば「上位レイヤーのデータ」が入る。ここが暗号化される。
4. Padding (0〜255バイト) ＆ Pad Length
- 暗号アルゴリズム（AESなど）のブロックサイズに合わせるためのパディングと、その長さを表すフィールド。
5. Next Header [8ビット]
- ペイロードの直後に続くプロトコルを示す（トンネルモードであれば
4（IPv4）や41（IPv6））。
6. Authentication Data (可変長、ICV: Integrity Check Value)
- パケットの改ざんがないことを証明する署名・MAC（Message Authentication Code）。これが最後に検証される。
—
3. 実務で遭遇する暗号化・認証アルゴリズムの選択
IKE（Internet Key Exchange）フェーズ2（IPsec SAの確立）において、どのような暗号スイート（Transform Set）を使うかは、セキュリティとパフォーマンスのバランスを決める重要な意思決定だ。
実務でよく使われる標準的な組み合わせを挙げておこう。
| 用途 / セキュリティレベル | 暗号化アルゴリズム (Confidentiality) | 認証/完全性アルゴリズム (Integrity) | 備考 |
| :— | :— | :— | :— |
| レガシー・互換性重視 | 3DES (192-bit) | SHA-1 | 現代では非推奨（レガシー機器接続用） |
| 標準的・堅牢 (AES-CBC) | AES-128 / AES-256 | SHA-256 (HMAC) | 最も広く普及している安全な組み合わせ |
| モダン・高速 (AEAD) | AES-GCM (128 / 256) | (AES-GCMに含まれる) | 暗号化と認証を同時に処理するため圧倒的に高速 |
ここで一言、シニアからのアドバイスだ。
もしハードウェアアクセラレーション（AES-NI等）が効くモダンなルーターやLinuxサーバーを使っているなら、迷わず AES-GCM を選択してほしい。従来の AES-CBC + HMAC-SHA256 の組み合わせに比べてオーバーヘッドが少なく、スループットが劇的に向上する。
—
4. 構築・設定の実例：Libreswan (Linux) でのIPsecトンネル設定
百聞は一見にしかず。Linux（RHEL/Ubuntu等）上でよく使われるIPsec実装である Libreswan を用いた、具体的な設定ファイル（/etc/ipsec.d/site_to_site.conf）を見てみよう。
# /etc/ipsec.d/site_to_site.conf
# AWSのVGWや別拠点のルーターと接続する際の設定例
conn aws-to-onpremise
# IKEのバージョン指定（基本はIKEv2を推奨）
ikev2=insist
# 接続タイプ（トンネルモードを指定）
type=tunnel
# 自拠点のローカルIPアドレス（NAT配下のときは %defaultroute 等を指定）
left=203.0.113.10
leftid=@onpremise.example.com
leftsubnet=192.168.100.0/24
# 対向（AWS側等）のパブリックIPアドレス
right=198.51.100.20
rightid=@aws.example.com
rightsubnet=10.0.1.0/24
# 認証方式（事前共有鍵: PSK）
authby=secret
# 暗号・認証アルゴリズムの指定（Transform Set）
# AES-256による暗号化と、HMAC-SHA256による完全性チェックを指定
ike=aes256-sha256;dh19
phase2alg=aes256-sha256;modp2048
# 自動起動設定（boot時にトンネルを張る）
auto=startそして、対応する事前共有鍵の設定ファイル（/etc/ipsec.d/site_to_site.secrets）は以下のようになる。
# /etc/ipsec.d/site_to_site.secrets
203.0.113.10 198.51.100.20 : PSK "SuperSecretSharedKeyForIPsecTunnel2023!"設定を反映したら、サービスをリロードしてトンネルの状態を確認する。
# Libreswanのサービス再起動
sudo systemctl restart ipsec
# トンネルの状態確認
sudo ipsec status
sudo ipsec whack --trafficstatusうまくトンネルが確立していれば、trafficstatus の出力に、現在やり取りされているバイト数や適用されているESPのアルゴリズムが表示されるはずだ。
—
5. 現場のトラブルシューティング：パケットキャプチャとデバッグの極意
インフラ運用において、設定が完了しても「なぜか通信できない」という壁にぶつかるのは日常茶飯事だ。そんなとき、どのようにESPパケットをデバッグすべきか、私の現場のノウハウを伝授しよう。
トラブル1：IKE（フェーズ1/2）は確立するのに、通信が一切通らない
- 原因の推論: これメンテンスで一番多いパターンだ。多くの場合、MTU（Maximum Transmission Unit）とパケットの断片化（Fragmentation）の問題、あるいはセキュリティグループやファイアウォールでのESP（IPプロトコル50）のブロックが原因。
- デバッグ手法:
tcpdumpを使って、パケットが実際にインターフェースを通過しているか確認する。
# IPプロトコル50（ESP）のパケットをリアルタイムでキャプチャする
sudo tcpdump -ni eth0 proto 50 -vvもしここでパケットが受信（rx）しているにもかかわらず、対向への送信（tx）がない、あるいはその逆であれば、ルーター内部のポリシー（PFKEYやセキュリティポリシーデータベース: SPD）のミスマッチが疑われる。
トラブル2：暗号化エラーやパケットドロップが起きる
- 原因の推論: 対向ルーターと自拠点で、
phase2algのパラメータ（暗号化方式やグループ）が微妙に食い違っているケース。 - デバッグ手法: Libreswanのデバッグログを有効にして、ネゴシエーションの瞬間を覗き見る。
# デバッグモードでログを詳細に出力させる
sudo ipsec whack --debug-all
# または /etc/ipsec.conf の config setup 部分に plutodebug="all" を追記してログ (/var/log/secure または journalctl) を監視
sudo journalctl -u ipsec -fログの中に NO-PROPOSAL-CHOSEN という無慈悲なエラーメッセージを見つけたら、それは「お互いの暗号スイートの好みが合わない」と言って怒られている証拠だ。両者の設定ファイルを突き合わせて、一言一句違わず一致させる必要がある。
—
6. まとめ
ESPプロトコルは、一見すると複雑なヘッダーや暗号化のレイヤーに阻まれて難解に思えるかもしれない。しかし、その本質は「インターネットという信頼できない荒野の中に、暗号と完全性によって守られた自分たち専用の安全なパイプラインを彫り込むこと」に他ならない。
API設計やクラウドアーキテクチャの設計図を描くとき、アプリケーション層のTLS（HTTPS）だけに頼るのではなく、ネットワーク層のベースとしてこのようなIPsec ESPの仕組みがどう機能しているかを理解しているか否かで、インフラエンジニアとしての「深み」は大きく変わる。
障害が発生したとき、パケットのバイナリやログの海から真実を見つけ出すのは、いつだって基礎を徹底的に押さえた者だけだ。
さあ、次のデプロイやネットワーク設計に、この堅牢な知識を存分に活かしてほしい。健闘を祈る！
コメント