はじめに（この記事で分かること）#

「VPNとTorを両方使えば、もっと匿名になれるのか」。答えは、つなぐ順序と、誰を相手に何を隠したいかで変わる。

自分の端末からVPNにつなぎ、その中でTorを使う構成を、この記事ではTor over VPNと呼ぶ（経路は 自分 → VPN → Tor → 接続先）。逆に、Torを通った先でVPNにつなぐ構成がVPN over Torである（自分 → Tor → VPN → 接続先）。呼び名は文献によって逆になることがあるので、本文では必ず矢印の経路を併記する。

二つの順序は、ISP、VPN事業者、Torの出口リレー、接続先のそれぞれに見えるものを入れ替える。その入れ替わりを公式文書の記述で確かめ、どちらがどの脅威モデルで合理的かを整理する。どちらの順序を選んでも「完全な匿名」にはならない。その理由も最後に書く。

前提: 脅威モデルの整理#

脅威モデル入門で整理した相手のうち、VPNとTorの組み合わせ方で結果が変わるのは、回線を握るISP（職場や学校のネットワーク管理者も含む）、VPN事業者、Torの出口リレーを運用する第三者、接続先のサービスの四者である。法執行機関は、このうちISPやVPN事業者が持つ記録を経由して利用者に近づく。

どの組み合わせでも変わらない相手もいる。端末に入り込んだマルウェアやブラウザの脆弱性、ログインした瞬間に身元を明かすアカウント、回線の両端を同時に観測できる相手（タイミング相関）がそれである。VPNとTorの順序を考える前に、自分の脅威モデルにこの種の相手が含まれるかを確認しておく必要がある。

公式文書の立場はそろっていない#

最初に押さえておきたいのは、Torの開発元と、プライバシー分野でよく参照される解説サイトとで、VPNの併用に対する立場が違うことだ。

Tor Projectのサポートページは、この問いに短く答えている。「Generally speaking, we don't recommend using a VPN with Tor unless you're an advanced user who knows how to configure both in a way that doesn't compromise your privacy.」。ページの説明文は、VPNを足せばプライバシーが増すように見えても、設定を誤れば匿名性を下げたりTorの保護を壊したりしうる、という趣旨である。詳細はTor Projectの旧wikiの「TorPlusVPN」に譲っている。

その旧wiki（現在はアーカイブされ読み取り専用）は、より踏み込んでいる。「You can very well decrease your anonymity by using VPN/SSH in addition to Tor.」と書いたうえで、VPNは「permanent entry」か「permanent exit」のどちらかとして働き、ある危険を解く代わりに別の危険を持ち込むと説明する。多くのVPN事業者はログを取り、匿名で支払えなければ支払いの記録が残る、という指摘もここにある。

一方のPrivacy Guidesは、Tor Browserの推奨ページで「We often recommend connecting to Tor through a trusted VPN provider」と書き、正しく行わなければ匿名性を下げると添えている。詳しい理屈は同サイトの「Tor Overview」にあり、推奨する経路として「You → VPN → Tor → Internet」を示している。

Tailsは、VPNとの併用そのものを用意していない。公式FAQは「Currently, Tails does not work with VPNs.」と答え、Torは一か所で接続元と接続先の両方を知る地点を作らない設計だが、VPNは事業者が両方を見られる、と理由を述べている。Whonixの文書は「Whonix does not "need" a VPN.」と明記し、VPNとの組み合わせを扱うページには、コミュニティによるサポートのみである旨の表示がある。

まとめると、Tor Projectは「上級者以外には基本的に勧めない」、Privacy Guidesは「信頼できるVPNがあるならVPN → Torの順で」、TailsとWhonixは「VPNは必須ではない」という立場である。以下の整理は、この食い違いを前提に読んでほしい。

二つの順序で、誰に何が見えるか#

まず経路を並べる。

Tor over VPN（VPN → Tor）
自分の端末 → VPN サーバー → Tor 入口リレー → 中間リレー → 出口リレー → 接続先

VPN over Tor（Tor → VPN）
自分の端末 → Tor 入口リレー → 中間リレー → 出口リレー → VPN サーバー → 接続先

それぞれの観測者に見えるものを表にすると、次のようになる。表の内容は、Privacy GuidesのTor Overview、Tor Projectの旧wiki、AirVPNの公式ページの記述を組み合わせたものである。

