帯域カウンターはVPNでの閲覧内容を教えてくれるのか

ルーターの通信ページやVPN事業者のダッシュボードを開くと、端末ごとのバイト合計とその横にグラフがある。そのグラフを閲覧履歴として読んでしまいたくなる。しかしそれは履歴ではない。理由は法的なものではなく構造的なものだ。カウンターはサイズを足し合わせるが、履歴は宛先と内容を記録する。どちらが「誰がどこへ行ったか」を語るかは明らかである。

目の前の画面から始める

数字を解釈する前に、その数字が何から生まれたのかを確かめる。ルーターの端末別合計は通常は物理インターフェースのカウンター、VPNクライアントの合計はそのトンネル、事業者のパネルは遠端の会計処理に由来する。どれも同じセッションの別の部分を数えている。同じ一時間について異なる数字を示す二つのパネルは、たいてい両方とも正しい。

間隔は情報源と同じくらい重要だ。通算の合計、日次の集計、瞬間の速度は三つの異なる測定であり、一つの操作と突き合わせるだけの分解能を持つのは瞬間の速度だけである。

結論を書く前に、情報源と間隔を書き留める。

カウンターが測るのは層であり、ページではない

WireGuardのピアでは、wg show の転送カウンターはそのピアの合計で、暗号化されたペイロードも含む。OpenVPNの状態出力は独自の層でクライアントごとのバイトを報告する。ホスト側では tun インターフェースが内側の IP パケットを数え、物理アダプターが外側の UDP パケットを数えるため、両者はカプセル化のオーバーヘッドと回線を共有する他のすべての分だけ異なる。

再送は新しい内容が届かないまま合計を膨らませ、バックグラウンドの同期が一時間を占めることもある。その間ユーザーは普通のテキストを読んでいるだけかもしれない。

だから大きな合計が示すのはデータを多く使う活動であり、それ以上に具体的なことではない。ダウンロードしたファイルのサイズとカウンターの差分は関係しているが、めったに一致しない。

合計が支えられること、支えられないこと

バイトの合計はサイト名を挙げられない。名前や URL はカウンターが決して覗かない TLS や QUIC のセッションの内側にあるからだ。動画配信と大きなバックアップ、ページの読み込みと広告の更新ループを区別することもできない。支えられるのは容量と時間についての主張だ。この端末はこの時間帯にこれだけのデータを動かした、ということである。

それを人についての主張に変えるには、あと二つの材料が要る。識別子と照合である。

RFC 6973 のプライバシーに関する考慮事項は、その組み合わせがなぜ重要かを説明している。慎重な報告が観測したことと推論したことを分けるのも同じ理由だ。結論に「なぜなら」という言葉が必要なら、カウンターだけでは証拠として足りない。

時刻と識別子が答えを変える

カウンターを名前のあるユーザーと正確な間隔に結びつけると、それは別の対象になる。

そうすれば他の観測と突き合わせられる。ログイン記録、DNS 問い合わせ、別システム上のセッションなどだ。カウンターは宛先を明かしていないが、すでに仮説を持っていた人がそれを確かめる助けにはなった。暗号化は転送中の内容と名前を守るが、流れが存在したこと、その大きさ、始まった時刻を隠しはしない。

これが正直な境界だ。パターンは見えるが、意味は見えない。

集める前に、何を保持するかを決める

要件が容量計画なら、粗い日次集計で答えが出てコストも小さい。要件がユーザーごとの履歴なら、それを明示し、項目と保持期間を名指しし、判断をダッシュボードの機能ではなく方針として扱う。パネルが対応しているからと細かい履歴を集めることが、誰も決めないまま保持が増えていく経路である。

トラブルシューティングでは、カウンターを試している操作と比べる。右肩上がりの合計が証明するのは通信が流れていることであり、アプリが動いていることではない。

明らかに動いているセッションでカウンターが平らなら、たいていはキャッシュされた値か間違ったインターフェースを読んでいる。保持する項目と期間を名指しすれば、次の監査には具体的に確認できるものがある。