Kan båndbreddetellere fortelle hva du har besøkt på en VPN?

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

Begynn med skjermen du leser

Før du tolker et tall, finn ut hva som produserte det. En ruters total per enhet kommer vanligvis fra tellere på fysiske grensesnitt, en VPN-klients total kommer fra tunnelen, og et leverandørpanel kommer fra regnskapet på den andre siden. Hver av dem 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 livstidstotal, en daglig sammenstilling og en sanntidsfrekvens er tre forskjellige målinger, og bare sanntidsfrekvensen har oppløsning nok til å samsvare med é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, kryptert nyttelast inkludert. Statusutdataene fra OpenVPN rapporterer bytes 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 innkapslingskostnader og med alt annet som deler lenken.

Retransmisjoner blåser opp en total uten at nytt innhold kommer, og en bakgrunnssynkronisering kan dominere en hel time mens brukeren leser vanlig tekst.

Derfor antyder en stor total en datatung aktivitet og ikke noe mer spesifikt. Størrelsen på en nedlastet fil og tellerens delta henger sammen, men de er sjelden like.

Hva en total kan og ikke kan underbygge

En bytetotal kan ikke navngi et nettsted, fordi navn og URL-er lever inne i TLS- eller QUIC-økter som telleren aldri inspiserer. Den kan ikke skille en videostrøm fra en stor sikkerhetskopi, eller en sideinnlasting fra en løkke for annonseoppdatering. Det den kan underbygge, er en påstand om volum og tid: denne enheten flyttet så mye data i dette vinduet.

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

Dokumentet RFC 6973 personvernhensyn forklarer hvorfor den kombinasjonen betyr noe, og også hvorfor en grundig rapport skiller det som ble observert, fra det som ble utledet. Hvis konklusjonen trenger ordet fordi, er telleren alene ikke godt 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 sammenligne den med 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 underveis, 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 en grov daglig aggregering på det og koster lite. Hvis kravet er historikk per bruker, si det eksplisitt, navngi feltene og oppbevaringsvinduet, og behandle avgjørelsen som policy snarere enn som en dashbordfunksjon. Å samle inn finmasket historikk fordi panelet støtter det, er måten oppbevaring vokser uten at noen bestemmer.

For feilsøking, sammenlign telleren med handlingen du tester. En jevnt økende total beviser at trafikken flyter, ikke at applikasjonen virker.

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