VPN-kapcsolati limitek: élő állapot vagy megőrzött előzmény
Egy három kapcsolatos limithez élő helyállapot kell, nem böngészési előzmény: mit kell tárolnia a mechanizmusnak, mit dobhat el, és hová kerül ez az állapot később.
Három egyidejű kapcsolat egy beengedési döntés, és a megválaszolásához azt kell tudni, mely helyek foglaltak éppen most, nem azt, hogy mi történt múlt hónapban. Egy szolgáltatás elutasíthat egy negyedik munkamenetet az aktív rekordok kis táblája alapján, és soha nem épít idővonalat. Ez a mechanizmusról szóló állítás, nem az üzemeltetőről, és a különbség számít, amikor adatvédelmi irányelvet olvasol. Az alábbi modell megmutatja, mire van szüksége a döntésnek, és mit dobhat el.
A mechanizmus: helytábla, nem napló
A legegyszerűbb megvalósítás egy előfizetést legfeljebb három aktív munkamenet-rekordhoz rendel. Minden beengedett munkamenet egy helyet foglal, és a hely akkor szabadul fel, amikor a szolgáltatás úgy dönt, hogy az a munkamenet véget ért. A rekordnak elég egyedi azonosítóra van szüksége ahhoz, hogy az egyik kapcsolat felszabadítása ne szabadítsa fel egy másik kapcsolat helyét; ezért a munkamenet-azonosító fontosabb, mint a fiók neve.
A foglaltság és az előzmény különböző adatszerkezetek. A foglaltság egy igen-nem kérdésre válaszol a jelenről, és el lehet dobni abban a pillanatban, amikor a munkamenet véget ér. Az előzmény csak hozzáfűzhető eseményfolyam, és azért marad meg, mert valaki úgy döntött, hogy megtartja. Egy szolgáltatásnak lehet az egyik, mindkettő vagy egyik sem.
A különbség kívülről láthatatlan. Egy látható kapcsolati limit összeegyeztethető egy parányi memóriabeli számlálóval, egy közös adatbázistáblával és egy irányítópulttal ellátott teljes eseményarchívummal. A limitről semmi nem árulja el, melyik fut.
| 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 |
Miért van mégis összehangolásra szükség az élő modellnél
Lehet, hogy egy elveszett kapcsolatot nem ismernek fel azonnal befejezettként. Az átjáró időtúllépésre, keepalive-hibára vagy elszámolási leállásra vár, és amíg valamelyik meg nem érkezik, a hely foglalt marad. Az a felhasználó, aki ebben az ablakban újra csatlakozik, olyan elutasítást lát, amelynek semmi köze egy negyedik eszközhöz.
Egy újraindított kiszolgálónak össze kell hangolnia az állapotát, és több átjárónak, amely ugyanazt a fiókot szolgálja ki, közös döntésre van szüksége. Különben egy fiók túllépheti a keretét azzal, hogy különböző helyekhez csatlakozik. A megosztott vagy helyreállítható állapot ezt megoldja, és a megosztott állapot tervezési követelmény, nem a megfigyelés bizonyítéka.
Ennek az összehangolásnak egyik része sem igényel böngészési előzményeket. Egy csomagokat továbbító átjárónak nem kell tudnia, mely oldalakat látogatta egy munkamenet ahhoz, hogy munkameneteket számoljon, és ezt a két adatfolyamot általában teljesen különböző összetevők kezelik.
A számláló memóriában tartása sem teszi névtelenné a kapcsolódó tényeket. Amíg a szolgáltatás fut, az előfizetéshez kötött rekord elárulja, hogy egy fióknak aktív kapcsolatai vannak, és mind az állapothoz való hozzáférés, mind annak élettartama kérdezésre érdemes.
Hová kerül az állapot utána
Az adatvédelmi kérdés nem az, hogy a kiszolgáló tud-e számolni. Kérdezd meg, mi történik egy befejezett munkamenettel: eltávolítják a rekordot, vagy eseménnyé válik egy megfigyelési sorozatban? Utána kérdezd meg, mely más összetevők látták ugyanazt az eseményt, mert a hitelesítési naplók, az elszámolási rekordok és a biztonsági mentések mindegyike őrizhet egy példányt, amelyet a kényszerítési útvonal elvetett.
A RADIUS-elszámolás a legvilágosabb példa. A Start és Stop pár a számlázás és a munkamenet-vezérlés támogatására létezik, és létrehozza a kapcsolat rekordját, függetlenül attól, hogy valaki valaha előzményként lekérdezi-e. Egy szolgáltatás, amely elszámolás révén kényszeríti ki a limiteket, ezért felépítésénél fogva többet őriz egy helytáblánál.
A törlésnek is van formája. Az élő táblából eltávolított rekord megmaradhat egy egy órával korábban készült biztonsági mentésben, és annak a mentésnek a megőrzési ideje önálló szabályzati nyilatkozat. Ha csak az elsődleges tárolót olvasod, hiányos választ kapsz.
Tegyük fel a kérdést mezők szerint
Az RFC 6973 adatminimalizálási útmutatása összeköti a gyűjtött és tárolt adatokat a szolgált céllal. Ide alkalmazva a hasznos kérdés az, mely mezőkre van ténylegesen szüksége az egyidejű beengedés feladatának, és milyen cél igazolja mindegyik megtartását a feladat vége után.
Egy pontos szolgáltatási nyilatkozat elválasztja a keret kikényszerítésére használt élő kapcsolati állapotot a megszűnés után megőrzött bármilyen rekordtól, és megnevezi a többi rendszert az ígéret hatókörén belül. Egy mondat, amely csak azt mondja, hogy három kapcsolatot kényszerítenek ki, nem bizonyítja sem azt, hogy létezik archívum, sem azt, hogy nem.
Amikor az életciklus nem világos, jegyezd fel megválaszolatlan megőrzési kérdésként, ne ítéletként. Egy limit jelenléte nem bizonyíték rejtett előzményre, és az élő állapot valószínű magyarázata nem a szolgáltató auditja.