Du öppnar routerns trafiksida, eller en VPN-leverantörs instrumentpanel, och där finns en bytestotal per enhet med ett diagram bredvid. Det är frestande att läsa diagrammet som en surfhistorik. Det är det inte, och skälet är strukturellt snarare än juridiskt. En räknare summerar storlekar, medan en historik registrerar destinationer och innehåll, och bara det senare säger vart någon tog vägen.

Börja med skärmen du tittar på

Innan du tolkar en siffra, ta reda på vad som producerade den. En routers total per enhet kommer oftast från räknare på det fysiska gränssnittet, en VPN-klients total kommer från dess tunnel, och en leverantörspanel kommer från redovisningen hos motparten. Var och en räknar en annan del av samma session. Två paneler som visar olika siffror för samma timme har oftast båda rätt.

Intervallet spelar lika stor roll som källan. En livstidssumma, en daglig sammanställning och en aktuell hastighet är tre olika mätningar, och bara den aktuella hastigheten har upplösning nog att matcha en enskild handling.

Skriv ned källan och intervallet innan du skriver ned en slutsats.

Räknare mäter lager, inte sidor

På en WireGuard-peer är överföringsräknarna i wg show summor för den peeren, inklusive krypterad nyttolast. OpenVPN:s statusutdata rapporterar byte per klient på sitt eget lager. På värden räknar tun-gränssnittet inre IP-paket medan det fysiska nätverkskortet räknar yttre UDP-paket, så de två skiljer sig åt genom inkapslingsöverhead och genom allt annat som delar länken.

Omsändningar blåser upp en summa utan att något nytt innehåll anländer, och en synkronisering i bakgrunden kan dominera en timme medan användaren läser vanlig text.

Därför antyder en stor summa en datatung aktivitet och inget mer specifikt. Storleken på en nedladdad fil och räknarens delta hänger ihop, men de är sällan lika.

Vad en summa kan och inte kan styrka

En bytestotal kan inte namnge en webbplats, eftersom namn och URL:er lever inuti TLS- eller QUIC-sessioner som räknaren aldrig inspekterar. Den kan inte skilja en videoström från en stor säkerhetskopiering, eller en sidladdning från en upprepad annonsförfrågan. Det den kan styrka är ett påstående om volym och tid: den här enheten flyttade så här mycket data under det här fönstret.

Att göra det till ett påstående om en person kräver två ingredienser till, en identitet och en korrelation.

Dokumentet RFC 6973 privacy considerations förklarar varför den kombinationen spelar roll, och det är också därför en noggrann rapport skiljer det observerade från det slutledda. Om slutsatsen behöver ordet eftersom räcker inte räknaren som bevis.

Tidpunkt och identitet ändrar svaret

Koppla en räknare till en namngiven användare och ett exakt intervall, och den blir ett annat objekt.

Då kan du ställa den mot andra observationer: en inloggningspost, en DNS-fråga, en session på ett annat system. Räknaren avslöjade inte destinationen, men den hjälpte någon som redan hade en hypotes att bekräfta den. Kryptering skyddar innehåll och namn under transport, och den döljer inte att ett flöde fanns, hur stort det var eller när det började.

Det är den ärliga gränsen: mönster syns, betydelse gör det inte.

Bestäm vad du behåller innan du samlar in

Om kravet är kapacitetsplanering räcker ett grovt dagligt aggregat och det kostar lite. Om kravet är historik per användare, säg det uttryckligen, namnge fälten och lagringstiden, och behandla beslutet som policy i stället för som en instrumentpanelsfunktion. Att samla in finmaskig historik för att panelen stöder det är hur lagring växer utan att någon beslutar.

Vid felsökning, jämför räknaren med den handling du testar. En stadigt stigande summa bevisar att trafik flödar, inte att programmet fungerar.

En platt räknare under en session som uppenbart fungerar betyder oftast att du läser ett cachat värde eller fel gränssnitt. Namnge de sparade fälten och fönstret, så har nästa revision något konkret att kontrollera.

Relaterade artiklar