Kan båndbreddetællere vise, hvilke sider du har været på via en VPN?

Du åbner routerens trafikside eller en VPN-udbyders dashboard, og der er en bytetotal pr. enhed med en graf ved siden af. Det frister at læse den graf som en browserhistorik. Det er den ikke, og årsagen er strukturel snarere end juridisk. En tæller lægger størrelser sammen, mens en historik registrerer destinationer og indhold, og kun det andet fortæller dig, hvor nogen gik hen.

Begynd med den skærm, du læser

Før du fortolker et tal, så find ud af, hvad der har produceret det. En routers total pr. enhed kommer normalt fra fysiske interface-tællere, en VPN-klients total kommer fra dens tunnel, og et udbyderpanel kommer fra regnskab hos den fjerne peer. Hver især tæller de en forskellig skive af samme session. To paneler, der viser forskellige tal for den samme time, har normalt begge ret.

Intervallet betyder lige så meget som kilden. En levetidstotal, en daglig opsummering og en live-hastighed er tre forskellige målinger, og kun live-hastigheden har opløsning nok til at passe til en enkelt handling.

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

Tællere måler lag, ikke sider

På en WireGuard-peer er overførslstællerne i wg show totaler for den peer, inklusive krypteret payload. OpenVPN’s statusoutput rapporterer bytes pr. klient på sit eget lag. På værten tæller tun-interfacet indre IP-pakker, mens den fysiske adapter tæller ydre UDP-pakker, så de to adskiller sig med indkapslingsomkostninger og med alt andet, der deler linket.

Retransmissioner puster en total op uden at der ankommer nyt indhold, og en baggrundssynkronisering kan dominere en hel time, mens brugeren læser almindelig tekst.

Derfor antyder en stor total en datatung aktivitet og intet mere specifikt. En downloadet fils størrelse og tællerens delta hænger sammen, men de er sjældent lige store.

Hvad en total kan og ikke kan understøtte

En bytetotal kan ikke navngive et websted, fordi navne og URL’er lever inde i TLS- eller QUIC-sessioner, som tælleren aldrig inspicerer. Den kan ikke skelne en videostream fra en stor backup eller en sideindlæsning fra en reklameopdateringsløkke. Det, den kan understøtte, er en påstand om volumen og tid: denne enhed flyttede så mange data i dette vindue.

At gøre det til en påstand om en person kræver to ingredienser mere: en identitet og en korrelation.

Dokumentet RFC 6973 om privatlivsovervejelser forklarer, hvorfor den kombination betyder noget, og det er også derfor en omhyggelig rapport skelner mellem det, der blev observeret, og det, der blev udledt. Hvis konklusionen har brug for ordet fordi, er tælleren alene ikke bevis nok.

Timing og identitet ændrer svaret

Knyt en tæller til en navngivet bruger og et præcist interval, og den bliver et andet objekt.

Så kan du holde den op mod andre observationer: en loginregistrering, en DNS-forespørgsel, en session på et andet system. Tælleren afslørede ikke destinationen, men den hjalp nogen, der allerede havde en hypotese, med at bekræfte den. Kryptering beskytter indhold og navne undervejs, og den skjuler ikke, at der fandtes en strøm, hvor stor den var, eller hvornår den startede.

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

Beslut, hvad du opbevarer, før du indsamler

Hvis kravet er kapacitetsplanlægning, svarer et groft dagligt aggregat på det og koster lidt. Hvis kravet er historik pr. bruger, så sig det eksplicit, navngiv felterne og opbevaringsvinduet, og behandl beslutningen som politik snarere end som en dashboardfunktion. At indsamle finkornet historik, fordi panelet understøtter det, er måden, hvorpå opbevaring vokser, uden at nogen beslutter det.

Til fejlfinding kan du sammenligne tælleren med den handling, du tester. En jævnt stigende total beviser, at der flyder trafik, ikke at applikationen virker.

En flad tæller i en session, der tydeligt virker, betyder normalt, at du læser en cachet værdi eller det forkerte interface. Navngiv de opbevarede felter og vinduet, så har den næste revision noget konkret at kontrollere.