Kan båndbreddetellere si hvilke sider du besøkte via VPN?

Du åpner trafikksiden til ruteren, eller dashbordet til en VPN-leverandør, og der står en bytetotal per enhet med en graf ved siden av. Det er fristende å lese grafen som en nettleserhistorikk. Det er den ikke, og grunnen er strukturell snarere enn juridisk. En teller summerer størrelser, mens en historikk registrerer destinasjoner og innhold, og bare det siste forteller hvor noen dro.

Begynn med skjermen du ser på

Før du tolker et tall, finn ut hva som produserte det. En ruters total per enhet kommer vanligvis fra tellere på det fysiske grensesnittet, en VPN-klients total kommer fra tunnelen, og et leverandørpanel kommer fra regnskapet hos motparten. Hver teller en annen del av samme økt. To paneler som viser ulike tall for samme time, har vanligvis begge rett.

Intervallet betyr like mye som kilden. En livstidssum, en daglig oppsummering og en sanntidsfart er tre forskjellige målinger, og bare sanntidsfarten har oppløsning nok til å matche én handling.

Skriv ned kilden og intervallet før du skriver ned en konklusjon.

Tellere måler lag, ikke sider

På en WireGuard-peer er overføringstellerne i wg show totaler for den peeren, inkludert kryptert nyttelast. OpenVPN sin statusutskrift rapporterer byte per klient på sitt eget lag. På verten teller tun-grensesnittet indre IP-pakker mens den fysiske adapteren teller ytre UDP-pakker, så de to skiller seg med overheaden fra innkapslingen og med alt annet som deler lenken.

Retransmisjoner blåser opp en sum uten at nytt innhold kommer inn, og en synkronisering i bakgrunnen kan dominere en time mens brukeren leser ren tekst.

Derfor tyder en stor sum på en datatung aktivitet og ingenting mer spesifikt. Størrelsen på en nedlastet fil og tellerens delta henger sammen, men de er sjelden like.

Hva en sum kan og ikke kan underbygge

En bytetotal kan ikke navngi et nettsted, fordi navn og URL-er ligger inne i TLS- eller QUIC-økter som telleren aldri ser inn i. Den kan ikke skille en videostrøm fra en stor sikkerhetskopi, eller lasting av en side fra en gjentatt annonseforespørsel. Det den kan underbygge, er en påstand om volum og tid: denne enheten flyttet så mye data i dette vinduet.

Å gjøre det til en påstand om en person krever to ingredienser til, en identitet og en korrelasjon.

Dokumentet RFC 6973 privacy considerations forklarer hvorfor den kombinasjonen betyr noe, og det er også derfor en grundig rapport skiller det observerte fra det utledede. Hvis konklusjonen trenger ordet fordi, er telleren alene ikke nok bevis.

Tidspunkt og identitet endrer svaret

Knytt en teller til en navngitt bruker og et presist intervall, og den blir et annet objekt.

Da kan du legge den ved siden av andre observasjoner: en innloggingspost, en DNS-spørring, en økt på et annet system. Telleren avslørte ikke destinasjonen, men den hjalp noen som allerede hadde en hypotese med å bekrefte den. Kryptering beskytter innhold og navn under transport, og den skjuler ikke at en strøm fantes, hvor stor den var eller når den startet.

Det er den ærlige grensen: mønstre er synlige, betydning er det ikke.

Bestem hva du beholder før du samler inn

Hvis kravet er kapasitetsplanlegging, svarer et grovt daglig aggregat på det og koster lite. Hvis kravet er historikk per bruker, si det eksplisitt, navngi feltene og oppbevaringsvinduet, og behandl beslutningen som policy i stedet for som en dashbordfunksjon. Å samle inn finmasket historikk fordi panelet støtter det, er hvordan oppbevaring vokser uten at noen bestemmer.

Ved feilsøking, sammenlign telleren med handlingen du tester. En jevnt stigende sum beviser at trafikk flyter, ikke at programmet virker.

En flat teller i en økt som tydelig virker, betyr vanligvis at du leser en bufret verdi eller feil grensesnitt. Navngi de lagrede feltene og vinduet, så har neste revisjon noe konkret å kontrollere.