VPN-verbindingslimiete: lewende toestand teenoor 'n bewaarde geskiedenis
Drie gelyktydige verbindings vereis lewende gleuftoestand, nie 'n blaaisgeskiedenis nie: wat die meganisme moet stoor, wat dit kan weggooi, en waar daardie toestand heen gaan.
Drie gelyktydige verbindings is 'n toelatingsbesluit, en om dit te beantwoord moet jy weet watter gleuwe nou beset is eerder as wat verlede maand gebeur het. 'n Diens kan 'n vierde sessie uit 'n klein tabel aktiewe rekords weier en glad geen tydlyn bou nie. Dit is 'n stelling oor die meganisme, nie oor die operateur nie, en die verskil maak saak wanneer jy 'n privaatheidsbeleid lees. Die model hieronder wys wat die besluit nodig het en wat dit kan weggooi.
Die meganisme: 'n gleuftabel, nie 'n logboek nie
Die eenvoudigste implementering koppel 'n subskripsie aan tot drie aktiewe sessierekords. Elke toegelate sessie neem een gleuf, en die gleuf word vrygestel wanneer die diens besluit die sessie het geëindig. Die rekord het 'n identiteit nodig wat spesifiek genoeg is sodat die vrystelling van een verbinding nie 'n ander verbinding se gleuf vrymaak nie; daarom maak die sessie-identifiseerder meer saak as die rekeningnaam.
Besetting en geskiedenis is verskillende datastrukture. Besetting beantwoord 'n ja-of-nee-vraag oor die hede, en dit kan weggegooi word sodra die sessie eindig. 'n Geskiedenis is 'n slegs-byvoeg-stroom van gebeure, en dit bly voortbestaan omdat iemand gekies het om dit te hou. 'n Diens kan enigeen, albei of nie een van die twee hê nie.
Die onderskeid is van buite onsigbaar. 'n Sigbare verbindingslimiet is versoenbaar met 'n klein geheuetoestandteller, 'n gedeelde databasis-tabel en 'n volledige gebeurtenisargief met 'n paneelbord. Niks omtrent die limiet vertel jou watter een daarvan loop nie.
| 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 |
Waarom die lewende model steeds koördinering nodig het
'n Verlore verbinding word dalk nie dadelik as geëindig herken nie. Die poort wag vir 'n tydsverloop, 'n keepalive-fout of 'n boekhoudingstop, en totdat een van dié opdaag, bly die gleuf beset. 'n Gebruiker wat gedurende daardie venster weer aansluit, sien 'n weiering wat niks met 'n vierde toestel te doen het nie.
'n Herbegin bediener moet sy toestand versoen, en verskeie poorte wat dieselfde rekening bedien, het 'n gemeenskaplike besluit nodig. Anders kan 'n rekening sy toelating oorskry deur aan verskillende liggings te koppel. Gedeelde of herstelbare toestand los dit op, en gedeelde toestand is 'n ontwerpvereiste eerder as bewyse van toesig.
Geen van daardie koördinering vereis blaaisgeskiedenisse nie. 'n Poort wat pakkette aanstuur, hoef nie te weet watter werwe 'n sessie besoek het om sessies te tel nie, en die twee datastrome word gewoonlik deur heeltemal verskillende komponente hanteer.
Om 'n telling in die geheue te hou, maak die gepaardgaande feite ook nie anoniem nie. Terwyl die diens loop, onthul 'n subskripsie-gekoppelde rekord dat 'n rekening aktiewe verbindings het, en toegang tot daardie toestand plus sy leeftyd is albei die moeite werd om na te vra.
Waar die toestand daarna heen gaan
Die privaatheidsvraag is nie of die bediener kan tel nie. Vra wat met 'n geëindigde sessie gebeur: word die rekord verwyder, of word dit 'n gebeurtenis in 'n moniteringreeks? Vra dan watter ander komponente dieselfde gebeurtenis gesien het, want verifikasielogs, boekhoudkundige rekords en rugsteune kan elkeen 'n kopie hou wat die handhawingspad weggegooi het.
RADIUS-boekhouding is die duidelikste voorbeeld. 'n Start-en-Stop-paar bestaan om fakturering en sessiebeheer te ondersteun, en dit skep 'n rekord van die verbinding ongeag of iemand dit ooit as 'n geskiedenis naslaan. 'n Diens wat limiete deur boekhouding handhaaf, behou dus per konstruksie meer as 'n gleuftabel.
Skrapping het ook 'n vorm. 'n Rekord wat uit die lewende tabel verwyder is, kan in 'n rugsteun van 'n uur vroeër voortbestaan, en die bewaartydperk van daardie rugsteun is sy eie beleidsverklaring. Om net die primêre stoor te lees, gee 'n onvolledige antwoord.
Vra die vraag in terme van velde
RFC 6973 se leiding oor dataminimalisering bind die data wat ingesamel en gestoor word aan die doel wat gedien word. Toegepas hier, is die nuttige vraag watter velde die gelyktydige-toelatingstaak werklik nodig het, en watter doel dit regverdig om elkeen te hou nadat daardie taak eindig.
'n Presiese diensverklaring skei lewende verbindingstoestand wat gebruik word om die toelating te handhaaf van enige rekords wat ná beëindiging behou word, en dit noem die ander stelsels binne die belofte se omvang. 'n Sin wat net sê dat drie verbindings afgedwing word, bevestig nóg dat 'n argief bestaan, nóg dat daar geen is nie.
Wanneer die lewenssiklus onduidelik is, teken dit aan as 'n onbeantwoorde bewaarvraag eerder as 'n uitspraak. Die teenwoordigheid van 'n limiet is nie bewyse van 'n verborge geskiedenis nie, en 'n geloofwaardige lewende-toestand-verduideliking is nie 'n oudit van die verskaffer nie.