Czy liczniki ruchu pozwalają ustalić, jakie strony odwiedzasz przez VPN?

Otwierasz stronę ruchu routera albo panel dostawcy VPN i widzisz sumę bajtów na urządzenie z wykresem obok. Kuszące jest czytanie tego wykresu jak historii przeglądania. To nie jest historia i powód jest strukturalny, a nie prawny. Licznik sumuje rozmiary, a historia zapisuje cele i treść, i tylko ta druga mówi, dokąd ktoś poszedł.

Zacznij od ekranu, który czytasz

Zanim zinterpretujesz liczbę, ustal, co ją wytworzyło. Suma na urządzenie w routerze zwykle pochodzi z liczników interfejsu fizycznego, suma w kliencie VPN pochodzi z jego tunelu, a panel dostawcy z rozliczeń po drugiej stronie. Każdy liczy inny fragment tej samej sesji. Dwa panele pokazujące różne liczby dla tej samej godziny zwykle oba mają rację.

Interwał znaczy tyle samo co źródło. Suma od początku działania, dzienne podsumowanie i chwilowa prędkość to trzy różne pomiary, a tylko chwilowa prędkość ma dość rozdzielczości, by zestawić ją z jedną czynnością.

Zapisz źródło i interwał, zanim zapiszesz wniosek.

Liczniki mierzą warstwy, nie strony

Na peera WireGuard liczniki transferu w wg show to sumy dla tego peera, wraz z zaszyfrowanym ładunkiem. Wynik stanu OpenVPN podaje bajty na klienta na własnej warstwie. Na hoście interfejs tun liczy wewnętrzne pakiety IP, a karta fizyczna liczy zewnętrzne pakiety UDP, więc oba różnią się narzutem enkapsulacji i wszystkim innym, co dzieli łącze.

Retransmisje zawyżają sumę, choć nie dociera żadna nowa treść, a synchronizacja w tle może zdominować godzinę, podczas gdy użytkownik czyta zwykły tekst.

Dlatego duża suma sugeruje aktywność intensywnie korzystającą z danych i nic bardziej konkretnego. Rozmiar pobranego pliku i przyrost licznika są powiązane, ale rzadko równe.

Co suma może, a czego nie może uzasadnić

Suma bajtów nie wskaże witryny, bo nazwy i adresy URL żyją wewnątrz sesji TLS lub QUIC, do których licznik nigdy nie zagląda. Nie odróżni strumienia wideo od dużej kopii zapasowej ani wczytania strony od pętli odświeżania reklam. Może uzasadnić twierdzenie o wolumenie i czasie: to urządzenie przesłało tyle danych w tym oknie.

Aby zrobić z tego twierdzenie o osobie, potrzeba dwóch dodatkowych składników: tożsamości i korelacji.

Dokument RFC 6973 privacy considerations wyjaśnia, dlaczego to połączenie ma znaczenie, i dlatego staranny raport oddziela to, co zaobserwowano, od tego, co wywnioskowano. Jeśli wniosek potrzebuje słowa ponieważ, sam licznik nie jest wystarczającym dowodem.

Czas i tożsamość zmieniają odpowiedź

Przypisz licznik do nazwanego użytkownika i precyzyjnego interwału, a stanie się innym obiektem.

Możesz wtedy zestawić go z innymi obserwacjami: wpisem logowania, zapytaniem DNS, sesją w innym systemie. Licznik nie ujawnił celu, ale pomógł komuś, kto już miał hipotezę, ją potwierdzić. Szyfrowanie chroni treść i nazwy w tranzycie i nie ukrywa tego, że przepływ istniał, jak duży był ani kiedy się zaczął.

To jest uczciwa granica: wzorce są widoczne, znaczenie nie.

Zdecyduj, co zachowujesz, zanim zaczniesz zbierać

Jeśli wymogiem jest planowanie pojemności, odpowiada na niego zgrubny dzienny agregat i niewiele kosztuje. Jeśli wymogiem jest historia na użytkownika, powiedz to wprost, nazwij pola i okno retencji, i potraktuj decyzję jako politykę, a nie funkcję panelu. Zbieranie szczegółowej historii, bo panel to obsługuje, to sposób, w jaki retencja rośnie, choć nikt tego nie zdecydował.

Przy rozwiązywaniu problemów porównaj licznik z czynnością, którą testujesz. Stale rosnąca suma dowodzi, że ruch płynie, a nie że aplikacja działa.

Płaski licznik podczas sesji, która wyraźnie działa, zwykle oznacza, że czytasz wartość z pamięci podręcznej albo niewłaściwy interfejs. Nazwij zachowane pola i okno, a następny audyt będzie miał co sprawdzić.