Ліміти підключень 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 щодо мінімізації даних пов'язують зібрані та збережені дані з метою, якій вони служать. У застосуванні тут корисне питання: які поля задачі одночасного допуску справді потрібні і яка мета виправдовує зберігання кожного з них після завершення цієї задачі.
Точна заява служби відокремлює поточний стан підключення, який використовується для забезпечення квоти, від будь-яких записів, збережених після припинення, і називає інші системи в межах обіцянки. Фраза, яка каже лише, що ліміт у три підключення забезпечується, не встановлює ні що архів існує, ні що його немає.
Коли життєвий цикл неясний, фіксуйте це як невідповідене питання зберігання, а не як вердикт. Наявність ліміту не є доказом прихованої історії, а правдоподібне пояснення живого стану не є аудитом постачальника.