VPN-Verbindungslimits: aktueller Zustand gegen gespeicherten Verlauf
Ein Limit von drei Verbindungen braucht den aktuellen Zustand der Plätze, keinen Browserverlauf: was der Mechanismus speichern muss, was er verwerfen kann und wohin dieser Zustand danach wandert.
Drei gleichzeitige Verbindungen sind eine Zulassungsentscheidung, und um sie zu beantworten, muss der Dienst wissen, welche Plätze gerade belegt sind, und nicht, was im letzten Monat passiert ist. Ein Dienst kann eine vierte Sitzung anhand einer kleinen Tabelle aktiver Datensätze ablehnen und dabei nie eine Zeitleiste aufbauen. Das ist eine Aussage über den Mechanismus, nicht über den Betreiber, und der Unterschied zählt, wenn man eine Datenschutzerklärung liest. Das folgende Modell zeigt, was die Entscheidung braucht und was sie verwerfen kann.
Der Mechanismus: eine Platztabelle, kein Protokoll
Die einfachste Umsetzung verknüpft ein Abonnement mit bis zu drei aktiven Sitzungsdatensätzen. Jede zugelassene Sitzung belegt einen Platz, und der Platz wird freigegeben, sobald der Dienst entscheidet, dass die Sitzung beendet ist. Der Datensatz braucht eine so spezifische Identität, dass die Freigabe einer Verbindung nicht den Platz einer anderen Verbindung freigibt; deshalb ist die Sitzungskennung wichtiger als der Kontoname.
Belegung und Verlauf sind verschiedene Datenstrukturen. Die Belegung beantwortet eine Ja-oder-Nein-Frage über die Gegenwart und kann in dem Moment verworfen werden, in dem die Sitzung endet. Ein Verlauf ist ein nur anfügbarer Strom von Ereignissen, und er überlebt, weil jemand sich entschieden hat, ihn zu behalten. Ein Dienst kann beides, eines von beidem oder keines haben.
Der Unterschied ist von außen unsichtbar. Ein sichtbares Verbindungslimit verträgt sich mit einem winzigen Zähler im Arbeitsspeicher, einer gemeinsamen Datenbanktabelle und einem vollständigen Ereignisarchiv mit Dashboard. Nichts an dem Limit verrät, welche dieser Varianten läuft.
| 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 |
Warum das Modell des laufenden Zustands trotzdem Koordination braucht
Eine verlorene Verbindung wird möglicherweise nicht sofort als beendet erkannt. Das Gateway wartet auf einen Timeout, einen Keepalive-Fehler oder einen Accounting-Stop, und bis eines davon eintrifft, bleibt der Platz belegt. Ein Nutzer, der sich in diesem Fenster erneut verbindet, erhält eine Ablehnung, die nichts mit einem vierten Gerät zu tun hat.
Ein neu gestarteter Server muss seinen Zustand abgleichen, und mehrere Gateways, die dasselbe Konto bedienen, brauchen eine gemeinsame Entscheidung. Sonst kann ein Konto sein Kontingent überschreiten, indem es sich mit verschiedenen Standorten verbindet. Gemeinsamer oder wiederherstellbarer Zustand löst das, und gemeinsamer Zustand ist eine Designanforderung und kein Beweis für Überwachung.
Nichts an dieser Koordination verlangt Browserverläufe. Ein Gateway, das Pakete weiterleitet, muss nicht wissen, welche Websites eine Sitzung besucht hat, um Sitzungen zu zählen, und die beiden Datenströme werden üblicherweise von völlig verschiedenen Komponenten verarbeitet.
Einen Zähler im Arbeitsspeicher zu halten macht die zugehörigen Fakten auch nicht anonym. Solange der Dienst läuft, verrät ein abonnementgebundener Datensatz, dass ein Konto aktive Verbindungen hat, und sowohl der Zugriff auf diesen Zustand als auch seine Lebensdauer sind es wert, erfragt zu werden.
Wohin der Zustand danach wandert
Die Datenschutzfrage ist nicht, ob der Server zählen kann. Fragen Sie, was mit einer beendeten Sitzung geschieht: Wird der Datensatz entfernt, oder wird er zu einem Ereignis in einer Überwachungsreihe? Fragen Sie dann, welche anderen Komponenten dasselbe Ereignis gesehen haben, denn Authentifizierungsprotokolle, Abrechnungsdatensätze und Sicherungen können jeweils eine Kopie behalten, die der Durchsetzungspfad verworfen hat.
RADIUS-Accounting ist das klarste Beispiel. Ein Paar aus Start und Stop existiert, um Abrechnung und Sitzungssteuerung zu unterstützen, und es erzeugt einen Datensatz der Verbindung, unabhängig davon, ob ihn jemals jemand als Verlauf abfragt. Ein Dienst, der Limits über Accounting durchsetzt, behält daher konstruktionsbedingt mehr als eine Platztabelle.
Auch das Löschen hat eine Form. Ein aus der aktiven Tabelle entfernter Datensatz kann in einer eine Stunde zuvor erstellten Sicherung fortbestehen, und die Aufbewahrungsfrist dieser Sicherung ist ihre eigene politische Aussage. Nur den primären Speicher zu lesen, ergibt eine unvollständige Antwort.
Fragen Sie in Feldern
Die Datensparsamkeitsleitlinie von RFC 6973 verbindet die erhobenen und gespeicherten Daten mit dem Zweck, dem sie dienen. Auf diesen Fall angewandt lautet die nützliche Frage, welche Felder die Aufgabe der gleichzeitigen Zulassung tatsächlich braucht und welcher Zweck es rechtfertigt, jedes einzelne nach dem Ende dieser Aufgabe zu behalten.
Eine präzise Dienstbeschreibung trennt den laufenden Verbindungszustand, der zur Durchsetzung des Kontingents dient, von allen nach der Beendigung aufbewahrten Datensätzen und benennt die anderen Systeme im Geltungsbereich des Versprechens. Ein Satz, der nur sagt, dass drei Verbindungen durchgesetzt werden, belegt weder, dass ein Archiv existiert, noch dass keines existiert.
Wenn der Lebenszyklus unklar ist, halten Sie das als offene Aufbewahrungsfrage fest statt als Urteil. Das Vorhandensein eines Limits ist kein Beweis für einen verborgenen Verlauf, und eine plausible Erklärung des laufenden Zustands ist keine Prüfung des Anbieters.