観測者Tor over VPN（VPN → Tor）VPN over Tor（Tor → VPN）
ISPVPNサーバーへの暗号化通信。Torを使っていることは直接は見えないTorの入口リレーへの接続。Torを使っている事実が見える
VPN事業者利用者の実IPと、Torネットワークへ接続していること。閲覧先は見えないTorの出口リレーのIP（実IPは見えない）と、利用者の最終的な接続先
Torの入口リレーVPNサーバーのIP利用者の実IP
Torの出口リレー接続先と、暗号化されていない通信の中身VPNサーバーへの暗号化通信のみ
接続先Torの出口リレーのIPVPNサーバーのIP

Tor over VPNについて、Privacy GuidesのTor Overviewは三者の視点をこう書いている。ISPからは普通にVPNを使っているように見える。VPN事業者からは「they can see that you are connecting to the Tor network, but nothing about what websites you're accessing」。Tor側からは通常の接続に見え、Torネットワークが侵害されるという起こりにくい事態でも、露出するのはVPNのIPだけだ、と。

VPN over Torの側については、AirVPNの公式ページが自社のTor mode（後述）について、AirVPNのサーバーには利用者の実IPではなくTorの出口のIPが見えると説明している。Tor Projectの旧wikiは、この順序が出口リレーから通信を隠して守る一方、VPN側に通信が集まる点を問題にしている。

表の右列で、VPN事業者の欄に「最終的な接続先」が入っていることに注意してほしい。VPN over Torでは、匿名で契約していない限り、契約情報と接続先が一か所にそろう。

Tor over VPN（VPN → Tor）が合理的になる場面#

何を守り、何を守らないか#

この順序の効果は、ISPや同じネットワークの管理者から「Torを使っている事実」を見えにくくすることにほぼ尽きる。Privacy Guidesは、Torに直接つなぐと地域のネットワーク管理者やISPから目立つと書き、VPNの通信は一般的な用途に紛れやすいとして、この順序を勧めている。同サイトは、自分の脅威モデルにISPや地域のネットワーク管理者が含まれる場合、あるいは敵対者がISPから情報を引き出せる場合には、VPNを併用したほうがよいとも書く。

逆に、自由な国で日常的な内容を閲覧し、ISPにTorの利用を知られても困らない人は、直接Torにつないでもおそらく問題ない、というのが同ページの立場である。Tor Projectの旧wikiも、この順序が良い考えになるのは「assuming your VPN/SSH provider's network is in fact sufficiently safer than your own network」の場合だと条件を付けている。

守らないものもはっきりしている。VPN事業者には実IPと「Torへ接続していること」が見える。ISPから隠した事実を、VPN事業者に預け替えているにすぎない。VPN事業者を選ぶ基準はノーログVPNの記事で扱った。また、VPNの通信であっても通信パターンから中身の種類を推定されうる。Tor Projectの旧wikiは、VPNやSSHはWebサイト・フィンガープリンティングという受動的な解析に弱く、VPNの中のTor通信が分類されうることは想像に難くないと書いている（同wikiは、その点を直接扱った研究はないとも添えている）。Privacy GuidesもVPNの通信がフィンガープリンティングに弱い可能性に触れている。「ISPから完全に隠せる」わけではない。

検閲回避の手段ではない#

Privacy Guidesは、この推奨を検閲回避の助言ではないと明記している。理由は「if Tor is blocked entirely by your ISP, your VPN likely is as well」。目的は、通信を一般的なVPN利用者の中に紛れさせ、ISPに対して一定の「もっともらしい否認」の余地を残すことだという。

それでも、Torへの直接接続は遮断されていてVPNへの接続は通る、という環境は存在する。その場合にTor over VPNが接続を確保する手段になりうることは、VPN Router配下のQubes OSの記事で条件を詰めた。

VPNが切れたときの問題#

この順序で見落とされやすいのが、VPNのトンネルが切れた瞬間である。Tor Projectの旧wikiは、VPNに先につなぐのを忘れる、VPNが落ちたときに特別な対策がなければ直接接続が行われる、という二つの失敗を挙げている。Tor over VPNの目的が「ISPにTorの利用を見せない」ことなら、トンネルが切れてTorが直接入口リレーにつながった時点で目的は崩れる。キルスイッチの役割と限界はキルスイッチの記事、DNSが外に漏れる経路はDNSリークの記事で確認できる。

Whonixの文書も、VPNソフトが「fail closed」（切断時に通信を止める動作）になっていない可能性を警告し、Whonix上で漏れを防ぐ仕組みを伴ったOpenVPNを組むのは難しいと書いている。ただし同じページは、VPNをTorの検閲回避のためだけに使っているなら、トンネルの断絶は大きな問題にならないかもしれない、とも添えている。

