Що вважається успішним входом у 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

Запустіть те саме вилучення в день із відомим збоєм і порівняйте форму, а не суму. У день, коли верхній канал тремтів, має бути сплеск подій з'єднання за помірного зростання різних облікових записів, а якщо його немає, лічильник, імовірно, вимірює не те, що стверджує звіт.

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

Повідомляйте, що доводить подія

Невдала спроба заслуговує на окрему категорію, а не бути втиснутою в будь-який бік. До невдач належать неправильно набрані паролі, клієнти із застарілим профілем і навмисне зондування, і всі три мають різну відповідь. Невдача не є доказом успішного проникнення і не є доказом нешкідливості.

Пишіть висновок із тією силою, яку підтримує подія: цей обліковий запис автентифікувався на цьому сервісі в цьому вікні, з цього джерела, і сеанс дійшов до ініціалізації. Усе про те, що користувач робив потім, вимагає запису на боці застосунку, а не додаткових даних тунелю.

Коли звіт потрапляє до того, хто ухвалюватиме рішення про ліцензування, потужність або безпеку, ставте визначення в перший рядок, а не в примітку. Визначення і є знахідка, і число має сенс лише всередині нього.