Што лічыцца паспяховым уваходам у 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

Запусціце тое ж выманне ў дзень з вядомым збоем і параўнайце форму, а не суму. Дзень, калі верхняя лінія трапятала, павінен паказаць скачок падзей злучэння пры ўмераным росце розных уліковых запісаў, а калі гэтага няма, лічыльнік, хутчэй за ўсё, вымярае не тое, што сцвярджае справаздача.

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

Паведамляйце пра тое, што даказвае падзея

Няўдалая спроба заслугоўвае ўласнай катэгорыі, а не зліцця з любым з бакоў. Да няўдач адносяцца памылкова ўведзеныя паролі, кліенты са састарэлым профілем і наўмыснае зандванне, і ўсе тры маюць розны адказ. Няўдача не з’яўляецца доказам паспяховага ўварвання і не з’яўляецца доказам бясшкоднасці.

Запішыце выснову з той сілай, якую падтрымлівае падзея: гэты ўліковы запіс аўтэнтыфікаваўся на гэтай паслузе ў гэтым акне, з гэтай крыніцы, і сеанс дасягнуў ініцыялізацыі. Усё пра тое, што карыстальнік рабіў далей, патрабуе запісу з боку праграмы, а не болей даных тунеля.

Калі справаздача ідзе да таго, хто будзе прымаць рашэнне пра ліцэнзіі, магутнасці ці бяспеку, змяшчайце вызначэнне ў першым радку, а не ў зносцы. Вызначэнне — гэта і ёсць выснова, і лік мае сэнс толькі ўнутры яго.