Чи можуть лічильники трафіку показати, які сайти ви відвідували через VPN?

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

Почніть з екрана, який ви читаєте

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

Інтервал важливий не менше за джерело. Підсумок за весь час, добовий зріз і миттєва швидкість — три різні вимірювання, і лише миттєва швидкість має достатню роздільність, щоб зіставити її з однією дією.

Запишіть джерело та інтервал, перш ніж записати висновок.

Лічильники вимірюють рівні, а не сторінки

На вузлі WireGuard лічильники передавання в wg show — це підсумки для цього вузла, включно із зашифрованим вмістом. Вивід стану OpenVPN повідомляє байти на клієнта на власному рівні. На хості інтерфейс tun рахує внутрішні пакети IP, а фізичний адаптер — зовнішні пакети UDP, тож вони різняться на накладні витрати інкапсуляції та на все інше, що ділить канал.

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

Тому великий підсумок вказує на навантаження на дані й ні на що конкретніше. Розмір завантаженого файлу та приріст лічильника пов'язані, але рідко рівні.

Що підсумок може і чого не може підтвердити

Підсумок байтів не може назвати сайт, бо імена та URL живуть усередині сесій TLS або QUIC, до яких лічильник ніколи не заглядає. Він не відділить відеопотік від великої резервної копії, а завантаження сторінки від циклу оновлення реклами. Підтвердити він може твердження про обсяг і час: цей пристрій передав стільки даних за таке вікно.

Щоб перетворити це на твердження про людину, потрібні два додаткові складники: ідентичність і кореляція.

Документ RFC 6973 privacy considerations пояснює, чому це поєднання важливе, і саме тому ретельний звіт відділяє спостережене від виведеного. Якщо висновку потрібне слово тому що, самого лічильника не досить як доказу.

Час та ідентичність змінюють відповідь

Прив'яжіть лічильник до названого користувача й точного інтервалу, і він стане іншим об'єктом.

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

Це чесна межа: закономірності видно, сенс — ні.

Вирішіть, що зберігати, перш ніж збирати

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

Під час пошуку несправностей порівнюйте лічильник із дією, яку перевіряєте. Рівно зростаючий підсумок доводить, що трафік іде, а не що застосунок працює.

Рівний лічильник під час сесії, яка явно працює, зазвичай означає, що ви читаєте кешоване значення або не той інтерфейс. Назвіть збережені поля та вікно, і наступній перевірці буде що звірити.