Что считается успешным входом в VPN в отчёте?

Три отчёта об одном и том же VPN могут расходиться, и ни один из них не будет ошибочным, потому что каждый вкладывает в успешный вход что-то своё. Один считает соединения, дошедшие до сервера, другой — идентичности, принятые на этапе аутентификации, а третий — сессии, завершившие инициализацию. Выбор одного из них до сбора данных — это разница между метрикой и аргументом.

Полезный вопрос не в том, какое определение верно вообще, а в том, на какой результат читатель будет действовать.

Три разных события носят одно название

Сервер принимает транспортное соединение, как только завершается рукопожатие, а это происходит до предъявления любых учётных данных. Это событие говорит, что порт доступен и сетевой путь работает, и ничего не говорит о том, кто подключился. Аутентификация — более поздний этап, который может не пройти, и он может пройти для идентичности, которой никогда не разрешают вход в сеть.

Инициализация идёт после аутентификации, и туннель, завершивший инициализацию, может простаивать до конца дня. Запрос приложения — единственное событие, которое показывает, что пользователь добрался до чего-то нужного ему. Эти этапы вложены друг в друга, поэтому счёт самого широкого всегда будет превышать счёт самого узкого. Ничто в последовательности событий не доказывает, что пользователь был продуктивен, — только то, что каждые ворота открылись в свой черёд.

Документация продукта обычно прямо называет состояния. заметки об интерфейсе управления OpenVPN разделяют TCP-соединение, результат аутентификации и завершённую инициализацию, и это именно то различие, которое нужно отчёту. Состояние с меткой connected не удостоверяет, что общий доступ к файлам или операция с базой данных позже удались.

Считайте сессии, идентичности или запросы

Определите единицу, прежде чем определять число. Счёт сессий отвечает, сколько раз использовался сервис, счёт идентичностей — сколько разных учётных записей появилось, а счёт запросов — сколько работы было сделано. Поставщики тоже считают это по-разному, и право, измеренное в пользователях, нельзя сравнивать с графиком, измеренным в сессиях. Выбор неверной единицы — это то, из-за чего план по мощности оказывается рассчитанным на неверное количество.

Переподключения — это место, где счёт сессий тихо раздувается. Клиент, который обрывается каждые несколько минут и подключается снова, создаёт десятки записей сессий на одного человека, поэтому отчёт, считающий сессии как людей, завысит использование именно в тех условиях, где надёжность хуже всего. Запишите правило: новая сессия после переподключения считается отдельно либо продолжает предыдущую в пределах заданного окна.

Адреса — самая слабая из доступных идентичностей. Адрес туннеля может быть выдан другому пользователю через несколько минут, и два пользователя могут делить один адрес через трансляцию. Прикрепляйте идентификатор учётной записи из события аутентификации, а не выводите человека из адреса в журнале.

Проверьте определение на одном реальном дне

Возьмите один день журналов и посчитайте один и тот же трафик тремя способами. Если три числа близки, определение может быть не так важно для вашей цели; если они различаются в большой кратности, отчёт должен сказать, какое из них он использует.

journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Initialization Sequence Completed"
journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Peer Connection Initiated"
awk '/VERIFY OK/ {print $NF}' /var/log/openvpn-server.log | sort -u | wc -l

Запустите то же извлечение в день с известным сбоем и сравните форму, а не сумму. В день, когда верхний канал дрожал, должен быть всплеск событий соединения при умеренном росте числа разных учётных записей, а если его нет, счётчик, вероятно, измеряет не то, что утверждает отчёт.

Храните сам запрос рядом с результатом. Любой может воспроизвести задокументированный фильтр, а число без своего фильтра не поддаётся аудиту.

Сообщайте, что доказывает событие

Неудачная попытка заслуживает отдельной категории, а не быть втиснутой в любую из сторон. К неудачам относятся неверно набранные пароли, клиенты с устаревшим профилем и намеренное зондирование, и у всех трёх разные ответы. Неудача не является доказательством успешного проникновения и не является доказательством безвредности.

Пишите вывод с той силой, которую поддерживает событие: эта учётная запись аутентифицировалась на этом сервисе в этом окне, из этого источника, и сессия дошла до инициализации. Всё о том, что пользователь делал потом, требует записи на стороне приложения, а не дополнительных данных туннеля.

Когда отчёт попадает к тому, кто будет принимать решение о лицензировании, мощности или безопасности, ставьте определение в первую строку, а не в сноску. Определение и есть находка, и число имеет смысл только внутри него.