VPNは古いIPを漏らしていない——覚えていた値がそうさせた
新しい接続がVPNの出口を使っていても、サービスが古い公開アドレスを報告することがある。パケットの送信元ヘッダーと、アプリが保持していた値を分けて考えよう。
VPNが起動した後でサービスのレポートに古い公開アドレスが表示されても、それ自体は 漏えいの証拠ではない。実際の接続はトンネルの出口を使っていて、アプリがトンネル以前に覚えた値を送っている可能性がある。これは二つの別の証拠であり、現在のパケットを説明するのは片方だけだ。もう片方は、ネットワーク経路上の何も所有していないために再接続を生き延びた値である。
ひとつのアドレスの裏にある二つの説明
人が想像する順序は、VPNが有効なはずのときに物理インターフェースからパケットが出ていくというものだ。レポートをよく説明する順序はもっと短くて地味だ——アプリが以前にアドレスを覚え、いまも保持している。出来事を順に並べると、この二つは分かれる。
Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1
その順序のどこにも、最初のアドレスからの実接続は必要ない。覚えていた値はメッセージの中を運ばれ、ヘッダーは現在のルートが選んだ出口を運ぶ。両方のフィールドを記録するサービスは、それらを並べて表示し、矛盾しているように見える。
それはあり得る説明であって、特定のクライアントへの非難ではない。評判は証拠ではない——読めるコードベース、信頼するブランド、別の出口は、あるプログラムが何を保持し送ったかを何も語らない。
アプリの記憶は再接続より長く残る
VPNに接続すると、新しい接続がたどるルートが変わる。アプリの状態には手を付けず、リモートのサービスがすでに保存した情報を撤回することもできない。プログラムはアカウント識別子、保存された場所、デバイス名、以前に得た別の値を送ることがあり、暗号化はそのペイロードを転送中に保護するが、中身を何も取り除かない。再接続はネットワークの出来事であり、保持された値はアプリの出来事だ。
この区別が重要なのは、両者が別の場所に住んでいるからだ。アプリの状態はプログラムに属し、再起動を生き延びる、一方ルートはオペレーティングシステムに属し、接続のたびに作り直される。片方を消しても、もう片方には影響しない。
サービスは何か月も前に渡した値を保持していることもあり、その場合どんなローカルの変更でも消えない。それは保持であり、トンネルの完全に外側にある。
まず送信元ヘッダーを、次にペイロードを読む
まずアドレスがどこに現れたかを特定する。サーバーの接続ログは実際の送信元を記述し、メッセージのフィールド、アカウントのプロフィール、ローカルの診断表示は、ずっと前に送信または保存された値を記述できる。これらの観察は別々の問いに答えている。
時刻も比べよう。古いアドレスがVPN接続より前のフィールドに現れるなら、ペイロードの説明のほうが強い。トンネルが有効な間にサーバーが古いアドレスからの直接接続を記録するなら、それはルーティングの問題であり、別の調査が必要だ。観察の種類を先に整理すれば、ひとつのアドレスが三つの出来事の証明に引き伸ばされるのを防げる。
メモでは別々に保とう——接続元、メッセージのフィールド、アカウント表示、ローカル診断。四か所に書かれたひとつのアドレスは、やはりひとつのアドレスだ。
保持は転送とは別の段階
RFC 6973 のプライバシー指針は、収集・利用・開示・保持を別々の段階として扱い、再利用された識別子が相関を容易にすると警告している。新しいネットワーク経路は転送の段階を変えるだけで、それ以外は何も変えない。受信者がすでに持つ記録は影響を受けず、入り口で値を保存したプロフィールも同じだ。だから転送が正しく動いていても、再接続は失敗したように感じられる。
どんなパケットフィルターも受信者の記録から値を削除できず、再接続しても各プログラムの保存履歴は消えない。これらはトンネルではなくデータ所有者の問題であり、別の種類の解決策が要る。ネットワークに隠すよう頼む前に、サービスが何をどれだけ保持するかを聞こう。
トンネルを責める前に確認すること
アプリの文書化された収集とアカウント管理を確認し、どのフィールドを送信してよいか、サービスがそれをどれだけ保持するか、アカウントが消去や訂正できるかを決める。次に説明を切り分けるテストを行う——新しいアカウントか、きれいなアプリプロフィールだ。古い値が消えれば、保持かキャッシュ状態が関与していた。きれいなプロフィールでも残るなら、VPNが失敗したと結論づける前に実際のリクエストフィールドを調べよう。
直接接続が本当に存在するなら、ネットワーク経路の所見として扱う。ルーティング、分割トンネル、クライアントポリシーをそれぞれの条件で調べ、その結果を、単に再接続を生き延びたペイロード値と混ぜないこと。二つの不具合はスクリーンショットでは同じに見え、キャプチャではまったく違う振る舞いをする。