TCP over TCPの奈落：VPNのパフォーマンスを殺す「TCP Melt-down」の深層
ネットワークの現場に長く身を置いていると、「なぜかVPN越しだとウェブサイトの読み込みが極端に遅い」「スループットは出ているはずなのに、体感速度が壊滅的だ」といった相談をよく受ける。特に、ファイアウォールの制限を回避するために OpenVPN を TCP モード（--proto tcp）で運用している環境では、ほぼ間違いなくこの「TCP Melt-down（TCPメルトダウン）」という悪魔が棲みついている。
今日は、パケットレベルで何が起きているのか、なぜこれが「終わりのない負のスパイラル」なのかを、インフラエンジニアの視点で解剖しよう。
—
1. TCP Melt-down：二重の制御が招く同期の崩壊
TCP over TCPの核心は、「二つの独立したTCPスタックが、互いの再送制御を認識せずに干渉し合う」という点にある。
VPNトンネルの中を通るデータ（インナーストリーム）は、アプリケーションによってTCPで制御されている。しかし、それを運ぶカプセル（アウターストリーム）もまた、OpenVPNの TCP モードによって制御されている。
パケットが経験する絶望
1. パケットロスが発生: インナーストリームのパケットが一つでもロストする。
2. インナー側の再送待ち: インナーのTCPスタックはACKを待つが、タイムアウトして再送処理を開始する。
3. アウター側の再送待ち: 同時に、アウターのTCPスタックもパケットロスを検出し、独自の再送アルゴリズム（Fast Retransmitなど）を走らせる。
ここで致命的なのが、「アウターの再送処理によってインナーのタイマーがさらに狂う」ことだ。インナーのTCPは「ネットワークが混雑している」と誤認し、Congestion Window (CWND) を極限まで縮小させる。結果として、スループットは理論値の数分の一、あるいはそれ以下まで急降下する。これがTCPメルトダウンの正体だ。
—
2. パフォーマンス最適化の「禁じ手」と回避策
もしあなたがインフラアーキテクトとしてこの問題に直面しているなら、第一の選択肢は「TCPをやめること」だ。しかし、どうしても 443/TCP を通さざるを得ないレガシーな環境下では、カーネルチューニングで少しでも延命を図るしかない。
LinuxカーネルのTCPバッファチューニング
TCPの再送アルゴリズムを bbr に変更し、ウィンドウサイズを調整してパケットの滞留を減らす設定を検討すべきだ。
# /etc/sysctl.conf に以下の設定を追加
# BBR混雑制御アルゴリズムを有効化 (パケットロスをベースにしないためMelt-downに強い)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
# TCPバッファの自動調整範囲を拡大
# 大規模な遅延環境でもWindowを大きく保ち、スループットの低下を防ぐ
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216—
3. OpenVPNの挙動を制御する：MTUとフラグメンテーション
TCP over TCPにおいて、もう一つ無視できないのが MTU（Maximum Transmission Unit）の不一致だ。カプセル化によるオーバーヘッドが MTU を超えると、パケットが断片化され、再送の嵐を呼ぶ。
OpenVPN の設定で mssfix を指定し、インナーのTCPセッションが適切なサイズのパケットを生成するように強制するのが定石だ。
# server.conf または client.conf
# 1400バイト程度にMSSを制限し、カプセル化によるオーバーヘッドを考慮する
mssfix 1360
# TCPモード運用時、keepaliveの間隔を短縮して切断を検知しやすくする
keepalive 10 60—
4. なぜ「WireGuard」が現代の解法なのか
ここまでTCP over TCPの地獄を語ったが、現在のベストプラクティスは、やはり UDP ベースのトンネリング、具体的には WireGuard への移行だ。
WireGuardは「ステートレスに近い設計」と「極限まで削ぎ落とされた暗号化プロトコル」を持っており、TCPのような複雑なコネクション管理を行わない。そのため、パケットロスが発生した際も、インナーのTCPスタックだけが冷静に再送を行えば済む。アウター側が混乱に巻き込まれることはない。
セキュリティとパフォーマンスのトレードオフ
- OpenVPN (TCP): セキュリティ（検閲回避）は高いが、パフォーマンスは常にメルトダウンのリスクを抱える。
- WireGuard (UDP): パフォーマンスは最高だが、
443/UDPがブロックされている環境では工夫が必要（udp2rawなどの隠蔽ツールを併用するなど）。
—
結びに：エンジニアとしての矜持
ネットワークセキュリティの世界において、「銀の弾丸」は存在しない。TCP over TCPのメルトダウンは、プロトコルスタックが積み重なった現代のネットワーク構造が抱える「避けられない物理法則」のようなものだ。
もしあなたが今後、VPNのパフォーマンス問題に遭遇したら、まずは tcpdump を取り、インナーとアウターの再送パケットがどのようなタイミングで交錯しているかを観察してほしい。教科書的な知識ではなく、パケットの生の声を聞くことこそが、凄腕のエンジニアへの唯一の道だ。
現場からは以上だ。次回の深掘り記事では、TLS 1.3 の 0-RTT ハンドシェイクがVPN環境で引き起こすセキュリティ上のリスクについて解説しよう。
コメント