【実務・中級編】 Tor over VPNとVPN over Torのアーキテクチャ比較 – サイバーセキュリティとプライバシー保護実践ガイド

Tor over VPN vs VPN over Tor：パケットの迷宮と現実のエンジニアリング

ネットワークエンジニアの皆さん、日々のインフラ運用やAPI設計、お疲れ様です。カフェのフリーWi-Fiから社内リポジトリにアクセスする際、「とりあえずVPNを繋いでおけば安心」なんて油断していませんか？ あるいは、プライバシーの限界を極めるために、Torと商用VPNを組み合わせる「二重の防壁」にロマンを感じたことはないでしょうか。

今回は、セキュリティとプライバシーの極限を追求するエンジニア向けに、「Tor over VPN」と「VPN over Tor」という2つのアーキテクチャを徹底比較します。パケットが暗号化のレイヤーをどのように通過し、出口のノードでどう振る舞うのか。教科書には載っていない、現場の泥臭い挙動と実務的な実装アプローチを解き明かしていきます。

—

1. 基礎知識：オニオンルーティングと商用VPNの交差点

まずは、それぞれの技術がネットワークスタックのどこに位置し、何を目的にしているかを整理しましょう。

商用VPNは、クライアントとVPNゲートウェイの間をIPsecやWireGuard、OpenVPNといったトンネリングプロトコルで包み込み、ISP（インターネットサービスプロバイダ）やローカルネットワークの管理者から通信内容を隠蔽します。しかし、VPNプロバイダ自身はあなたの通信先を知ることができます。

一方、Tor（The Onion Router）は、世界中に分散するボランティア運営のノードを3段階（Guard $\rightarrow$ Middle $\rightarrow$ Exit）経由させることで、通信の送信元と宛先の相関関係を数学的に追跡困難にするオニオンルーティングネットワークです。パケットは幾重もの暗号化（タマネギの皮）で包まれ、各ノードは「一つ前のノード」と「次のノード」しか知りません。

この2つを直列に繋ぐとき、「どちらを内側にするか」でセキュリティモデルとトラフィックの性格が劇的に変わります。

—

2. アーキテクチャ比較：パケットの旅路とシーケンス

パターンA：Tor over VPN （VPNの中でTorを動かす）

この構成では、まずデバイスと商用VPNサーバー間で暗号化トンネルを張り、そのカプセル化された内部でTorのプロセスを起動してオニオンネットワークへ接続します。

通信フロー（シーケンス）

1. Client $\rightarrow$ VPN Gateway: デバイスからの全てのトラフィックがVPNで暗号化され、ISPからは「VPNサーバーと通信していること」しか見えません。
2. VPN Gateway $\rightarrow$ Tor Guard Node: VPNサーバーのIPアドレスから、Torの第一ノード（Guard）へTLS接続が確立されます。
3. Tor Network: Guard $\rightarrow$ Middle $\rightarrow$ Exit ノードを経て、最終的なWebサーバーへ到達します。

メリットとデメリット

  • ISPに対する秘匿性: ISPやローカルネットワークの管理者には、あなたがTorを使っていることすら隠蔽され、「単にVPNを使っているユーザー」に見えます。
  • 出口の性質: 最終的にインターネットへ出るのはTorのExitノードのIPアドレスです。そのため、アクセス先のWebサービスからは「Torからのアクセス」として検知されます。
  • パフォーマンス: VPNのオーバーヘッドにTorの3ホップ遅延が乗るため、レイテンシは最悪の部類に入ります。Web APIの疎通確認にはフラストレーションが溜まるでしょう。

—

パターンB：VPN over Tor （Torの中でVPNを動かす）

こちらの構成は、まずローカルデバイスでTorを起動してトラフィックをオニオンルーティング網に流し込み、そのTorの出口（SOCKS5プロキシなど）の先にVPNの接続を確立しようとするアプローチです。理論的にはTorの秘匿性の後にVPN認証が乗りますが、実際のネットワークスタック（特にUDPを必要とする現代のVPNプロトコル）において実装が非常に困難、あるいはセキュリティ上の致命的な罠（IPリーク等）を孕みます。

通信フローと実務上の罠

Torは基本的にTCPベースのストリーム指向です。しかし、WireGuardやOpenVPN（UDPモード）などのモダンなVPNプロトコルはUDPを使用するため、標準的なTorのSOCKS5プロキシ（SocksPort）をそのままトンネリングするのは困難を極めます。強引に実装しようとすると、DNSリクエストやUDPパケットがTorのプロキシをバイパスして平文で漏洩（DNSリーク）するインシデントが多発します。

この構成は、実務のインフラ設計においては「アンチパターン」として扱われることが多く、特殊な匿名化研究を除いて商用・本番環境で採用すべきではありません。

—

3. 実務で役立つ設定とコード例

