VPN事業者はあなたがどのサイトを見たか分かるのか

VPNに何が見えるかを尋ねると、答えは経路のどこに立つかによって変わる。セッション層では事業者には認証イベントとバイト数がある。パケット層では宛先アドレスと時刻がある。DNS層では名前そのものを持つことがある。層ごとに別の問いに答えており、単一のスイッチで層をまたげるわけではない。

主張する前に層を特定する

同じ接続でも地点ごとに残る記録は異なり、プライバシーについての言明はその地点を名指しして初めて意味を持つ。表を列ごとに読んでほしい。その層に何が存在し、事業者がそこで何を見られ、同じ記録がなお何を語れないのか。

一つの層を全体像として読むことが、過大な主張と偽の安心の双方の始まりになる。閲覧を記録しないと言う提供者でも、URLの記録については正確でありながらセッション記録を保持している場合があり、アドレスだけを示すパケットキャプチャは、逆引きと推測なしには閲覧履歴にはならない。

方針を評価するときは、各層を説明する一文を探す。方針が層を分けていないなら、暗号化に関する一般論を受け入れるのではなく、どの記録が存在するのかを問うべきだ。

セッション目録: 標準のOpenVPNサーバーが保持するもの

既定のままでは、OpenVPNサーバーは通信をキャプチャしない。通常の出力はセッション目録だ。認証したアカウント、その送信元アドレス、開始と終了の時刻、割り当てたトンネルアドレス、双方向のバイト合計。これはセッションの目録であり、宛先の一覧ではない。

ログ設定は詳細を加えられる。詳細度を上げればハンドシェイクについてより多く書き、状態ファイルは接続中のクライアントを列挙できるが、どちらもサーバーを透過プロキシに変えるものではない。URLを生成するにはTLSを終端するか明示的なプロキシを動かす必要があり、どちらも隠れた機能を有効にするのではなく信頼の構図を変える。

だからこそ閲覧ログなしという主張の正確な版は、聞こえよりも狭い。サーバーはページを知らないが、セッションが存在したことと、およそどれだけのデータが通過したかは知っている。そのセッション記録を保持するか、どれだけ保持するかは別の方針の問いだ。

内側と外側のパケットは別の証拠になる

パケットキャプチャは、トンネルを実際に何が通過するかを見る手段だ。サーバー上でトンネルのインターフェースを指定し、後からオフラインで解析できるファイルに書き出す:

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

そのファイルには復号された内側の通信が入る。送信元としてクライアントのトンネルアドレス、宛先アドレスとポート、パケットサイズと時刻。どこかでTLSを終端していない限りHTTPのパスや応答本文は含まず、これは機密データであり、その保持はデバッグの便宜ではなく方針の判断だ。

物理インターフェースでのキャプチャは別のものを見せる。そこに見えるのはVPNエンドポイント宛ての外側パケットで、中に暗号化されたペイロードがある。仮想アダプターがあれば、そのファイルに無関係なアドレスが現れるのは正常だ。トンネルデバイスが内側のフローを運び、暗号化された転送が外側のフローを運ぶからだ。

そのキャプチャが何に答えるためのものかを問う。アプリケーションによるトンネルの利用は仮想アダプターに見え、エンドポイントへのトンネルの到達性は物理アダプターに見える。どちらか一方を全体像として扱えば、データが支えられない結論が出てくる。

DNSこそ名前が見える場所だ

DNSは実務上の例外であり続ける。リゾルバーは解決を求められた名前を見るので、それを運用する者は、後の接続が暗号化されていても、クライアントがどのサイトを引くかを知る。トンネルのキャプチャはアドレスを示し、リゾルバーは名前を示す。

リゾルバーが外部サービスへ到達するのに使ったアドレスを確認する。答えはリゾルバーの出口アドレスであり、VPNの出口と比べれば、問い合わせがトンネルを通ったかが分かる:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

そのアドレスがトンネルの出口ではなくローカル接続と一致するなら、名前解決はVPNを迂回し、名前はローカルの経路で見えていた。クライアントの更新後には再確認してほしい。新しい版ではプロファイルが入れるリゾルバーが変わりうる。

暗号化DNSは可視性を消すのではなく移す。ネットワークは問い合わせを見なくなるが、リゾルバーは依然として見ており、信頼の問いは持ち主を変えるだけだ。接続のハンドシェイクにおけるTLSサーバー名も部分的な手がかりで、ペイロードが不透明でも残ることが多く、宛先アドレスだけが転送サーバーの観測できるメタデータではない。

三種類の記録と、それを読める者

セッションの計数、名前ごとの記録、漏えいの証拠は、三つの異なる義務を負う三つの異なる成果物だ。セッションログは安価で感度が低く、誰がいつ接続したかに答える。名前ごとの記録には記録するリゾルバーか明示的なプロキシが必要で、影響を受ける人々への開示義務を生む。漏えいの証拠は、リゾルバーが明かすものとトンネルの出口を比べるクライアント側の検査だ。

この三つのどれを運用し、誰が読め、どれだけ残るのかを記録しておく。サービスはログを保持しないという言明は一つの層を述べており、その範囲内でしか正しくない。同じ提供者がセッションについては正確で、DNSについては誤っていることもある。

検査は再現できる形に保つ。同じリゾルバーへの問い合わせ、同じキャプチャインターフェース、同じ比較だ。名指しした層で検査できないプライバシーの主張は、運用上の事実ではなくスローガンである。