VPN over Tor（Tor → VPN）が合理的になる場面#

公式文書はそろって否定的#

この順序については、確認した公式文書の評価がほぼ一致している。

Tor Projectの旧wikiは、Torの後ろに何かをつなぐ構成全体を「This is generally a really poor plan.」と書く。理由は、Torは通常ネットワーク上の経路を頻繁に変えるが、固定の行き先を置けばその利点を手放すことになり、匿名性に深刻な影響を及ぼしうるからだ。Privacy GuidesのTor Overviewも「We very strongly discourage combining Tor with a VPN in any other manner」とし、避けるべき構成として「You → Tor → VPN → Internet」と「You → VPN → Tor → VPN → Internet」を名指ししている。固定の行き先となるVPNを置くと、変化する経路の利点を消し、匿名性を大きく損なう、という説明は旧wikiと同じである。

それでもこの順序を使う人がいる理由も、両方の文書に書かれている。Torの出口リレーのIPを遮断するWebサイトを避けるためだ。

例外として語られる条件#

例外の条件を最も具体的に書いているのは、Privacy Guidesのコミュニティフォーラムに2024年1月14日に投稿された回答である。サイト本体の文書ではなく、フォーラム参加者の回答である点は区別しておく。回答は「VPN over Tor is generally never recommended.」としたうえで、例外を一つだけ挙げる。Torと匿名の支払い手段でVPNを購入し、そのVPNをTor経由でだけ使う場合である。その場合でも「the more you use it, the more traceable you become」、つまり同じ契約を使い続けるほど追跡されやすくなる、と書いている。

Tor Projectの旧wikiも、同じ方向の注意を書いている。この順序なら出口リレーから通信を隠せ、VPNは少なくとも自分で選べる。その代わり匿名で支払う必要がある。さらに「Even if you pay for them anonymously, you're making a bottleneck where all your traffic goes」と続け、VPNがすべての行動のプロファイルを作れるため、時間がたつほど危険になりうると書いている。

二つの文書を合わせると、この順序が成り立ちうるのは、契約・支払い・利用の全体が実名から切り離されていて、Torの出口を遮断するサイトに届く必要があり、使い込むほど一つの契約に行動が蓄積する代償を受け入れる場合、と読める（ここまでは当サイトの整理である）。支払い経路を切り離す方法とその限界はVPNを匿名で支払う方法で扱った。どれか一つでも欠けるなら、この順序は通信を一点に集める仕組みを足すだけになる。

事業者の実装例: AirVPNのTor mode#

当サイトで個別レビューを書いた事業者のうち、VPN over Torの接続方式を公式に用意していることを確認できたのはAirVPNだけである。AirVPNの公式ページによれば、「Tor mode」はTorを経由してAirVPNのサーバーにつなぐ方式で、「This connection mode works ONLY with AirVPN Client」とされ、同社クライアントの遮断機能であるNetwork Lockとは「not compatible with Network Lock at the moment」である。欠点として「Fixed Tor circuit for each OpenVPN session」も挙げられている。つまりOpenVPNのセッションの間、Torの経路は固定される。ページはOpenVPNを前提にしており、WireGuardで使えるかどうかは書かれていない。詳細はAirVPNのレビューを参照してほしい。

Tor Projectの旧wikiは、この順序はVPNをTCPで動かす必要があり、Torを通したVPN接続の確立は不安定で調整が要る、とも書いている。

「VPNサーバーがTorに中継する」機能は別物#

VPN事業者のアプリに、Tor用のサーバーを選ぶとそのままTorネットワークにつながる機能がある。経路の順序としてはVPN → Torだが、端末側でTor Browserを使わない点が、ここまで扱った構成と違う。

Proton VPNのサポートページは、有料プランで使える「Tor over VPN」機能を説明し、Torサーバーに接続すると通信が自動的にTorネットワークを経由し、通常のブラウザで.onionサイトを開けると書いている。同ページは、TorはTCPしか運べないこと、通常のVPNサーバーより大幅に遅いことも明記している。NordVPNの「Onion Over VPN」も同じ原理で、公式ページは「you connect to a VPN server first, then access the Onion network」と説明する。同ページは、この機能でTor Browserが不要になり、ChromeやFirefoxなどでOnionネットワークを使える、Tor Browserだけを使うより安全でプライバシーが高い、とまで書いている。

