VPN接続の上限:ライブ状態か、保持された履歴か
三接続の上限にはブラウザ履歴ではなくライブのスロット状態が必要です。仕組みが保存すべきもの、破棄できるもの、そしてその状態がその後どこへ行くのかを説明します。
三つの同時接続は受け入れの判断であり、それに答えるには先月何があったかではなく、今どのスロットが埋まっているかを知る必要があります。サービスはアクティブなレコードの小さな表から四つ目のセッションを拒否でき、タイムラインを一切作らないこともあります。これは仕組みについての話であり事業者についての話ではなく、プライバシーポリシーを読むときにはこの違いが重要です。以下のモデルは、判断に何が必要で、何を破棄できるかを示します。
仕組み:スロット表であり、ログではない
最も単純な実装は、サブスクリプションを最大三つのアクティブなセッションレコードに関連付けます。受け入れられたセッションはそれぞれ一つのスロットを取り、サービスがそのセッションを終了したと判断した時点でスロットは解放されます。レコードには、一つの接続を解放しても別の接続のスロットが解放されないだけの固有の識別子が必要であり、そのためアカウント名よりもセッション識別子のほうが重要になります。
占有状況と履歴は別のデータ構造です。占有状況は現在についての「はい/いいえ」の問いに答え、セッションが終了した瞬間に破棄できます。履歴は追加のみのイベントの流れであり、誰かが残すことを選んだから存続します。サービスはどちらか一方、両方、あるいはどちらも持たないことがあります。
その区別は外からは見えません。目に見える接続上限は、メモリ内の小さなカウンター、共有データベースの表、ダッシュボード付きの完全なイベントアーカイブのいずれとも両立します。上限そのものからは、どれが動いているのか分かりません。
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
ライブモデルに依然として調整が必要な理由
失われた接続は、すぐには終了したと認識されないことがあります。ゲートウェイはタイムアウト、keepaliveの失敗、または会計の停止を待ち、そのどれかが届くまでスロットは占有されたままです。その間に再接続した利用者は、四台目の端末とは無関係な拒否を受けます。
再起動したサーバーは自分の状態を整合させる必要があり、同じアカウントを扱う複数のゲートウェイには共通の判断が要ります。そうでなければ、アカウントは異なる拠点に接続することで割当を超えられます。共有または復元可能な状態がそれを解決し、共有状態は設計上の要件であって監視の証拠ではありません。
その調整のどこにもブラウザ履歴は必要ありません。パケットを転送するゲートウェイは、セッションを数えるためにどのサイトを訪れたかを知る必要はなく、この二つのデータの流れは通常まったく別のコンポーネントが扱います。
カウントをメモリに保っても、関連する事実が匿名になるわけではありません。サービスの稼働中、サブスクリプションに紐づくレコードは、あるアカウントにアクティブな接続があることを明らかにし、その状態へのアクセスと存続期間の両方を問う価値があります。
その状態がその後どこへ行くか
プライバシーの問いは、サーバーが数えられるかどうかではなく、終了したセッションがどうなるかです。レコードは削除されるのか、それとも監視系列のイベントになるのか、そして同じイベントをどの他のコンポーネントが見たのかを尋ねてください。認証ログ、会計記録、バックアップはそれぞれ、執行経路が破棄したコピーを保持している可能性があります。
RADIUS会計が最も明快な例です。StartとStopの組は課金とセッション制御を支えるために存在し、誰かがそれを履歴として問い合わせるかどうかに関係なく、接続のレコードを作ります。したがって、会計を通じて上限を執行するサービスは、構造上スロット表以上のものを保持します。
削除にも形があります。ライブの表から削除されたレコードは、一時間前に取られたバックアップの中に残ることがあり、そのバックアップの保持期間はそれ自体がポリシーの表明です。一次ストアだけを読むと不完全な答えになります。
問いをフィールドの言葉で立てる
RFC 6973のデータ最小化の指針 は、収集・保存されるデータを提供する目的に結びつけます。ここに当てはめると、有用な問いは、同時受け入れの作業が実際に必要とするフィールドはどれか、その作業が終わった後に各フィールドを保持することを正当化する目的は何か、ということです。
正確なサービス記述は、割当を執行するために使うライブの接続状態を、終了後に保持されるあらゆるレコードから切り離し、約束の範囲内にある他のシステムを名指しします。三つの接続を執行しているとだけ述べる文は、アーカイブが存在することも、存在しないことも証明しません。
ライフサイクルが不明確なときは、判定ではなく未回答の保持の問いとして記録してください。上限の存在は隠れた履歴の証拠ではなく、ライブ状態のもっともらしい説明は事業者への監査ではありません。