Ограничения на VPN връзки: живо състояние срещу запазена история
Ограничението от три връзки се нуждае от живо състояние на слотовете, а не от история на сърфирането: какво трябва да съхранява механизмът, какво може да изхвърли и накъде отива това състояние.
Три едновременни връзки е решение за допускане и отговорът му изисква да се знае кои слотове са заети сега, а не какво се е случило миналия месец. Услуга може да откаже четвърта сесия от малка таблица с активни записи и изобщо да не изгражда хронология. Това е твърдение за механизма, не за оператора, и разликата е важна, когато четете политика за поверителност. Моделът по-долу показва какво е нужно на решението и какво може да изхвърли.
Механизмът: таблица на слотовете, а не дневник
Най-простата реализация свързва абонамент с до три записа за активни сесии. Всяка допусната сесия заема един слот и слотът се освобождава, когато услугата реши, че сесията е приключила. Записът се нуждае от достатъчно конкретна идентичност, за да не освобождава освобождаването на една връзка слота на друга, поради което идентификаторът на сесията е по-важен от името на акаунта.
Заетостта и историята са различни структури от данни. Заетостта отговаря на въпрос да-или-не за настоящето и може да бъде изхвърлена в момента, в който сесията приключи. Историята е поток от събития само за добавяне и оцелява, защото някой е избрал да я пази. Услугата може да има едното, и двете, или нито едно.
Разликата е невидима отвън. Видимо ограничение на връзките е съвместимо с малък брояч в паметта, споделена таблица в база данни и пълен архив на събития с табло. Нищо в ограничението не ви казва кое от тях работи.
| 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 |
Защо живият модел все още се нуждае от координация
Изгубена връзка може да не бъде разпозната като приключила веднага. Шлюзът чака таймаут, отказ на keepalive или спиране на отчитането и докато едно от тях не дойде, слотът остава зает. Потребител, който се свърже отново в този прозорец, вижда отказ, който няма нищо общо с четвърто устройство.
Рестартиран сървър трябва да съгласува състоянието си, а няколко шлюза, обслужващи един акаунт, се нуждаят от общо решение. Иначе акаунтът може да надхвърли квотата си, като се свързва от различни места. Споделеното или възстановимо състояние решава това и споделеното състояние е изискване към дизайна, а не доказателство за наблюдение.
Никое от това съгласуване не изисква история на сърфирането. Шлюз, който препраща пакети, не трябва да знае кои сайтове е посетила една сесия, за да брои сесии, и двата потока от данни обикновено се обработват от напълно различни компоненти.
Пазенето на брояч в паметта също не прави свързаните факти анонимни. Докато услугата работи, запис, свързан с абонамент, разкрива, че акаунтът има активни връзки, и достъпът до това състояние плюс живота му са двете струващи да се питат.
Накъде отива състоянието след това
Въпросът за поверителността не е дали сървърът може да брои. Питайте какво се случва с приключила сесия: записът премахва ли се или се превръща в събитие в серия за мониторинг? След това питайте кои други компоненти са видели същото събитие, защото журналите за удостоверяване, записите за отчитане и резервните копия могат да пазят копие, която пътят за налагане е изхвърлил.
Отчитането RADIUS е най-ясният пример. Двойка Start и Stop съществува, за да поддържа таксуване и контрол на сесиите, и създава запис за връзката независимо дали някой някога я търси като история. Услуга, която налага ограничения чрез отчитане, следователно по своя конструкция запазва повече от таблица на слотовете.
Изтриването също има форма. Запис, премахнат от живата таблица, може да остане в резервно копие, направено час по-рано, и срокът на съхранение на тази копия е собствено политическо изявление. Четенето само на основното хранилище дава непълен отговор.
Задайте въпроса чрез полетата
Насоките на RFC 6973 за минимизиране на данните свързват събраните и съхранявани данни с целта, на която служат. Приложено тук, полезният въпрос е кои полета задачата за едновременно допускане действително изисква и каква цел оправдава запазването на всеки от тях, след като тази задача приключи.
Точно изявление за услугата отделя живото състояние на връзката, използвано за налагане на квотата, от всякакви записи, запазени след прекратяване, и назовава другите системи в обхвата на обещанието. Изречение, което казва само, че се налагат три връзки, не установява нито че архив съществува, нито че няма.
Когато жизненият цикъл е неясен, запишете го като въпрос за съхранение без отговор, а не като присъда. Наличието на ограничение не е доказателство за скрита история и правдоподобно обяснение на живото състояние не е одит на доставчика.