IPsecの深淵：パケットを「守り抜く」ためのアーキテクチャ再考
ネットワークエンジニアの諸君、今日も今日とてパケットの断片化と格闘しているだろうか。
ゼロトラストが謳われる昨今、「境界防御は死んだ」と叫ぶ声も聞こえるが、現実のエンタープライズ環境において、VPNは依然として強固なバックボーンだ。特にIP層で暗号化と認証を完遂する IPsec は、OSI参照モデルの第3層という特等席に陣取っているからこそ、その挙動を理解しているか否かで、アプリケーションのパフォーマンスからセキュリティ強度までが劇的に変わる。
今回は、教科書的な説明は極力省き、カーネルレベルの挙動と、現場で「なぜか遅い」「なぜか切れる」を解決するための解像度まで踏み込んで解説しよう。
—
1. AHとESP：カプセル化の哲学
IPsecの根幹は AH (Authentication Header) と ESP (Encapsulating Security Payload) にある。現代のアーキテクチャにおいて、AH の出番はほぼ皆無と言っていい。IPヘッダーまで整合性をチェックするその潔癖さは、NAT環境（IPヘッダーを書き換える）という現代のネットワークの現実と激しく衝突するからだ。
我々が採用すべきは常に ESP だ。ESP は暗号化だけでなく、ICV (Integrity Check Value) を用いた改ざん検知も行う。
現場の知見：ESPのオーバーヘッドを読み解く
ESP を利用する際、必ず考慮すべきはMTU（Maximum Transmission Unit）の低下だ。カプセル化により ESP ヘッダーと IV（初期化ベクトル）、そして Padding が加わる。標準的な1500バイトのインターフェースでは、フラグメンテーションが起きやすくなる。
特に AES-GCM を利用する場合、暗号化と認証を同時に処理できるため、CPU負荷を下げつつセキュリティ強度を最大化できる。モダンなIPsec実装であれば、これ以外の選択肢は検討に値しない。
—
2. パフォーマンスの限界を突破する：TCPとカーネルのチューニング
VPN越しに大容量のトラフィックを流すと、しばしば「TCPスループットが頭打ちになる」という相談を受ける。これは単なるVPNの帯域制限ではない。パケットの「往復時間（RTT）」が伸びたことによる、TCPのウィンドウ制御の限界だ。
RTT削減とバッファサイズ
Linux環境で strongSwan 等を使用してVPNを構築している場合、カーネルのTCPウィンドウサイズを明示的に広げる必要がある。VPNという「論理的な長距離リンク」では、デフォルトのバッファサイズではパイプラインを埋めきれない。
# /etc/sysctl.conf に追記して、高遅延リンクでのスループットを最大化する
# TCPの受信バッファの最小値、デフォルト値、最大値を拡張
net.ipv4.tcp_rmem = 4096 87380 16777216
# TCPの送信バッファの最小値、デフォルト値、最大値を拡張
net.ipv4.tcp_wmem = 4096 65536 16777216
# ネットワーク全体の最大バッファサイズを拡張
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216また、TCP BBR 輻輳制御アルゴリズムを有効にすることで、VPN越しのようなパケットロスがわずかに発生する環境下でも、劇的にパフォーマンスが向上する。
# BBRを有効化
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr—
3. セキュリティの防壁を「堅牢」にするための勘所
IPsecのネゴシエーション（IKEv2）において、セキュリティを疎かにしてはいけない。特に「何でも通す」設定は、ゼロトラストの思想に反する。
脆弱性を回避するための設定戦略
IKEv2における暗号スイートは、AES-256-GCM を中心に据えるのが鉄則だ。また、Perfect Forward Secrecy (PFS) を無効にするという愚行は避けなければならない。
# strongSwan (ipsec.conf) での推奨設定例
conn enterprise-tunnel
ike=aes256gcm16-sha384-ecp384! # 強固な暗号化と楕円曲線による鍵交換
esp=aes256gcm16-ecp384! # ESPもGCMで統一し、処理効率を上げる
keyexchange=ikev2
pfs=yes # PFSを有効化し、過去の鍵の漏洩による遡及被害を防ぐ
dpddelay=30s # デッドピア検出（DPD）で死活監視
dpdaction=restart # 切断時は自動再接続—
4. 終わりに：パケットに心を馳せる
VPNは魔法の杖ではない。それは物理的に離れた地点を論理的に結ぶための「暗号化されたトンネル」に過ぎない。パケットがカーネルの XFRM フレームワークを通過し、暗号化エンジンに渡され、再びネットワークインターフェースへと戻っていく過程を想像してほしい。
もし、貴方の管理するVPNで不穏な挙動を感じたら、tcpdump で esp プロトコルを覗いてみるがいい。生データを見れば、今の設定が最適化されているのか、あるいはフラグメンテーションの嵐に揉まれているのか、パケット自身が教えてくれるはずだ。
ゼロトラストへの道は、こうした足元の「プロトコルの理解」から始まる。境界防御を捨て去る準備ができるまで、せめてその境界を最高に堅牢で、かつ高速なものにしておくのが、我々スペシャリストの矜持というものだ。
コメント