境界の崩壊とパケットの苦悩：IPsec vs SSL-VPNの深淵を覗く
「VPNは遅い」。現場でこの愚痴を聞くたび、私はつい苦笑してしまう。それはVPNそのものの罪ではなく、パケットが通過するアーキテクチャの「摩擦」を無視した設計の罪だからだ。
ゼロトラスト全盛の今、エンタープライズの境界防御はVPNの先にある。しかし、レガシーな拠点間接続や、どうしてもセキュアなトンネルが必要なシーンにおいて、IPsecとSSL-VPN（TLS-VPN）のどちらを選ぶべきか、そしてどうチューニングすべきかは、インフラアーキテクトにとっての永遠の命題だ。今回は、CPUの熱量とパケットの呼吸を感じるレベルまで掘り下げてみたい。
—
IPsec vs SSL-VPN：CPUとパケットの力学
両者の根本的な違いは、パケット処理の「レイヤー」にある。
IPsec（ESP）の優位性
IPsecはネットワーク層（L3）で動作する。カーネルスペースで直接パケットを処理し、ESP（Encapsulating Security Payload）ヘッダーを付与するだけ。非常にシンプルだ。特にAES-NI命令セットに対応したCPUであれば、暗号化のオーバーヘッドはハードウェアレベルで相殺される。
SSL-VPN（TLS）の足枷と可能性
一方、SSL-VPNはトランスポート層（L4）からアプリケーション層にかけて動作する。パケットは一度ユーザーランドへ引き上げられ、SSL/TLSスタックを経て再カプセル化される。この「コンテキストスイッチ」こそが、高トラフィック環境におけるボトルネックの正体だ。
しかし、現代のTLS 1.3は、0-RTTハンドシェイクによるレイテンシ削減や、ChaCha20-Poly1305のような軽量な暗号スイートを武器に、IPsecとの距離を急速に縮めている。
—
限界を引き出す：スループット最適化の現場技法
大規模環境でパフォーマンスを絞り出すには、プロトコルスタックの「呼吸」を整える必要がある。
1. TCPバッファのチューニング（SSL-VPNの肝）
SSL-VPNはTCPの上でTCPをトンネリングする「TCP-over-TCP」問題を抱えがちだ。これが輻輳制御の悪循環（TCP Meltdown）を招く。これを防ぐには、カーネルのTCPウィンドウサイズを最適化し、バッファを太くしておくことが必須だ。
# /etc/sysctl.conf に追記し、広帯域・高遅延環境でのスループットを維持する
# 読み取りバッファの最小/デフォルト/最大設定
net.ipv4.tcp_rmem = 4096 87380 16777216
# 書き込みバッファの最小/デフォルト/最大設定
net.ipv4.tcp_wmem = 4096 65536 16777216
# TCPウィンドウサイズのスケーリングを有効化
net.ipv4.tcp_window_scaling = 1
# BBR混雑制御アルゴリズムの適用（Google開発の神アルゴリズム）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr2. IPsecの断片化（Fragmentation）対策
IPsecはESPヘッダー分だけパケットサイズが増える。これがMTUオーバーを引き起こすと、パケットは断片化され、再構築のコストがCPUを蝕む。Path MTU Discovery（PMTUD）を過信せず、強制的に調整するのがプロの流儀だ。
# iptables/nftables を用いてMSSを調整し、断片化を未然に防ぐ
# VPNトンネルを通過するパケットのMSSを1360バイト程度に絞るのが安全
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360—
トランスポートセキュリティとRTTの極意
SSL-VPNで最も重要なのは「TLSハンドシェイクの短縮」だ。大規模拠点からアクセスする場合、1回のRTT削減が体感速度を劇的に変える。
- OCSP Staplingの活用: クライアントがCAサーバーに証明書検証を問い合わせる時間を省く。
- TLS 1.3の強制: 不要なレガシー暗号スイートを廃止し、ネゴシエーションのラウンドトリップを削減する。
設定例：NginxベースのSSL-VPNゲートウェイ最適化
ssl_protocols TLSv1.3; # 1.2以下は捨て去る勇気を持つ
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_session_cache shared:SSL:10m; # セッション再利用でハンドシェイクを削減
ssl_session_timeout 10m;
ssl_stapling on; # OCSPスタッぷを有効化—
最後に：ゼロトラストの文脈で考える
ここまでパフォーマンスのチューニングを語ってきたが、最後にひとつだけ。「VPNを速くすること」が、常に「正しい」わけではないという事実に触れておきたい。
ゼロトラストの観点では、VPNは「境界」を維持するだけのツールに過ぎない。もし、VPNのトンネルを流れるトラフィックの大部分がSaaSへのアクセスなら、それは今すぐSDP（Software Defined Perimeter）へ移行すべきサインだ。
VPNをチューニングして限界まで性能を引き出すスキルは、インフラエンジニアの誇りである。しかし、その技術を「何のために使うか」というアーキテクトの視点こそが、これからの時代を生き抜く鍵になる。
さあ、今夜のログ解析に戻ろうか。パケットがどこで詰まっているか、その呼吸音を聞きに行く時間だ。
コメント