VPNの「見えない壁」を突破せよ：IPsec vs SSL-VPN、現場が求める最適化の解法
ネットワークエンジニアとして現場に立っていると、「VPNが遅い」というクレームは日常茶飯事だ。大抵の場合、それは回線速度のせいではなく、暗号化という「見えない処理」がCPUを食いつぶし、パケットを滞留させていることに起因する。
今回は、エンタープライズ環境で避けては通れない「IPsec VPN」と「SSL-VPN」のパフォーマンス特性を紐解き、大規模環境で泥臭くチューニングするための実践的知見を共有しよう。
—
1. なぜ「暗号化」はパフォーマンスを殺すのか
まず、両者の構造的違いを理解しなければならない。
- IPsec VPN (Network Layer): カーネルレベルで動作する。パケットそのものをカプセル化（ESPヘッダーの付与）し、暗号化する。OSのスタックに近い分、オーバーヘッドは比較的少ないが、設定の柔軟性が低く、NATトラバーサルやMTU問題が頻発する。
- SSL-VPN (Application/Transport Layer): 通常はHTTPS（TLS）上で動作する。ユーザー空間での処理が多く、暗号化・復号のコンテキストスイッチが頻発する。特にTCP over TCPの問題（いわゆる「TCP Meltdown」）は、パケットロス発生時に致命的なスループット低下を招く。
どちらを選ぶべきか？
- 拠点間接続: 間違いなく
IPsecだ。安定したルーティングとスループットが確保できる。 - リモートアクセス: 柔軟性とセキュリティ（ゼロトラスト的な認可）の観点から
SSL-VPNが主流だが、パフォーマンスには配慮が必要だ。
—
2. IPsec VPN：MTUとMSSの「魔の三角形」を攻略する
IPsecで最も多いトラブルは「パケットサイズ超過による断片化（Fragmentation）」だ。ESPヘッダーが追加される分、通常の 1500 byte では収まらない。
実践：MSSクランプ設定
クライアントからのTCP SYN パケット内の MSS（Maximum Segment Size）値を強制的に書き換えるのが定石だ。
# Cisco IOSでの設定例
# MTU 1500 - IPsecヘッダー(約60-80 byte)を考慮し、1360程度に絞る
interface GigabitEthernet0/1
ip tcp adjust-mss 1360これを怠ると、大きなパケットがルーターで断片化され、CPU負荷が急増して通信が瞬断する。「なぜか小さなパケットは通るのに、大きなファイル転送だけ失敗する」という事象があれば、まずここを疑え。
—
3. SSL-VPN：TCP Meltdownを回避する技術
SSL-VPNで「Web APIを叩くと極端に遅い」という場合、多くのケースでTLSオーバーヘッドとTCPの再送制御が喧嘩をしている。
Pythonによるパフォーマンス計測スクリプト
開発者が「VPNが遅い」と泣きついてきたら、まずはレイテンシとスループットを定量化する。curl や requests でパケットの往復時間を測定し、TLSハンドシェイクに時間がかかっていないかを確認しよう。
import requests
import time
# VPN経由でAPIを叩く際の実効速度を測る
url = "https://internal-api.example.com/data"
start_time = time.time()
try:
response = requests.get(url, timeout=10)
# 応答時間とステータスコードを記録
print(f"Status: {response.status_code}")
print(f"Latency: {time.time() - start_time:.4f} sec")
except requests.exceptions.RequestException as e:
print(f"Error: {e}")チューニングのポイント
もしSSL-VPN環境でパフォーマンスが改善しない場合、以下の構成を検討せよ。
1. DTLS（Datagram TLS）の有効化: SSL-VPNのトンネル内でUDPを利用する機能だ。TCPの輻輳制御の影響を受けず、リアルタイム性が格段に向上する。
2. Keep-Alive設定: セッション維持のためのパケットを減らし、暗号化処理のオーバーヘッドを削減する。
—
4. ゼロトラスト時代における「境界」の再定義
最後に、スペシャリストとしての提言を一つ。
パフォーマンスを追求するあまり、VPNゲートウェイそのものを巨大化させるのは、もはや時代遅れだ。
大規模環境では、VPNの集中による「ボトルネック」を避けるために、SD-WANによる拠点の直接インターネット接続（DIA）や、ZTNA（Zero Trust Network Access）への移行を並行して進めるべきだ。
- VPN集中型: センター側のCPU/メモリリソースがスループットの限界を決める。
- ZTNA分散型: アプリケーション単位でアクセスを制御し、認証ゲートウェイをクラウドに分散させることで、物理的なボトルネックを排除できる。
まとめ：トラブルシューティングの極意
1. ping での MTU チェック（ping -f -l 1472）を怠るな。
2. 暗号アルゴリズム（AES-GCM推奨）がハードウェアアクセラレーションに対応しているか、機器のスペックシートを確認せよ。
3. 最終的には「VPNを通さない通信」をどれだけ増やせるか（＝ゼロトラスト化）が、最大の最適化であると理解せよ。
現場でトラブルが起きたとき、盲目的に設定を変えるのではなく、パケットがどこで、なぜ渋滞しているのかを常にイメージしてほしい。ネットワークは、正直だ。正しく設定すれば、必ず期待通りのパフォーマンスで応えてくれる。
コメント