Tor か VPN か：それぞれの経路があなたに誰を信頼させるかで決める
VPN は信頼を一つの事業者に積み上げ、Tor はリレーに分散させます。カバレッジ、誰があなたをサイトに結び付けられるか、何を検証できるかで決めましょう。
Tor と VPN のどちらを選ぶかは、接続の両端を見るのをどちらの当事者に許容できるかという問題に帰着します。VPN はその視野を、あなたが選んだ一つの事業者に集中させます。Tor はそれをリレーに分散させるので、単一のリレーがあなたが誰で何を取得したかを学ぶことは想定されていません。
どちらの仕組みも、それ自体であなたを匿名にするものではありません。残っている信頼を声に出して言える方を選び、それが覆わない部分を修正しましょう。
誰があなたを宛先に結び付けられるかを数える
VPN では、対象となるすべてのフローが宛先に届く前に事業者の出口へ到達します。その事業者は必然的にあなたの送信元アドレスを見て、それを経由して暗号化されていないものについては、あなたが要求した宛先も見ます。TLS はページの内容をその視野の外に保ちますが、通常、接続の確立中はホスト名を可視のままにします。したがって一つの当事者があなたをサイトに結び付けられ、その結び付きこそがあなたが与えている信頼です。
Tor はその両半分を三つのリレーに分けます：あなたのアドレスを知るが宛先は知らないガード、どちらの端も知らない中間リレー、宛先を知るがあなたは知らない出口です。この設計は、単一のリレーが両方の事実を結合しないことを前提にしており、これは一社を信頼するより弱く、より有用な前提です。リレーが正直であることは前提にしておらず、経路の両端を見る観察者も打ち負かしません。
どちらの設計にも一つの弱点があり、それは宛先にあります。ログインすれば、パケットがどの経路を通ってそこへ届いたとしても、サービスはそのセッションをあなたのアカウントに結び付けます。ルーティングが変えるのは、要求がどこから来たように見えるかであり、ページがあなたに何を提供するよう求めるかではありません。
ルーティング図よりカバレッジが重要
VPN はネットワーク層でルーティングするため、意図的に除外しない限り、デバイス上のすべてのアプリケーションがトンネルを継承します。この広さが、メールクライアント、パッケージマネージャー、ブラウザーで同時に機能する理由です。
Tor Browser はバンドルであり、その保護は主にブラウザーの中で生きています：均一なフィンガープリント、サイト間の分離、そしてインストールした拡張機能ではなくセキュリティレベルによって制限されるスクリプトです。 Chrome を SOCKS ポートに向けても、ルーティングが手に入るだけで、そのどれも得られません、これは誤った場所での自信のよくある源です。
デスクトップの残りは手つかずです。同期クライアント、アップデーター、別のプログラムで開いたダウンロード済みの文書は、そのプログラムの設定どおりに接続し、そこで設定しない限り SOCKS リスナーを通りません。ネットワークと話すアプリケーションを列挙し、選んだ道具が実際にどれを覆うのかを問いましょう。カバレッジはあなたの設定の性質であり、意図の性質ではありません。
三つの条件で選ぶ
決定は通常、三つの問いで解けます：トラフィックは一つのアプリケーションから来るのか、デバイス全体から来るのか、宛先はあなたのアドレスを識別できてはならないのか、プライベートネットワークに到達する必要があるのか？この順に答えれば、道具はたいてい自らを選びます。
| Requirement | Better fit | Reason |
|---|---|---|
| Every app covered, including non-browser traffic | A device VPN | Routing happens below the application, with a kill switch to stop leaks |
| Destination must not learn your address | Tor | The site sees a shared exit address rather than one tied to your account |
| Browser fingerprint that blends in | Tor Browser | The uniformity ships with the browser, a proxy alone adds none of it |
| Access to a private subnet or office resource | A VPN | Tor exits reach the public internet, not your internal routes |
二つの要件が衝突するときは、どちらを実行できるかを天秤にかけましょう。除外リストが漏れるデバイストンネルは、あなたが実証できるブラウザー限定の経路より悪いです。
検証はどちらの経路でも安価であり、どちらかに頼む前に済ませるべきです：
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
最初のコマンドの誤った結果は、要求が回線の外へ出たことを意味し、それが早く捕まえる価値のある失敗です。二つ目は、プロバイダーが割り当てたアドレスと比較し、先週覚えていたアドレスとは比較しないでください。
どちらの選択肢も修復しないもの
アプリケーションの暗号化は、どの経路も行わない仕事を依然として行います。プライバシーネットワークを横切る平文の HTTP は出口で読めるままであり、HTTPS はペイロードを端から端まで守る唯一のものです。TLS はまた、あなたが入力したホスト名について何も語らないため、経路を終端する者に宛先が見えたままになります。
アカウントはあなたを識別し、どのルーティングの選択もそれを変えません：ヘッダーのアドレスに関係なく、サービスは誰がサインインしたかを知っています。十分なネットワークを見る観察者による相関、あなた自身のデバイスの侵害、フォームに入力するすべては、どちらの設計でも生き残ります。両方の道具を、信頼を削除する方法ではなく、移動させる方法として扱ってください。
各プロジェクトが文書化している既定の構成から始め、上の二つのコマンドで経路を確認し、それから初めて Tor の下に VPN を重ねることを検討してください。それらを入れ子にするのは、独自の故障モードを持つ構成であり、無料のアップグレードではありません。