匿名性の迷宮をどう設計するか：Tor over VPN vs VPN over Tor の深淵
ネットワークエンジニア諸君、パケットがフラグメンテーションの嵐に揉まれ、MTUの制限と戦いながら、OSI参照モデルの向こう側を夢想する日々を送っていることだろう。今日は、個人のプライバシー保護という文脈で語られることが多い「VPNとTorの多段接続」について、あえてアーキテクチャの泥沼に足を踏み入れ、そのパケットレベルの挙動を解剖していこう。
「Tor over VPN」か「VPN over Tor」か。この問いは、単なる接続順序の問題ではない。それは、エントリノードの隠蔽と、出口ノードの汚染をどうトレードオフするかという、極めてインフラ屋らしい設計思想の衝突なのだ。
—
1. Tor over VPN：VPNトンネルの内部をオニオンが駆け抜ける
まずは一般的な「Tor over VPN」の構成だ。デバイスからVPNサーバーへ暗号化トンネルを張り、その内側でTorクライアントがオニオンルーティングを開始する。
パケットの挙動と懸念
この場合、ISPやローカルゲートウェイからは「VPNサーバーとの間の暗号化通信」しか見えない。Torの存在はカプセル化によって秘匿される。しかし、ここで発生するのがTCP Meltdown問題だ。
TorはTCPストリームを多重化するが、VPN（OpenVPN等）もまたTCP/UDPでトンネルを構築する。VPN側でパケットロスが発生すると、VPNのTCP層が再送制御を行い、その内側のTorのTCPストリームも再送を待たされる。いわゆる「TCP over TCP」の呪いにより、RTT（往復遅延時間）は爆発し、レイテンシは壊滅的な値を示す。
パフォーマンス改善の勘所
これを解消するには、VPNプロトコルに WireGuard を選択し、かつカーネルレベルでMTUをチューニングする必要がある。
# WireGuardインタフェースのMTUを最適化する
# Torのオーバーヘッドを考慮し、フラグメンテーションを防ぐために標準より小さく設定
ip link set dev wg0 mtu 1280
# sysctlでのTCPバッファチューニング（極端なRTT環境下でのスループット維持）
# ネットワークの遅延が大きいTor環境では、送受信バッファを拡大する
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"—
2. VPN over Tor：匿名性の砦の裏側に潜り込む
次に「VPN over Tor」だ。Torネットワークを通過した後にVPNサーバーへ到達する。この構成の最大の目的は、Torの出口ノード（Exit Node）がブラックリスト化されているサイトに対して、VPNサーバーのIPを使ってアクセスすることにある。
アーキテクチャの脆弱性と設計の罠
この構成では、Torの出口ノードが VPNプロトコル のパケットを拾うことになる。もしVPN側で認証情報の漏洩や設定ミスがあれば、匿名化の努力は水泡に帰す。特に、TorからVPNサーバーへの接続において、TLS ハンドシェイクがVPNプロトコルのネゴシエーションと衝突しないよう、慎重なルーティングが必要だ。
推奨される実装指針
この構成を実現するには、ProxyCommand を活用してSSHでVPNサーバーに接続するか、Tor の TransPort 機能を利用してトラフィックを強制的にTor経由にするのが定石だ。
# torrc設定例：透過プロキシとしての運用
# これにより、システム全体のトラフィックをTorに流し込み、
# その先にVPNゲートウェイを配置するルーティングを組む
VirtualAddrNetworkIPv4 10.192.0.0/10
TransPort 9040
DNSPort 5353
AutomapHostsOnResolve 1—
3. パフォーマンスとセキュリティの統合的考察
結局のところ、どちらが「最強」なのか。
- Tor over VPN：ISPからの検閲回避や、Tor利用そのものを隠したい場合に最適。ただし、VPNプロバイダがあなたの通信を「ログ」として把握している可能性を排除できない（VPNプロバイダを信頼する必要がある）。
- VPN over Tor：VPNプロバイダに「Torの出口からアクセスしている」ことを知られる。しかし、VPNの出口IPを使用できるため、Tor特有の「サービス遮断」を回避しやすい。
究極の低レイテンシ・高セキュリティを目指して
もしあなたが極限の環境を構築したいのであれば、以下の3点に注力すべきだ。
1. UDPベースのVPN選択: OpenVPN のTCPモードは避け、WireGuard または Shadowsocks (v2ray-plugin等) を検討すること。TCPの再送制御とTorの輻輳制御を分離せよ。
2. TCPバッファの動的調整: Linuxカーネルの BBR 輻輳制御アルゴリズムを有効化する。
# BBRを有効化し、高レイテンシ環境でのスループットを改善
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr3. ヘッダー圧縮の抑制: 暗号化されたパケットに対してヘッダー圧縮を試みるのはリソースの無駄だ。VPN側で nocomp オプションを明示的に有効にし、CPU負荷を下げてパケット処理速度を優先せよ。
最後に：ネットワークは「生き物」である
技術スタックを組み上げた瞬間、それは静的な構成図から、パケットが飛び交う動的な生命体へと変貌する。Torのノードは常に増減し、VPNのサーバーも負荷状況によってRTTは刻々と変化する。
「正しい構成」とは、教科書にあるものではなく、現場のネットワーク環境下で「許容できるレイテンシ」と「妥協できる匿名性」の交差点に自ら杭を打つことにある。諸君のトラフィックが、今日も安全かつ高速に目的地へ届くことを祈っている。
コメント