VPN-forbindelsesgrænser: Aktuel tilstand kontra en gemt historik

Tre samtidige forbindelser er en optagelsesbeslutning, og for at besvare den skal tjenesten vide, hvilke pladser der er optaget lige nu, og ikke hvad der skete sidste måned. En tjeneste kan afvise en fjerde session ud fra en lille tabel med aktive poster og aldrig opbygge en tidslinje. Det siger noget om mekanismen, ikke om operatøren, og forskellen betyder noget, når du læser en privatlivspolitik. Modellen nedenfor viser, hvad beslutningen behøver, og hvad den kan kassere.

Mekanismen: en pladstabel, ikke en log

Den enkleste implementering knytter et abonnement til op til tre aktive sessionsposter. Hver session, der lukkes ind, optager en plads, og pladsen frigives, når tjenesten beslutter, at sessionen er slut. Posten skal have en identitet, der er specifik nok til, at frigivelsen af én forbindelse ikke frigiver en anden forbindelses plads, og derfor betyder sessionsidentifikatoren mere end kontonavnet.

Optagethed og historik er forskellige datastrukturer. Optagethed besvarer et ja-eller-nej-spørgsmål om nutiden og kan kasseres i samme øjeblik, sessionen slutter. En historik er en strøm af begivenheder, der kun tilføjes, og den består, fordi nogen valgte at beholde den. En tjeneste kan have ingen, begge eller kun den ene.

Forskellen er usynlig udefra. En synlig forbindelsesgrænse er forenelig med en bittelille tæller i hukommelsen, en delt databasetabel og et fuldt begivenhedsarkiv med et dashboard. Intet ved grænsen fortæller dig, hvilken af dem der kører.

Hvorfor den levende model stadig kræver koordination

En tabt forbindelse bliver måske ikke straks genkendt som afsluttet. Gatewayen venter på en timeout, en keepalive-fejl eller en afslutning af regnskabsføringen, og indtil en af disse indtræffer, forbliver pladsen optaget. En bruger, der genopretter forbindelse i det vindue, møder en afvisning, som intet har med en fjerde enhed at gøre.

En genstartet server skal afstemme sin tilstand, og flere gateways, der betjener den samme konto, har brug for en fælles beslutning. Ellers kan en konto overskride sin kvote ved at forbinde til forskellige placeringer. Delt eller gendannelig tilstand løser det, og delt tilstand er et designkrav snarere end et bevis på overvågning.

Intet af den koordination kræver browserhistorik. En gateway, der videresender pakker, behøver ikke at vide, hvilke websteder en session besøgte, for at tælle sessioner, og de to dataflow håndteres normalt af helt forskellige komponenter.

At holde en tælling i hukommelsen gør heller ikke de tilknyttede fakta anonyme. Mens tjenesten kører, afslører en abonnementsknyttet post, at en konto har aktive forbindelser, og både adgangen til den tilstand og dens levetid er værd at spørge om.

Hvor tilstanden ender bagefter

Privatlivsspørgsmålet er ikke, om serveren kan tælle. Spørg, hvad der sker med en afsluttet session: fjernes posten, eller bliver den en begivenhed i en overvågningsserie? Spørg derefter, hvilke andre komponenter der så den samme begivenhed, fordi autentificeringslogfiler, regnskabsposter og sikkerhedskopier hver kan gemme en kopi, som håndhævelsesvejen kasserede.

RADIUS-regnskab er det klareste eksempel. Et Start- og Stop-par findes for at understøtte fakturering og sessionsstyring, og det skaber en post om forbindelsen, uanset om nogen nogensinde forespørger den som en historik. En tjeneste, der håndhæver grænser via regnskab, bevarer derfor per konstruktion mere end en pladstabel.

Sletning har også en form. En post, der fjernes fra den levende tabel, kan bestå i en sikkerhedskopi taget en time tidligere, og opbevaringsperioden for den sikkerhedskopi er sin egen politik-erklæring. At læse kun det primære lager giver et ufuldstændigt svar.

Stil spørgsmålet i form af felter

RFC 6973's vejledning om dataminimering knytter de data, der indsamles og gemmes, til det formål, der tjener. Anvendt her er det nyttige spørgsmål, hvilke felter opgaven med samtidig optagelse faktisk har brug for, og hvilket formål der retfærdiggør at beholde hvert enkelt, efter at opgaven er slut.

En præcis tjenestebeskrivelse adskiller levende forbindelsestilstand, som bruges til at håndhæve kvoten, fra eventuelle poster, der bevares efter afslutningen, og den navngiver de andre systemer inden for løftets rækkevidde. En sætning, der kun siger, at tre forbindelser håndhæves, fastslår hverken at der findes et arkiv, eller at der ikke gør.

Når livscyklussen er uklar, skal du registrere det som et ubesvaret opbevaringsspørgsmål snarere end en dom. Tilstedeværelsen af en grænse er ikke bevis på en skjult historik, og en plausibel forklaring om levende tilstand er ikke en revision af udbyderen.