VPN-tilkoblingsgrenser: sanntidstilstand kontra lagret historikk
En grense på tre tilkoblinger trenger sanntids slottilstand, ikke nettleserhistorikk: hva mekanismen må lagre, hva den kan forkaste, og hvor den tilstanden går videre.
Tre samtidige tilkoblinger er en opptaksbeslutning, og for å svare på den må man vite hvilke slott som er opptatt akkurat nå, ikke hva som skjedde i forrige måned. En tjeneste kan avslå en fjerde økt fra en liten tabell med aktive poster og aldri bygge en tidslinje. Det er en påstand om mekanismen, ikke om operatøren, og forskjellen betyr noe når du leser en personvernerklæring. Modellen nedenfor viser hva beslutningen trenger og hva den kan forkaste.
Mekanismen: en slotttabell, ikke en logg
Den enkleste implementasjonen knytter et abonnement til opptil tre aktive øktposter. Hver økt som slippes inn tar ett slott, og slottet frigjøres når tjenesten avgjør at økten er avsluttet. Posten trenger en identitet som er spesifikk nok til at frigjøring av én tilkobling ikke frigjør en annen tilkoblings slott; derfor er øktidentifikatoren viktigere enn kontonavnet.
Opptatthet og historikk er forskjellige datastrukturer. Opptatthet svarer på et ja-eller-nei-spørsmål om nåtiden, og kan forkastes i det øyeblikket økten avsluttes. En historikk er en strøm av hendelser som bare legges til, og den overlever fordi noen valgte å beholde den. En tjeneste kan ha én, begge eller ingen.
Forskjellen er usynlig utenfra. En synlig tilkoblingsgrense er forenlig med en bitteliten teller i minnet, en delt databasetabell og et fullstendig hendelsesarkiv med dashbord. Ingenting ved grensen forteller deg hvilken av dem som kjører.
| 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 |
Hvorfor den levende modellen fortsatt trenger koordinering
En tapt tilkobling blir kanskje ikke umiddelbart gjenkjent som avsluttet. Gatewayen venter på en timeout, en keepalive-feil eller en regnskapsstopp, og til en av dem kommer, forblir slottet opptatt. En bruker som kobler til på nytt i det vinduet, ser en avvisning som ikke har noe med en fjerde enhet å gjøre.
En omstartet server må avstemme tilstanden sin, og flere gatewayer som betjener samme konto trenger en felles beslutning. Ellers kan en konto overskride kvoten ved å koble til forskjellige steder. Delt eller gjenopprettbar tilstand løser det, og delt tilstand er et designkrav, ikke et bevis på overvåking.
Ingenting av den koordineringen krever nettleserhistorikk. En gateway som videresender pakker, trenger ikke å vite hvilke nettsteder en økt besøkte for å telle økter, og de to dataflytene håndteres vanligvis av helt forskjellige komponenter.
Å holde en teller i minnet gjør heller ikke de tilknyttede fakta anonyme. Mens tjenesten kjører, avslører en abonnementsknyttet post at en konto har aktive tilkoblinger, og både tilgangen til den tilstanden og levetiden dens er verdt å spørre om.
Hvor tilstanden går videre
Personvernspørsmålet er ikke om serveren kan telle. Spør hva som skjer med en avsluttet økt: fjernes posten, eller blir den en hendelse i en overvåkingsserie? Spør deretter hvilke andre komponenter som så den samme hendelsen, fordi autentiseringslogger, regnskapsposter og sikkerhetskopier hver kan beholde en kopi som håndhevingsveien forkastet.
RADIUS-regnskap er det tydeligste eksempelet. Et Start- og Stop-par finnes for å støtte fakturering og øktkontroll, og det lager en post om tilkoblingen uavhengig av om noen noen gang spør etter den som historikk. En tjeneste som håndhever grenser gjennom regnskap, beholder derfor ved konstruksjon mer enn en slotttabell.
Sletting har også en form. En post som fjernes fra den levende tabellen, kan bestå i en sikkerhetskopi tatt en time tidligere, og oppbevaringsperioden for den kopien er sin egen policerklæring. Å lese bare primærlageret gir et ufullstendig svar.
Still spørsmålet i form av felt
RFC 6973s veiledning om dataminimering knytter dataene som samles inn og lagres, til formålet som betjenes. Anvendt her er det nyttige spørsmålet hvilke felt oppgaven med samtidig opptak faktisk trenger, og hvilket formål som rettferdiggjør å beholde hvert enkelt etter at oppgaven er avsluttet.
En presis tjenestebeskrivelse skiller den levende tilkoblingstilstanden som brukes til å håndheve kvoten, fra alle poster som beholdes etter avslutning, og den navngir de andre systemene innenfor løftets omfang. En setning som bare sier at tre tilkoblinger håndheves, fastslår verken at et arkiv finnes eller at det ikke gjør det.
Når livssyklusen er uklar, registrer det som et ubesvart oppbevaringsspørsmål i stedet for en dom. Tilstedeværelsen av en grense er ikke bevis på en skjult historikk, og en plausibel forklaring på levende tilstand er ikke en revisjon av tilbyderen.