この最後の主張は、Tor Projectの説明と真っ向から食い違う。Tor Projectのサポートページは、Tor Browser以外のブラウザでTorを使うことに強く反対し、そうしたブラウザはDNSリークやWebRTCを通じた実IP、OS・フォント・プラグインの情報によるフィンガープリンティング、セッション後に残るCookieやキャッシュから身元を明かしうると書いている。Tor Browserは利用者を互いに見分けにくくするよう改変されており、それが匿名性を大きく高めている、という説明である。

事業者の主張とTor Projectの説明のどちらを採るかは読者の判断だが、当サイトとしては、匿名性を目的にするなら、VPN事業者のTor中継機能を通常のブラウザで使う構成はTor Browserの代わりにならない、と考える（これは上記二つの公式文書を比べたうえでの当サイトの評価である）。.onionサイトをときどき開けるようにする便利機能として理解するのが妥当だろう。WebRTCからの漏れについてはWebRTCリークの記事で扱った。

Whonixでの実装と、TCPの制約#

ネットワークの構成で順序を強制したい場合、WhonixはTorを担うゲートウェイ（Whonix-Gateway）と作業用の環境（Whonix-Workstation）を分けているので、VPNをどこに置くかで順序が決まる。Whonixは両方の順序の文書を用意しているが、どちらも「community support only」の扱いである。

VPN → Torの順（VPNをTorの手前に置く）#

Whonixの「Connecting to a VPN before Tor」は、VPNを置く場所を三つ挙げている。

一つ目はホストOS上で、この場合はホストのすべての通信がVPNを通る。ISPからすべての通信を隠したい場合の選択肢である。二つ目はWhonix-Gatewayの内側で、VPN事業者に見えるのをTorの通信だけに限りたい場合の選択肢になる。手順はOpenVPNの設定ファイルを置き、Whonixのファイアウォール設定でVPN用のモード（VPN_FIREWALL=1）を有効にし、OpenVPNのサービスを起動してからTorを有効にする流れで、VPNを止めたときにTorもWorkstationもどこにもつながらなくなることを確認するよう求めている。三つ目はQubes OS専用の構成で、Whonix-Workstation → Whonix-Gateway → sys-vpn → sys-firewall → sys-netという階層にVPN用のVM（sys-vpn）を挟む。この構成をVPNルーターと組み合わせる設計はVPN Router配下にQubes OSを置くで詳しく扱った。

この順序では、UDPのVPNで問題ない。Whonixの文書は、sys-vpnを分ける構成について「Both TCP and UDP VPN connections should work.」、Whonix-Gatewayの内側に置く場合も「The VPN in UDP mode should work just fine.」と書いている。TorはUDPを運べないが、この順序ではVPNの通信がTorの中を通らないからである。WireGuardのようなUDPのVPNもこの順序なら制約を受けない。

Tor → VPNの順（VPNをTorの中に通す）#

TCPの制約が出るのはこちらの順序である。Whonixの「Connecting to Tor before a VPN」は「UDP-style VPN connections are incompatible with Tor; the VPN must be configured to use TCP.」と書き、OpenVPNの設定にproto tcpを加えるよう指示している。Proton VPNの文書が書いているように、TorはTCPしか運ばない。

同じページは、この順序の欠点として、プロキシ設定を持たないアプリケーションの通信がすべてVPNを通ることで、身元の相関の危険が高まる点を挙げている。Tor BrowserはVPNの手前にTorを置く使い方を想定していないため、Tor Browserのプロキシ設定を外す回避策が要り、それによってTor Browserの「Stream Isolation」（接続先ごとに経路を分ける仕組み）が壊れる、とも書いている。設定後の確認では、ブラウザにはVPNのIPが見え、Tor Browserが「You are not using Tor」と表示されるのが想定どおりの結果だとされる。手間と引き換えに、Tor Browserが持つ保護の一部を自分で外す構成だということになる。

ブリッジのほうが適切な場面#

ISPからTorの利用を隠す手段として、VPNの代わりによく挙がるのがTorのブリッジである。Tor Projectの説明では、ブリッジは通常のリレーと同じくボランティアが運用するが、公開リストに載らないため敵対者が見つけにくい。多くのPluggable Transportはブリッジを使い、その代表であるobfs4は「makes Tor traffic look random, and also prevents censors from finding bridges by Internet scanning」とされる。ブリッジはTorが遮断されている場所でTorネットワークに入るための仕組みである。

