VPN-verbindingslimieten: live status versus bewaarde geschiedenis

Drie gelijktijdige verbindingen is een toelatingsbeslissing, en om die te beantwoorden moet je weten welke slots nu bezet zijn, niet wat vorige maand is gebeurd. Een dienst kan een vierde sessie weigeren op basis van een kleine tabel met actieve records en nooit een tijdlijn opbouwen. Dat is een uitspraak over het mechanisme, niet over de operator, en het verschil doet ertoe wanneer je een privacybeleid leest. Het model hieronder laat zien wat de beslissing nodig heeft en wat ze kan weggooien.

Het mechanisme: een slottabel, geen logboek

De eenvoudigste implementatie koppelt een abonnement aan maximaal drie actieve sessierecords. Elke toegelaten sessie neemt één slot in, en het slot wordt vrijgegeven wanneer de dienst beslist dat die sessie is afgelopen. Het record heeft een identiteit nodig die specifiek genoeg is dat het vrijgeven van de ene verbinding niet het slot van een andere verbinding vrijgeeft; daarom is de sessie-identificatie belangrijker dan de accountnaam.

Bezetting en geschiedenis zijn verschillende datastructuren. Bezetting beantwoordt een ja-of-nee-vraag over het heden, en kan worden weggegooid op het moment dat de sessie eindigt. Een geschiedenis is een alleen-toevoegbare stroom gebeurtenissen, en die blijft bestaan omdat iemand ervoor koos hem te bewaren. Een dienst kan het een, beide of geen van beide hebben.

Het onderscheid is van buitenaf onzichtbaar. Een zichtbare verbindingslimiet is verenigbaar met een piepkleine teller in het geheugen, een gedeelde databasetabel en een volledig gebeurtenisarchief met een dashboard. Niets aan de limiet vertelt je welke daarvan draait.

Waarom het live-model toch coördinatie nodig heeft

Een verloren verbinding wordt misschien niet meteen als beëindigd herkend. De gateway wacht op een time-out, een keepalive-fout of een accounting-stop, en tot een van die arriveert blijft het slot bezet. Een gebruiker die in dat venster opnieuw verbindt, ziet een weigering die niets met een vierde apparaat te maken heeft.

Een herstarte server moet zijn status afstemmen, en meerdere gateways die hetzelfde account bedienen hebben een gezamenlijke beslissing nodig. Anders kan een account zijn quotum overschrijden door verbinding te maken met verschillende locaties. Gedeelde of herstelbare status lost dat op, en gedeelde status is een ontwerpvereiste, geen bewijs van surveillance.

Niets aan die coördinatie vereist browsergeschiedenissen. Een gateway die pakketten doorstuurt, hoeft niet te weten welke sites een sessie bezocht om sessies te tellen, en de twee datastromen worden meestal door volledig verschillende componenten afgehandeld.

Een teller in het geheugen houden maakt de bijbehorende feiten ook niet anoniem. Zolang de dienst draait, onthult een aan het abonnement gekoppeld record dat een account actieve verbindingen heeft, en zowel de toegang tot die status als de levensduur ervan is het vragen waard.

Waar die status daarna naartoe gaat

De privacyvraag is niet of de server kan tellen. Vraag wat er met een beëindigde sessie gebeurt: wordt het record verwijderd, of wordt het een gebeurtenis in een monitoringsreeks? Vraag dan welke andere componenten dezelfde gebeurtenis zagen, want authenticatielogs, accountingrecords en back-ups kunnen elk een kopie bewaren die het handhavingspad weggooide.

RADIUS-accounting is het duidelijkste voorbeeld. Een Start- en Stop-paar bestaat om facturering en sessiebeheer te ondersteunen, en het creëert een record van de verbinding ongeacht of iemand het ooit als geschiedenis opvraagt. Een dienst die limieten via accounting handhaaft, bewaart daardoor door zijn opbouw meer dan een slottabel.

Verwijderen heeft ook een vorm. Een record dat uit de live-tabel is verwijderd, kan voortbestaan in een back-up van een uur eerder, en de bewaartermijn van die back-up is een eigen beleidsverklaring. Alleen de primaire opslag lezen geeft een onvolledig antwoord.

Stel de vraag in termen van velden

De dataminimalisatierichtlijn van RFC 6973 verbindt de verzamelde en opgeslagen gegevens met het doel dat wordt gediend. Hier toegepast is de nuttige vraag welke velden de taak van gelijktijdige toelating werkelijk nodig heeft, en welk doel rechtvaardigt elk daarvan te bewaren nadat die taak is afgelopen.

Een precieze dienstverklaring scheidt de live verbindingsstatus die wordt gebruikt om het quotum te handhaven van alle records die na beëindiging worden bewaard, en ze noemt de andere systemen binnen de reikwijdte van de belofte. Een zin die alleen zegt dat drie verbindingen worden gehandhaafd, stelt niet vast dat er een archief bestaat en ook niet dat er geen bestaat.

Wanneer de levenscyclus onduidelijk is, leg het vast als een onbeantwoorde bewaarvraag in plaats van een vonnis. De aanwezigheid van een limiet is geen bewijs van een verborgen geschiedenis, en een plausibele verklaring van live-status is geen audit van de aanbieder.