著者 TorとVPNの違い、どちらが必要ですか？
TorとVPNは解決する問題が異なります。各ホップでISP、VPN事業者、Torリレー、接続先に何が見えるかと、契約者名義のVPSが匿名化ツールにならない理由を解説します。
Tor と VPN のどちらが実際に必要か
Tor と VPN はどちらも、自分が管理していないマシンを経由してネットワークトラフィックを送信しますが、解決する問題は異なります。VPN（仮想プライベートネットワーク）を使うと、信頼先がインターネットプロバイダーから 1 社の VPN 事業者に移ります。その事業者は、実際のアドレスとアクセスしたすべての宛先を把握できます。Tor では、信頼を異なる運用者が管理する 3 台のリレーに分散します。そのため、1 台のリレーだけでは、利用者が誰で、どこへ接続しているかの両方を把握できません。自分が隠れたい相手を明確にして、選択してください。
隠れたい相手が、現在接続しているネットワークの管理者であれば、VPN が適しています。相手が Web サイト自体、または 1 社の記録の提出を強制できる者であれば、Tor が適しています。このガイドの残りでは、この 2 つの文の背景にある詳細を説明します。
両方の構成で 1 つのリクエストを追跡する
一般的なリクエストを 1 つ取り上げます。ブラウザーが https://news.example.com を開きます。どちらの構成でも、TLS（transport layer security）がページの内容を保護するため、通信の途中にいる第三者が記事を読むことはできません。重要なのはメタデータです。誰があなたの IP アドレスを知るのか、誰が接続先を知るのか、そして誰がその 2 つの情報を結び付けられるのかが問題になります。プライバシーツールは、その 2 つの情報を切り離すための仕組みです。VPN は、その組み合わせを別の管理者へ移します。Tor は、それを分離します。
VPN を使用したときに各当事者から見える情報
クライアントはすべてのパケットを暗号化し、1 つのエンドポイントへ送信します。そのエンドポイント以降では、パケットは再び通常のトラフィックになります。
- ISP (internet service provider) からは、回線と 1 つの VPN サーバーアドレスの間で交換される暗号化パケットが見えます。通信量とタイミングは分かります。ただし、DNS (domain name system) クエリもトンネルを通る限り、宛先ホスト名は分かりません。
- VPN operator からは、一方に実 IP アドレス、もう一方にすべての宛先アドレスが見えます。時刻とサイズも分かります。この両側の情報は同じマシンに到達します。
- 宛先からは、VPN の出口アドレスと、ブラウザーが送信するすべての識別情報が見えます。
したがって、VPN は匿名性を作り出しません。監視者を ISP から VPN provider へ移すだけです。ローカルネットワークに問題がある場合や、ISP が取得した情報をフィルタリングまたは再販売している場合には、実質的な利点があります。訪問先のサイトに対しては、まったく利点がありません。トラフィックは、あなたが誰かを正確に把握し、支払い記録を保持する 1 社からの 1 つのストリームとして、引き続き到達するためです。
「no logs」という主張が製品全体の価値であり、あなたの側から確認できない唯一の部分です。トンネルが確立していることは確認できます。DNS が漏洩していないことも確認できます。しかし、operator がディスクに何を書き込むかは確認できません。これが受け入れる取引条件です。自分で選んだ 1 社が、全体像を保持します。
トンネルをひそかに無効化する漏洩を確認します。
resolvectl status
curl -s https://ifconfig.me; echoifconfig.me が表示するアドレスは、VPN の出口アドレスである必要があります。デフォルトルートを運ぶリンクに設定された DNS サーバーは、トンネルの resolver である必要があります。192.168.1.1 にローカルルーターが表示される場合、名前解決はローカルリンク上を平文で送信されています。これは、そのルーターへのルートが on-link であり、トンネルのデフォルトルートより具体的だからです。トラフィックはプライベートでも、アクセスしたサイトの一覧は隠れていません。WireGuard トンネルから DNS クエリが漏れる場合の修正で、対処方法を説明します。
Tor を使用したときに各当事者に見える情報
Tor は、少数のディレクトリ機関が公開する署名済みリストであるコンセンサスから選ばれた 3 つのリレーで回路を構築します。クライアントは、リレーごとに 1 層ずつデータを暗号化します。各リレーは 1 層だけを取り除き、次のホップだけを把握して、残りを転送します。この多層構造により、経路上の誰も両方の情報を同時には把握できません。
- ISP からは、1 つのガードリレーへの暗号化された通信に見えます。リレーのアドレスは公開されているため、ISP は Tor を使用していることを把握できます。ただし、どこへ接続しているかは把握できません。
- ガードリレーには、実際の IP アドレスが見えます。ただし、宛先は見えません。サイト名を含むメッセージの部分は、その後のリレー向けにまだ暗号化されているためです。
- 中間リレーからは、一方にガード、もう一方に出口リレーが見えます。あなたも宛先も見えません。ガードと出口リレーが直接通信しないようにするために存在します。
- 出口リレーには、宛先とネットワークから出ていく通信が見えます。見えるのは中間リレーのアドレスであり、あなたのアドレスではありません。HTTPS を使用している場合、把握できるのはホスト名と接続メタデータであり、ページの内容ではありません。
- 宛先からは、公開された出口リストに掲載されている出口リレーのアドレスと、ブラウザーが送信する情報が見えます。
あなたとサイトを結び付けるには、ガードと出口を同時に監視する必要があります。これが設計を一文で表したものです。そのため、クライアントは起動のたびに新しいガードを選ばず、同じガードを数か月間使用します。入口を常に切り替えると、悪意のあるリレーにガードになる機会を繰り返し与えることになるためです。
回路は永続的ではありません。新しい接続はおよそ 10 分ごとに新しい回路へ移ります。一方、すでに開いているストリームは、開始時に使用した回路に留まります。長時間のダウンロードと、15 分後に開いたタブは、通常は異なる出口から接続します。
どのリレーも他のリレーを把握せずに 3 つのホップを構築する方法
クライアントは、リレーの一覧をガードに渡しません。最初にガードと鍵をネゴシエートし、次にガードを経由して回路を中間リレーまで拡張する要求を送信します。その後、そのホップを経由して、出口リレーまで拡張する追加の要求を送信します。各リレーに伝えられるのは、次に通信する必要がある隣接リレーの情報だけです。また、各ホップには固有の鍵があり、他のホップからは見えません。そのため、中間リレーは検査だけで出口の役割を把握できません。また、処理した内容をすべて記録するリレーであっても、記録できるのは 1 つの断片だけです。
インストールして経路を確認します。
sudo apt update && sudo apt install -y tor
systemctl status tor@default
journalctl -u tor@default -n 20
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ipログには Bootstrapped 100% (done): Done が表示されるはずです。curl には、見覚えのないアドレスを持つ {"IsTor":true,"IP":"..."} が表示されます。これは現在の出口リレーです。IsTor が false の場合、要求はプロキシを経由していません。Ubuntu のパッケージ版 Tor は最新リリースより遅れることがあります。上流版を追跡する必要がある場合、Tor Project は独自の apt リポジトリを公開しています。
このコマンドには注意点があります。--socks5 を指定すると、curl 自身がホスト名を解決してから、解決結果のアドレスをプロキシ経由で送信します。そのため、通常のリゾルバーには、アクセスしたすべての名前が伝わります。--socks5-hostname を指定すると、名前が Tor に送信され、出口リレーが解決します。同じトンネルでも、情報漏えいの内容はまったく異なります。Tor Browser と torsocks は正しく処理します。手動で設定したツールでは、正しく処理されないことがよくあります。
Tor が転送できるのは TCP ストリームだけです。UDP は転送できないため、ping 1.1.1.1 は Tor を経由しません。また、UDP ベースの VPN プロトコルを Tor 内で実行することもできません。プロキシ設定を無視するプログラムは、通常のアドレスを使用して通常の経路へ接続します。警告は表示されません。そのため、システム全体で Tor を使用する場合は、環境変数ではなく、別のボックス上の透過プロキシを使用します。
信頼が実際に置かれる場所
VPN は信頼を集中させます。1 社の事業者が、あなたの身元、請求記録、すべてのトラフィックパターンを保持し、保護はログを保存しないという事業者の約束に依存します。その約束が守られている間、構成は明快で、高速で、理解しやすいものです。召喚令状、侵害、または虚偽によってその約束が破られると、すべてのトラフィックに対して一度に、完全に破綻します。
Tor は信頼を分散させます。互いのことをほとんど知らない 3 者が、それぞれ情報の一部を保持します。その一部だけでは、ほとんど価値がありません。この構成を機能させるために、誰も完全に正直である必要はありません。必要なのは、十分な独立性です。その代わりに、速度、TCP のみの通信、そしてあなたを監視したい人々が運用しているリレーも確実に存在するネットワークを受け入れる必要があります。悪意のあるリレーに対する Tor の答えは、リレー 1 台だけでは決して十分にならないことです。
VPN が適している場合
- 現地のネットワークを信頼できない場合です。ホテル、空港、会議場、大家のルーターなどが該当します。運用者から見えるのは、暗号化されたトンネルだけです。
- 自分のマシンへ接続したい場合、または自分で管理する固定アドレスから通信したい場合です。
- 速度と UDP が必要な場合です。ビデオ通話、ゲーム、大容量転送、バックアップなどが該当します。
- Web サイトから追加確認を求められない安定したアドレスが必要な場合です。Web の広い範囲で、Tor の出口ノードはブロックされるか CAPTCHA を要求されます。
この一覧は、サブスクリプションを購入するのではなく VPS 上で自分の VPN を運用するべき理由を示しています。また、自分で設定する WireGuard サーバーを使えば、ログのポリシーを自分が所有する設定ファイルで管理できます。デバイス間の鍵管理も追加した同じトンネルが必要であれば、通常の WireGuard と Tailscale の違いを比較してください。これらはいずれも、この一覧にある用途には非常に適しています。ただし、次の一覧にある用途には対応しません。
Tor が適している場合
- 攻撃者にアクセス先のサイト、または単一の企業に記録の提出を要求できる人物が含まれる場合です。
- 回線まで追跡されると不利益を受ける内容を読んだり、公開したりする場合です。
- onion service を利用したい場合です。通信がネットワークの外へ出ず、exit relay を経由せず、サーバーのアドレスを隠したまま運用できます。
- ページの表示が遅いこと、CAPTCHA、そしてときどき
403 Forbiddenが発生することを許容できる場合です。
9050 番ポートを指定した普段のブラウザーではなく、Tor Browser を使用してください。ブラウザー自体が保護の半分を担います。その理由は、次の次のセクションで説明します。
匿名性では、レンタルした VPS は商用 VPN より不利です
ここは、よく誤解される点です。レンタルした VPS は、あなたの名前が記載されたリース契約です。登録時のメールアドレス、カード情報、請求書、サポートチケットは、すべてその IP アドレスとともに、1 社のデータベースに保存されます。IP アドレスとあなたを結び付けるために、何かを侵害する必要はありません。通常の会計処理のためにすでに記録されており、法的な根拠を持ってプロバイダーに問い合わせられる人なら誰でも入手できます。
2 つ目の問題は、利用者の多さです。商用 VPN の出口アドレスは、同じ時刻に多くの顧客で共有されるため、そのアドレスだけでは 1 人に特定できません。一方、VPS のアドレスはあなた専用です。そこから送信されるすべてのリクエストは、今日も翌月もあなたのものです。アドレスもローテーションされないため、接続先は Cookie がなくても、数か月にわたって利用状況のプロファイルを作成できます。
だからといって、セルフホスト VPN が悪いわけではありません。管理していないネットワーク上でトラフィックを暗号化したり、どこからでも自分のサービスに接続したりする用途には非常に有効です。ただし、匿名化ツールではありません。匿名化ツールとして使うことが誤りです。プロバイダーがそのマシン自体で確認できる情報と確認できない情報を簡潔に確認するには、VPS ホスティングの実際の安全性 を読んでください。
Tor でも VPN でも解決できないこと
- ブラウザーのフィンガープリント。ユーザーエージェント、画面サイズ、タイムゾーン、インストール済みフォント、言語、Canvas の描画結果が組み合わさり、多くの場合は固有の値になります。この値は、使用する IP アドレスが変わっても追跡に利用されます。Tor Browser は、利用者同士が同じように見えるようにし、ウィンドウサイズを一定の刻みで変更することで、この問題に対処します。SOCKS プロキシ経由で通常のブラウザーを使っても、フィンガープリントと Cookie はそのまま残ります。
- ログイン。氏名を把握しているアカウントにサインインした時点で、ネットワーク層による匿名化は意味を失います。自宅からのログインと、同じアカウントへの Tor 経由のログインがあれば、両方のセッションが関連付けられます。
- エンドポイントが記録する情報。入力した内容、購入した商品、検索した内容などです。
- エンドツーエンドの相関分析。回線と出口ノードを同時に監視できる攻撃者は、通信のタイミングとパケット量を照合して、両端を対応付けられます。Tor は、通信の両側を確認できる攻撃者からは防御できないと明記しています。
Tor と VPN は併用できますか？
VPN over Tor では、最初に VPN が接続し、その中で Tor が動作します。この場合、ISP から見えるのは VPN だけです。また、guard relay からは、あなたのアドレスではなく VPN のアドレスが見えます。ただし、氏名やカード情報を保有する企業を、まさにその情報を避けるよう設計されたシステムの手前に置くことになります。この構成に意味があるのは、回線上で Tor を使うこと自体が危険で、ほかに適切な選択肢がない場合です。
Tor over VPN では、トラフィックが Tor ネットワークを出た後に VPN アカウントへ入ります。この構成は設定が難しく、通常はより不適切です。そのアカウントには支払い記録が紐付いているため、直前まで匿名だったトラフィックに、固定的な身元情報を結び付けることになります。
目的が ISP から Tor の使用だけを隠すことであれば、対応策は bridge です。これは公開コンセンサスに含まれないエントリーポイントに、obfs4 や Snowflake など、トラフィックの分類を困難にする pluggable transport を組み合わせます。Tor Browser にはこの両方が含まれており、第三者の企業に氏名を渡す必要もありません。
FAQ
Tor は単なる無料の VPN ですか？
いいえ。VPN では、1 社が運用する 1 台のサーバーを経由して通信します。その会社は、実際のアドレスとすべての宛先を把握できます。つまり、ISP を自分で選んだプロバイダーに置き換える仕組みです。Tor では、異なる運用者が管理する 3 つのリレーを経由します。ガードは利用者を把握できますがサイトは把握できず、出口リレーはサイトを把握できますが利用者は把握できません。Tor は TCP のみに対応し、明らかに低速です。また、多くの Web サイトでブロックまたは追加確認の対象になります。そのため、VPN の日常的な用途をそのまま置き換えるものではありません。
ISP は Tor を使用していることを把握できますか？
デフォルトでは把握できます。リレーのアドレスは公開コンセンサスに掲載されているため、プロバイダーは既知のガードリレーへの接続を確認できます。ただし、どのサイトにアクセスしたかは確認できません。Tor の使用自体を隠すには、Tor Browser のブリッジを使用します。ブリッジは obfs4 や Snowflake などの pluggable transport に対応しており、公開リストに載っていないエントリーポイントを経由して接続します。Tor の前段に VPN を置く方法でも ISP から Tor の使用を隠せますが、その事実は VPN の運用者に伝わります。
自分の VPS で VPN を運用すれば匿名になりますか？
いいえ。サーバーは利用者名義と利用者のカードで借りるため、プロバイダーの請求記録ですでにそのアドレスと利用者が結び付いています。プロバイダーへの照会だけで、その記録を確認できます。また、そのアドレスを使用するのは利用者だけなので、そこから出るすべての通信は 1 人の利用者に属し、サーバーを保持する限り関連付け可能です。自己ホスト型 VPN は、ローカルネットワークに対しては強力なプライバシー保護手段です。一方、プロバイダーに照会できる相手に対しては、匿名性を高める手段としては限定的です。
Tor を使用すると、なぜ Web サイトにブロックされたり CAPTCHA が表示されたりするのですか？
出口リレーのアドレスは公開されており、非常に多くの利用者が共有しています。そのため、いずれかの利用者による不正利用が、借りているアドレスに結び付けられます。コンテンツ配信ネットワークは、そのようなアドレスを低く評価し、チャレンジ、403 Forbidden、または送信を拒否する登録フォームを返します。利用者側の設定でこの問題をなくすことはできません。新しいサーキットを使用すると別の出口リレーになります。その出口リレーの評価が高ければ、状況が改善する場合があります。
VPN を使用している場合でも、DNS クエリは漏洩しますか？
漏洩する可能性があり、よくある問題です。フルトンネルを使用し、トンネルインターフェースにリゾルバーを設定していない場合、クライアントはローカルネットワークから取得したリゾルバーを使い続けます。そのリゾルバーへの経路がリンク上にあるため、トンネルのデフォルトルートより優先されます。その結果、他の通信が暗号化されていても、DNS クエリは平文で送信されます。resolvectl status を実行し、デフォルトルートを運ぶリンクに表示される DNS サーバーが、ローカルルーターではなくトンネルのリゾルバーであることを確認してください。