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