【入門編】 TCP over TCP問題（TCP Melt-down）の発生メカニズム – サイバーセキュリティとプライバシー保護実践ガイド

「VPNを使っているのにネットが激重…」その犯人は”TCPの二重奏”？TCP Melt-downを徹底解説！

皆さん、こんにちは！ネットワークの現場でパケットの迷子探しをしていると、時々こんな悲鳴が聞こえてきます。

「カフェのWi-Fiが怖いからVPNを繋いでいるのに、なぜかWebサイトの読み込みが異常に遅いんだ。これ、VPNのせいなの？」

結論から言うと、その犯人は「TCP Melt-down（TCPメルトダウン）」という現象かもしれません。今日は、なぜVPNをTCPモードで動かすとネットワークが「パニック」を起こすのか、その不思議な仕組みを紐解いていきましょう。

—

1. そもそも「TCP」って何をしているの？

まずは基本の復習から。TCPは、例えるなら「確実に荷物を届ける郵便屋さん」です。

1. 荷物を送る（パケット送信）
2. 届いたら「届いたよ！」とサインをもらう（ACK返信）
3. もしサインがなければ、「届いてないみたいだね、もう一回送るよ！」と再送する

この「届いた確認（ACK）」のおかげで、私たちは安全にWebサイトを見たり、ファイルをダウンロードしたりできるわけですね。

—

2. 悪夢の始まり：TCP over TCP

さて、ここでVPNの登場です。VPNは「トンネル」を作って通信を守ります。OpenVPNなどの設定で、あえて「ポート443（Web通信用）」を使い、TCPモードで通信を行うことがあります。

ここで起きるのが「TCP over TCP」という、いわば「郵便屋さんの荷物の中に、別の郵便屋さんが入っている」ような状態です。

なぜこれがダメなのか？

外側のトンネル（VPNのTCP）と、内側の通信（Webサイト閲覧のTCP）。この2つの郵便屋さんが、それぞれ勝手に「再送」を始めるからです。

内側の郵便屋さん： 「あれ？返事がないぞ。よし、もう一回送ろう！」
外側の郵便屋さん： 「おっと、ネットが混んでるみたいだ。少し待機してからまとめて送ろう。」

内側の郵便屋さんが焦ってパケットを再送している最中に、外側の郵便屋さんが「混雑しているから待機！」とブレーキをかけてしまう。すると、内側の郵便屋さんは「ますます届かない！」と判断して、さらに再送を連発します。

結果として、ネットワーク内は「まだ届いてないの！？」「いや、もう送ったよ！」という再送パケットで埋め尽くされ、肝心の本物のデータが全く通らなくなる。これが「TCP Melt-down」の正体です。

—

3. どうすれば回避できる？

一番の解決策は、VPNのプロトコルをUDPにすることです。UDPは「届いたか確認しない、とにかく速く送る」という性格なので、外側にUDPを配置すれば、内側のTCPが自由に再送制御を行えるようになり、渋滞が解消されます。

しかし、どうしてもファイアウォールの制約などでTCPポートしか使えない場合はどうすればいいでしょうか？

設定のヒント：OpenVPNの場合

もしあなたがOpenVPNを運用しているなら、サーバー側の設定ファイル（server.conf）を見直してみましょう。

# TCPモードで運用せざるを得ない場合の推奨設定
# 1. タイムアウト設定を緩和して、外側が焦って再送しないようにする
# クライアントが切断判断を下すまでの時間を長めに設定
keepalive 10 120

# 2. フラグメント（パケット分割）設定を適切にする
# 内側のTCPと外側のTCPでパケットサイズが競合しないよう調整
mssfix 1300

# 3. 圧縮機能（comp-lzo）はセキュリティリスクがあるため、最近は無効が推奨
# 圧縮による遅延もTCPの再送を誘発する要因になります
comp-lzo no

—

4. エンジニアとして知っておきたい「現場の視点」

現場でトラブルシューティングを行う際、まずはpingの結果だけでなく、Wiresharkなどでパケットを見てみてください。

もし、同じシーケンス番号（荷物の管理番号）のパケットが異常に何度も飛んでいる（Retransmission）ようなら、それは「TCP Melt-down」のサインです。「回線が遅い」と決めつけず、「トンネルの中で渋滞が起きていないか？」を疑うこと。これが凄腕エンジニアへの第一歩です。

—

まとめ：VPNは「適材適所」が大切

TCP over TCPは、二重の再送制御がケンカする最悪の組み合わせ！
可能なら必ずUDPモードを選択しよう。
どうしてもTCPが必要なら、タイムアウト設定やMSS調整で「あわてんぼう」なTCPを落ち着かせよう。

ネットワークは目に見えないからこそ、こうした「パケットの気持ち」を想像してあげることで、解決の糸口が見えてきます。皆さんのインフラ構築が、少しでも快適で安全なものになりますように！

それでは、また次のテクニカルログでお会いしましょう。Happy Hacking!