目的が「Torへの接続が遮断されている環境でTorにつなぐ」ことなら、ブリッジが第一の選択肢になる。Privacy Guides自身が、Torが遮断されていればVPNもおそらく遮断されている、と書いていることとも整合する。VPNと違って事業者との契約や支払いが要らず、VPN事業者という新たな観測者を足さずに済む点も、脅威モデルによっては大きい。各方式の使い分けはPluggable Transportの記事で扱う。

ただし、ブリッジが「Torの利用を隠す」点でVPNより優れているとは言い切れない。Privacy GuidesのTor Overviewは、ブリッジは検閲回避には一時的な利点しかなく、obfs4やmeek、Snowflakeといった方式も標準的な通信解析で検知されうると書く。さらに、後になってそのブリッジのIPが明らかになって遮断されれば、ISPは過去の接続記録からTorの利用を特定できる、と指摘している。VPNの利用は一般的なので、ISPが長期保存するメタデータに対して否認の余地を残しやすい、というのが同サイトの見方である。同ページは、VPNが遮断されている環境ではブリッジが唯一の選択肢になりうること、VPNとブリッジ（できればobfs4）を組み合わせる方法もあることも書いている。

Tor Project側は、VPNもWebサイト・フィンガープリンティングの対象になると旧wikiで書いており、どちらの手段も「Torの利用を確実に隠す」ものではない。遮断を越えたいのか、後から記録を調べられたときの否認の余地を残したいのかで、選ぶ手段が変わる。

限界と残るリスク#

どちらの順序でも、匿名性は「完全」にはならない。Tor Projectの旧wikiが書くとおり、VPNは常に固定の入口か固定の出口として振る舞い、ある危険を減らす代わりに別の危険を持ち込む。資源の大きい全体的な観測者に対しては、ホップを増やしても受動的な攻撃がわずかに難しくなるだけで、攻撃面と外に出るデータが増える分、能動的な攻撃は容易になる、とも書いている。VPN事業者が敵対者の支配下にあれば、Torの保護はかえって弱まる。

回線の両端を観測できる相手には、順序の工夫は効かない。Tor over VPNでは、ISPが見るVPNサーバーへの通信と、VPN事業者が見るTor入口への通信の時刻と量が対応する。組み合わせによって記録の置き場所は変わっても、記録が消えるわけではない。この限界はタイミング相関の記事で詳しく扱った。

端末とアカウントも範囲外である。ブラウザの脆弱性、マルウェア、ファイルのメタデータ、実名のアカウントへのログインは、VPNとTorをどう組み合わせても防げない。Tor Browserの使い方での典型的な失敗はTor Browser実践ガイドにまとめた。

最後に、構成を複雑にすること自体が失敗の原因になる。Tor Projectが「上級者以外には基本的に勧めない」としているのは、設定を誤ったときに匿名性が下がるからであり、VPNが切れたときの直接接続、Tor Browser以外のブラウザでの利用、Stream Isolationの喪失は、いずれも本記事で見たとおり、組み合わせ方の誤りから生じる。

まとめ#

ISPや職場のネットワークに「Torを使っていること」を知られたくない人で、信頼できるVPNを既に使っているなら、Tor over VPN（自分 → VPN → Tor）が合理的である。その場合は、VPNが切れたときに通信が止まることを確認し、VPN事業者には実IPとTorの利用が見えることを受け入れたうえで、Torの通信はTor Browserで行う。ISPにTorの利用を知られても困らないなら、VPNを足さずに直接Torにつなぐ選択も、Privacy GuidesとTor Projectの記述のどちらとも矛盾しない。

Torへの接続そのものが遮断されている環境なら、最初に試すのはVPNではなくブリッジである。遮断の状況に応じた方式の選び方はPluggable Transportの記事で確認してほしい。

VPN over Tor（自分 → Tor → VPN）は、Torの出口を遮断するサイトに届く必要があり、契約と支払いを実名から切り離せる場合に限って検討の対象になる。その場合でも、一つの契約を使い続けるほど行動が蓄積することを前提に、用途を絞って使う。こうした条件を満たせないなら、この順序を足す理由はない。

VPN事業者のTor中継機能を通常のブラウザで使う構成は、.onionサイトを開くための便利機能と考え、匿名性が必要な作業はTor Browserで行う。国家級の相手のように回線の両端を観測しうる相手を想定するなら、順序の選択より、タイミング相関の記事で扱った運用面の対策を先に検討したほうがよい。

出典#