ここでは、最も現実的かつ安全に検証可能なTor over VPN環境において、アプリケーションからどのようにプロキシ経由でリクエストを投げるか、具体的なコード例を見ていきます。

通常、ローカルマシン上でVPNを有効にした状態で、バックグラウンドでTor Daemon（tor）を起動すると、デフォルトで 127.0.0.1:9050 にSOCKS5プロキシが立ち上がります。

Python (requests) によるTor経由のAPIリクエスト

インフラの自動化スクリプトや死活監視ボットなどで、特定のトラフィックを強制的にTor経由（Tor over VPN環境下）に流す場合のコードです。requests[socks] ライブラリを使用します。

import requests

# TorのSOCKS5プロキシを経由するようにプロキシ辞書を定義
# ※事前にローカル環境で Tor デーモンが起動していること前提
proxies = {
    'http': 'socks5h://127.0.0.1:9050',
    'https': 'socks5h://127.0.0.1:9050'
}

def check_ip_via_tor():
    target_url = "https://httpbin.org/ip"
    
    try:
        # タイムアウトを長めに設定（オニオンルーティングの遅延を考慮）
        response = requests.get(target_url, proxies=proxies, timeout=30)
        response.raise_for_status()
        
        print("[+] Tor経由でのIP確認成功:")
        print(response.json())
        
    except requests.exceptions.RequestException as e:
        print(f"[-] 通信エラーが発生しました: {e}", file=sys.stderr)

if __name__ == "__main__":
    import sys
    check_ip_via_tor()

> 実務Tips (socks5h:// の重要性):
> 上記コードのプロキシスキームに socks5h を指定している点に注目してください。単なる socks5:// だと、DNSの名前解決がローカル（あなたのOS側）で行われてしまい、DNSリーク（プライバシー漏洩）の原因になります。socks5h を指定することで、DNSクエリ自体もTorのプロキシ経由でリモート側（出口ノード）で解決させることができます。セキュリティ設計の基本中の基本です。

—

Linux (curl) によるコマンドライン検証

インフラのデバッグやコンテナ内での疎通確認には curl が欠かせません。Tor over VPN環境下で特定のエンドポイントを叩く場合のコマンドは以下の通りです。

# --socks5-hostname を使用することで、DNSリークを防ぎつつTor経由でリクエストを送信
curl --socks5-hostname 127.0.0.1:9050 https://httpbin.org/ip

もしレスポンスに含まれるグローバルIPアドレスが、あなたが契約している商用VPNのIPとも、自宅のISPのIPとも異なる、全く見知らぬ国のIP（Tor Exit Node）になっていれば、正しく「Tor over VPN」の多重カプセル化が機能している証拠です。

—

4. パフォーマンスとトラブルシューティングの現実

ネットワークスペシャリストとして、綺麗ごと抜きで言わせてもらえば、Tor over VPNの実用性は極めて低いです。

1. レイテンシの爆発:
商用VPNの暗号化オーバヘッドに加え、地球の裏側を経由するかもしれない3つのTorノードを挟むため、RTT（Round Trip Time）は簡単に数百ミリ秒〜数秒に跳ね上がります。現代のWeb API設計で主流のRESTやgRPCにおいて、タイムアウトエラーが頻発する原因になります。
2. WAF（Web Application Firewall）による強力なブロック:
CloudflareなどのモダンなCDN/WAFは、TorのExitノードリストをリアルタイムで把握しています。Tor over VPNであっても、最終的な出口がTorである以上、アクセス先のWebサービスから 403 Forbidden や難解なCAPTCHA（Bot検証）を突きつけられる確率が跳ね上がります。
3. TCPタイムアウトとコネクション切断:
ボランティアノードの負荷や回線品質の不安定さにより、コネクションが途中でプツリと切れることが日常茶飯事です。冪等性（Idempotency）が担保されていないAPIリクエストをこの環境から投げるのは、実務上は自殺行為と言えます。

—

まとめ

今回は「Tor over VPN」と「VPN over Tor」のアーキテクチャの違い、そして前者の実務的な実装アプローチを解説しました。

  • Tor over VPN: VPNでISPから隠れつつ、さらにTorで匿名性を高める構成。DNSリーク対策（socks5h の使用等）を行えば技術的には成立するが、レイテンシとWAFブロックの壁が厚い。
  • VPN over Tor: ネットワークスタックの相性やUDPの扱いから実務的・セキュリティ的に破綻しやすく、採用すべきではない。

セキュリティと利便性、そしてパフォーマンスは常にトレードオフの関係にあります。システム要件が真に求めているプライバシーのレベルを見極め、無駄に複雑な多重防御でインフラの保守性を下げてしまわないよう、冷静なアーキテクチャ選定を心がけましょう。現場からは以上です。

スポンサーリンク

コメント

タイトルとURLをコピーしました