Limity připojení VPN: živý stav versus uchovaná historie
Limit tří připojení vyžaduje živý stav slotů, nikoli historii prohlížení: co musí mechanismus ukládat, co může zahodit a kam tento stav dál jde.
Tři současná připojení jsou rozhodnutím o přijetí a jeho zodpovězení vyžaduje vědět, které sloty jsou právě obsazené, nikoli co se stalo minulý měsíc. Služba může odmítnout čtvrtou relaci z malé tabulky aktivních záznamů a vůbec nevytvořit časovou osu. To je tvrzení o mechanismu, ne o operátorovi, a rozdíl je důležitý, když čtete zásady ochrany soukromí. Model níže ukazuje, co rozhodnutí potřebuje a co může zahodit.
Mechanismus: tabulka slotů, ne log
Nejjednodušší implementace přiřazuje předplatnému až tři záznamy aktivních relací. Každá přijatá relace zabere jeden slot a slot se uvolní, když služba rozhodne, že relace skončila. Záznam potřebuje dostatečně konkrétní identitu, aby uvolnění jednoho připojení neuvolnilo slot jiného připojení, a proto je identifikátor relace důležitější než název účtu.
Obsazenost a historie jsou různé datové struktury. Obsazenost odpovídá na otázku ano, nebo ne o přítomnosti a lze ji zahodit ve chvíli, kdy relace skončí. Historie je proud událostí pouze pro přidávání a přežívá, protože se někdo rozhodl ji uchovat. Služba může mít jedno, obojí, nebo ani jedno.
Rozdíl je zvenčí neviditelný. Viditelný limit připojení je slučitelný s malým počítadlem v paměti, sdílenou tabulkou databáze i úplným archivem událostí s panelem. Nic na limitu neříká, který z nich běží.
| 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 |
Proč živý model stále potřebuje koordinaci
Ztracené připojení nemusí být hned rozpoznáno jako ukončené. Brána čeká na časový limit, selhání keepalive nebo zastavení účtování, a dokud jedno z toho nepřijde, slot zůstává obsazený. Uživatel, který se v tomto okně znovu připojí, vidí odmítnutí, které nemá nic společného se čtvrtým zařízením.
Restartovaný server musí sladit svůj stav a několik bran obsluhujících stejný účet potřebuje společné rozhodnutí. Jinak může účet překročit svůj limit připojením z různých míst. Sdílený nebo obnovitelný stav to řeší a sdílený stav je požadavek návrhu, nikoli důkaz sledování.
Nic z této koordinace nevyžaduje historii prohlížení. Brána, která předává pakety, nemusí vědět, které stránky relace navštívila, aby mohla počítat relace, a oba datové toky obvykle zpracovávají zcela odlišné komponenty.
Udržování počtu v paměti také nečiní související skutečnosti anonymními. Dokud služba běží, záznam spojený s předplatným prozrazuje, že účet má aktivní připojení, a přístup k tomuto stavu i jeho životnosti stojí za otázku.
Kam stav potom jde
Otázka soukromí není, zda server umí počítat. Ptejte se, co se stane s ukončenou relací: záznam se odstraní, nebo se stane událostí v monitorovací řadě? Pak se ptejte, které další komponenty viděly stejnou událost, protože autentizační logy, účetní záznamy a zálohy mohou každý uchovat kopii, kterou cesta vynucení zahodila.
RADIUS účtování je nejjasnější příklad. Dvojice Start a Stop existuje na podporu fakturace a řízení relací a vytváří záznam o připojení bez ohledu na to, zda ho někdo někdy vyhledá jako historii. Služba, která vynucuje limity přes účtování, proto konstrukčně uchovává víc než tabulku slotů.
Mazání má také tvar. Záznam odstraněný z živé tabulky může přetrvat v záloze pořízené o hodinu dříve a doba uchování této zálohy je vlastní politické prohlášení. Čtení pouze primárního úložiště dává neúplnou odpověď.
Položte otázku v pojmech polí
Pokyny RFC 6973 k minimalizaci dat svazují shromažďovaná a ukládaná data s účelem, kterému slouží. Při aplikaci zde je užitečná otázka, která pole úloha souběžného přijetí skutečně potřebuje a jaký účel ospravedlňuje uchování každého z nich poté, co tato úloha skončí.
Přesné prohlášení služby odděluje živý stav připojení používaný k vynucení limitu od jakýchkoli záznamů uchovávaných po ukončení a pojmenovává ostatní systémy v rozsahu slibu. Věta, která říká jen, že se vynucují tři připojení, neprokazuje ani existenci archivu, ani jeho neexistenci.
Když je životní cyklus nejasný, zapište ho jako nezodpovězenou otázku uchování, nikoli jako verdikt. Přítomnost limitu není důkazem skryté historie a věrohodné vysvětlení živého stavu není auditem poskytovatele.