IPsecの深淵：トランスポートモードとトンネルモード、その「境界」を巡るパケットの旅
ネットワークエンジニアにとって、VPNとは単なる「安全なトンネル」ではない。それは、OSI参照モデルの第3層（ネットワーク層）で繰り広げられる、パケットの身代わり（カプセル化）と暗号化の壮大な儀式だ。
特にIPsecは、TLSのようなアプリケーション層のセキュリティとは異なり、OSのカーネルスタックに近い場所でパケットを弄り回す。今日は、このIPsecの二つの顔――トランスポートモードとトンネルモード――について、パケットの内部挙動を解剖しながら、実務的なパフォーマンスチューニングの勘所を紐解いていく。
—
1. パケットの構造に潜む「アイデンティティ」の相克
IPsecの動作を理解する鍵は、パケットがどこで「守られ」、どこで「見捨てられるか」にある。
トランスポートモード：信頼されたエンド・ツー・エンド
トランスポートモードは、オリジナルのIPヘッダーをそのまま残し、その直後に ESP (Encapsulating Security Payload) ヘッダーを挿入する。
- 構造:
[Original IP Header] [ESP Header] [Payload] [ESP Trailer] [ESP Auth] - 用途: 主にエンド・ツー・エンドの通信用。IPヘッダーが書き換わらないため、ネットワーク機器による経路制御がそのまま機能する。
ここで注意すべきは、NAT環境との相性だ。トランスポートモードでUDP/TCPのポート番号を暗号化してしまうと、ルーターのNAPTがパケットを識別できず、通信が即座に破綻する。これを回避するには NAT-T (NAT Traversal) が必須となる。
トンネルモード：パケットの「保護服」
トンネルモードは、オリジナルのIPパケット全体を新しいIPヘッダーで包み込む。
- 構造:
[New IP Header] [ESP Header] [Original IP Header] [Payload] [ESP Trailer] [ESP Auth] - 用途: ゲートウェイ間通信（Site-to-Site）。内側のパケットは完全にカプセル化されるため、グローバルIP空間を意識せずにプライベートネットワークを延伸できる。
—
2. パフォーマンスの死角：オーバーヘッドとRTT削減
インフラアーキテクトとして頭を悩ませるのが、カプセル化によるMTU（最大転送単位）の減少とそれに伴う断片化（フラグメンテーション）だ。
TCPバッファとMSSクランピング
VPNを通すと、ヘッダー追加分だけパケットサイズが肥大化する。これを放置すると Path MTU Discovery が失敗し、ブラックホールルーター問題を引き起こす。Linuxカーネルレベルで、iptables または nftables を使い、MSS (Maximum Segment Size) を調整するのが定石だ。
# クライアント側のiptablesでMSSを調整する例
# 1360バイトに制限することで、VPNヘッダー分を吸収しパケット断片化を防ぐ
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360割り込み処理とCPUボトルネック
IPsecの暗号化はCPUリソースを激しく消費する。現代のサーバーであれば、AES-NI 命令セットを活用するのが大前提だ。NICの RSS (Receive Side Scaling) や RPS (Receive Packet Steering) を適切に設定し、特定CPUコアへの偏りを防ぐ必要がある。
—
3. なぜ今、IPsecなのか：TLSとの比較
「TLSで十分ではないか？」という議論をよく耳にする。しかし、ゼロトラストアーキテクチャにおいてIPsecが再評価されている理由は、「アプリケーションの関与を一切必要としない」という点にある。
アプリケーション側がプロキシ設定を持っていようが、非HTTPプロトコルであろうが、IPsecはカーネルスタックで全てを透過的に暗号化する。これは、セキュリティポリシーを一元管理したいテックリードにとって、非常に強力な武器となる。
4. 実戦的設定：LinuxカーネルでのIPsec最適化
StrongSwan 等を用いて構築する際、以下の設定はシステムの安定稼働に直結する。
# /etc/ipsec.conf の抜粋
conn vpn-site-to-site
# トンネルモードの明示的な指定
type=tunnel
# AES-GCMを使用。認証と暗号化を単一パスで行い、パフォーマンスを最適化する
esp=aes256gcm16-sha256
# Perfect Forward Secrecy (PFS) を有効化し、鍵漏洩時の被害を最小化
pfs=yes
keyexchange=ikev2
# DPD (Dead Peer Detection) で回線断を即座に検知
dpddelay=10s
dpdtimeout=30s
dpdaction=restartAES-GCM を採用している点に注目してほしい。従来の CBC モード＋ HMAC という組み合わせは、二重の計算負荷がかかる。GCM は認証付き暗号化（AEAD）であり、現代のCPUではハードウェア支援を受けて爆速で動作する。
—
終わりに：複雑さこそが最強の防壁
ネットワーク層の暗号化は、一見すると泥臭いパケット操作の連続だ。しかし、この「低レイヤーの徹底的な制御」こそが、アプリケーション層の脆弱性からインフラを守る最後の砦となる。
パケットがどのヘッダーを纏い、どのトンネルを潜り抜けるのか。その挙動をパケットキャプチャツール tcpdump や tshark で追いかけ、ボトルネックを ethtool で監視する。そうした地道な観測の積み重ねだけが、堅牢で高パフォーマンスなインフラを構築する唯一の道だ。
次の記事では、さらに踏み込んで WireGuard との比較や、低遅延を実現するためのカーネルパラメータチューニングについて解説しようと思う。現場のトラブルシューティングで得た「生きた知識」こそが、何よりも信頼できるはずだ。
コメント