VPN-tilkoblingsgrenser: direktetilstand mot en lagret historikk
En grense på tre tilkoblinger krever direkte slottilstand, ikke nettleserhistorikk: hva mekanismen må lagre, hva den kan kaste, og hvor denne tilstanden går hen etterpå.
Tre samtidige tilkoblinger er en innlemmelsesbeslutning, og for å besvare den trenger man å vite hvilke slott som er opptatt akkurat nå, ikke hva som hendte forrige måned. En tjeneste kan nekte en fjerde sesjon ut fra en liten tabell over aktive oppføringer og aldri bygge en tidslinje. Det er en uttalelse om mekanismen, ikke om operatøren, og forskjellen er viktig når man leser en personvernpolicy. Modellen nedenfor viser hva beslutningen trenger og hva den kan kaste.
Mekanismen: en slotttabell, ikke en logg
Den enkleste utførelsen knytter et abonnement til opptil tre aktive sesjonsoppføringer. Hver innlatte sesjon tar ett slott, og slottet frigis når tjenesten bestemmer at sesjonen er over. Oppføringen trenger en identitet som er såpass spesifikk at frigivelse av én tilkobling ikke frigir slottet til en annen tilkobling; derfor betyr sesjonsidentifikatoren mer enn kontonavnet.
Belegget og historikken er forskjellige datastrukturer. Belegget besvarer et ja-eller-nei-spørsmål om nåtiden, og det kan kastes i samme øyeblikk som sesjonen avsluttes. En historikk er en strøm av hendelser som bare legges til, og den består fordi noen valgte å beholde den. En tjeneste kan ha én, begge eller ingen.
Forskjellen er usynlig utenfra. En synlig tilkoblingsgrense er forenlig med en liten teller i minnet, en felles databasetabell og et komplett hendelsesarkiv med dashbord. Ingenting ved grensen sier 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 likevel trenger samordning
En mistet tilkobling blir kanskje ikke straks gjenkjent som avsluttet. Gatewayen venter på en tidsavbrudd, en keepalive-feil eller en regnskapsstopp, og inntil en av dem kommer, holder slottet seg opptatt. En bruker som kobler til igjen i det vinduet, får 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 avgjørelse. Ellers kan en konto overskride kvoten sin ved å koble til forskjellige steder. Delt eller gjenopprettbar tilstand løser det, og delt tilstand er et designkrav, ikke et bevis på overvåking.
Ingen del av den samordningen krever nettleserhistorikk. En gateway som videresender pakker, trenger ikke å vite hvilke nettsteder en sesjon besøkte for å telle sesjoner, og de to dataflytene håndteres vanligvis av helt forskjellige komponenter.
Å holde en teller i minnet gjør heller ikke de tilknyttede fakta anonyme. Så lenge tjenesten kjører, avdekker en abonnementsknyttet oppføring at en konto har aktive tilkoblinger, og både tilgangen til denne tilstanden og levetiden er verdt å spørre om.
Hvor tilstanden går hen etterpå
Personvernspørsmålet er ikke om serveren kan telle. Spør hva som skjer med en avsluttet sesjon: blir oppføringen fjernet, eller blir den en hendelse i en overvåkingsserie? Spør deretter hvilke andre komponenter som så den samme hendelsen, fordi autentiseringslogger, regnskapsoppføringer og sikkerhetskopier kan hver beholde en kopi som håndhevingsveien kastet.
RADIUS-regnskap er det klareste eksempelet. Et Start- og Stop-par finnes for å støtte fakturering og sesjonskontroll, og det lager en oppføring om tilkoblingen uansett om noen noen gang spør etter den som historikk. En tjeneste som håndhever grenser gjennom regnskap, beholder derfor ved sin oppbygning mer enn en slotttabell.
Sletting har også en form. En oppføring som fjernes fra den levende tabellen, kan bestå i en sikkerhetskopi tatt en time tidligere, og oppbevaringsperioden for den kopien er en egen policyerklæring. Å lese bare primærlageret gir et ufullstendig svar.
Still spørsmålet som felt
RFC 6973s råd 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 innlemmelse faktisk trenger, og hvilket formål som rettferdiggjør å beholde hvert enkelt etter at oppgaven er over.
En presis tjenestebeskrivelse skiller den levende tilkoblingstilstanden som brukes til å håndheve kvoten, fra oppføringer som beholdes etter avslutning, og den navngir de andre systemene innenfor løftets rekkevidde. En setning som bare sier at tre tilkoblinger håndheves, fastslår verken at et arkiv finnes eller at det ikke finnes.
Når livssyklusen er uklar, registrer det som et ubesvart oppbevaringsspørsmål i stedet for en dom. At en grense finnes er ikke bevis på en skjult historikk, og en sannsynlig forklaring på levende tilstand er ikke en revisjon av tilbyderen.