VPN をオンにしたときだけサイトにブロックされる？サイトが見ているのはこれだ
ブロックの原因は通常、漏えいではなく出口アドレスだ。トラフィックがどこから来たように見えるか、サイトが記録できるリゾルバー、ページコードが知っていることを確認しよう。
店は自宅では問題なく開くのに、トンネルが上がった瞬間に「異常なトラフィック」の壁が現れる。フォーラムはログインを拒否し、ストリーミングページは一度も訪れたことのない国にいると主張する。どれもスパイウェアを必要としない。サイトはパケットが届く元のアドレスを見ており、VPN を使うとそのアドレスは家庭回線ではなくデータセンターのものになる。VPN 検出と呼ばれるもののほとんどはこの一つの事実から始まり、そこで終わる。残りは予測可能な誤り率を持つ推測だ。
ブロックはパケットがどこから来たように見えるかから始まる
すべてのリクエストは送信元アドレスを持ち、受け取るサーバーは公開データでそれを調べられる。どのネットワークが告知しているか、そのネットワークがホスティング事業者か、悪用リストに載ったことがあるか、レジストリがどの国を割り当てているか、といったことだ。どれもあなたを特定しないが、すべて合わせれば分類するには十分だ。
自分のトラフィックを他人の目で見てみよう。二つのコマンドで大半の表面を覆えるが、二つ目こそ忘れられがちだ。
curl -sS https://ipinfo.io/json
dig +short TXT o-o.myaddr.l.google.com @ns1.google.com一つ目は出口アドレス、その組織、国を返す。二つ目は Google のネームサーバーに到達したリゾルバーのアドレスを返す。これは出口とは別のネットワークであることが多く、サイトがリゾルバー側のデータを記録していれば、それがサイトの見るアドレスになる。この二つが別の国に属していると、設定に何も問題がなくても、不一致を怪しむサイトがある。
トンネルが上がってから拒否が始まるなら、まず出口アドレスを疑おう。ブラウザーに触る前にサーバーを変えて再試行する。同じ事業者の三つの出口でブロックが付きまとうなら事業者の範囲の問題であり、別のサーバーで消えるならその一つのアドレスの問題だ。
タイムゾーン、言語、時計がアドレスと一致しない
ページコードは許可を求めずに、あなたのタイムゾーン、言語設定、画面設定を読める。接続がシンガポールのデータセンターから来ているのにブラウザーが中央ヨーロッパ時間を報告するのは、アドレス単体より強いシグナルであり、詐欺スコアリングがまさに検知するために作られている不一致だ。
Intl.DateTimeFormat().resolvedOptions().timeZone
navigator.language
Intl.DateTimeFormat().resolvedOptions().locale開発者コンソールのその三行は、ブラウザーが自発的に何を渡しているかを教えてくれる。VPN クライアントは経路を変えるだけで、それ以外は何もしない。だから持ち歩くプロファイルは国内のままで、出口だけが国外になる。ここで重要なのは一貫性だ。出口と同じ地域に設定されたノート PC は普通に見えるが、自分自身と矛盾する PC はそう見えない。
失敗が断続的なのはそのためだ。気にしないサイトが多く、一部はスコアを付け、ある会員サイトはあなたを詐欺師だと判断する。どの場合もクライアントは正しく動いている。だから「きっとブラウザーのせいです」といういつものサポートの答えは、腹立たしいと同時に部分的には正しい。
ページコードが実際に知っていること
JavaScript にはネットワークインターフェースを列挙する API はない。ページはノート PC がどのアドレスを持つか尋ねられない。だからスクリプトが LAN アドレスを読むという古い主張は、ActiveX コントロールや Java アプレットなどのネイティブコードがそれをできたプラグイン時代の記憶にすぎない。
| Signal | What it reveals | Status today |
|---|---|---|
| Source address of the request | Exit network, country, hosting status | Always visible; the main signal |
| Time zone and language | Where the profile claims to be | Readable without permission |
| WebRTC candidates | Local addresses, historically | Host candidates are mDNS-obfuscated by default |
| Interface list | All local addresses | Not available to ordinary JavaScript |
WebRTC は「ローカルアドレスの漏えいはない」という原則の正直な例外だ。かつては候補の収集が、求めたすべてのページにローカルアドレスを露出していた。修正はホスト候補をランダムな mDNS 名に置き換えることだった。その既定値は現在のブラウザーで有効だが、プロトコルの保証ではなくブラウザーの判断なので、古いビルドやローカル候補を再有効化する厳格な設定では今も漏えいしうる。ここではどんな拡張機能よりもブラウザーの更新が役に立つ。
事業者は中身ではなく名前を見る
HTTPS はページの中身を端から端まで守り、そのバイトを転送するトンネル事業者は読めない。それでも事業者は、あなたがどのアドレスに接続したかを見られる。多くの配備ではハンドシェイク内のサーバー名も見える。正しいサイトへ接続を振り分けるには名前が読める必要があるからだ。Encrypted Client Hello はまさにそのフィールドを隠すために存在し、クライアントとサイトの両方が対応しているときだけ役に立つ。
名前解決はもう半分だ。事業者がリゾルバーも提供していれば、接続が存在する前に、あなたが引くすべての名前を見る。端末が HTTPS 経由で公開リゾルバーを使うなら、事業者に見えるのはそのリゾルバーへの接続だけで、リストを見るのはリゾルバー自身だ。
暗号化されていない HTTP リクエストは、ホテルのネットワークから読めるのと同じ理由で事業者からも読める。中身が暗号化されていないのだ。トンネルはそれ以上を主張したことはなく、アプリケーションの選択を直しもしない。
「これは VPN」と「これは自分」を分ける
検出は安価で確率的で、しばしば間違う。共有の出口アドレスは誰かが悪用したために印を付けられ、企業の範囲はホスティングと分類され、携帯事業者は誰もが驚く地理的結果を出す。特定は別の問題だ。サインインしたアカウント、Cookie、支払い情報、あるいはメモを突き合わせる二人の観測者といった、持続的なつながりが必要になる。
本当にどちらと戦っているのかを決めよう。目的がページを読むことなら、HTTPS がすでにその仕事をしており、トンネルはほとんど変えない。目的がサイトにどの都市にいるかを知られないことなら、出口とリゾルバーが重要だ。目的が本当の身元とのつながりを断つことなら、弱いのはアカウントであり、サーバーを変えても今使ったログインには何の効果もない。
新しい出口はどこからもログアウトさせず、使ったアカウントについてサイトがすでに保存したものを消すこともできない。実際の手順は地味だ。ネットワークが普通に見える出口を選び、ブラウザーのプロファイルをそれと一致させ、漏えいしやすい機能が現代の既定値を使うようブラウザーを更新し、少数のサイトは依然としてあなたを誤って推測すると受け入れる。