Åbn klientens statusvindue, og tallene ser beroligende ud: bytes stiger, tunnelen er forbundet. Luk vinduet, og kontorapplikationen fejler stadig, hvilket betyder, at tællerne svarede på et spørgsmål, ingen stillede. At tælle bytes på et interface måler trafik på netop det observationspunkt og intet mere. Gå fra det tal, du kigger på, til det lag, det rapporterer om, og videre til det resultat, applikationen faktisk gav dig.

Vælg interfacet, før du vælger tallet

Start der, hvor tallet vises, og læs etiketten ved siden af. Et klientvindue kan vise sessionstotaler, et tunnelinterface kan vise indre IP-bytes, og en fysisk adapter kan vise krypterede ydre bytes; tre forskellige tællere, som tilfældigvis måles i bytes. På kommandolinjen udskriver netstat -ibn én række for hver adresse på hvert interface, så en tunnel kan optræde flere gange. Match rækken med det interface, klienten faktisk ejer, og bekræft det mod den rute, destinationen vælger. En enhed med navnet utun kan tilhøre VPN'en, en anden tunnel eller noget, du ikke bekymrer dig om.

Skift ikke til en Wi-Fi-tæller, fordi den er lettere at læse. Et andet observationspunkt besvarer et andet spørgsmål.

Tag en forskel, ikke en samlet total

Læs rækken, lav én lille autoriseret anmodning, og læs så den samme række igen. Forskellen er beviset, for en samlet total omfatter alt, maskinen har gjort siden opstart. Hold intervallet kort, så baggrundstrafik har mindre chance for at forurene det. På en travl maskine kan nettop tilskrive gennemstrømning til en proces, hvilket indsnævrer feltet, før du vender tilbage til interface-tællere.

Accepter, at forskellen ikke er ren. Mail, opdateringer og klientens egne keepalives bidrager alle, så behandl tallet som en øvre grænse snarere end en måling. Hvis applikationen var det eneste, du gjorde i intervallet, er grænsen normalt stram nok til at være nyttig.

Indre og ydre tællere måler forskellige ting

Den fysiske adapter tæller krypterede pakker inklusive deres ydre headere, mens tunnelinterfacet bogfører den nyttelast, det modtager eller afleverer. At lægge de to sammen tæller én overførsel dobbelt. Overhead, genudsendelser og indkapsling gør også en simpel lighed umulig.

To tællere, der bevæger sig i modsatte retninger, er et fund, ikke en modsigelse. Det betyder normalt, at trafik gik ind i det ene lag og aldrig forlod det andet.

Par tælleren med appens resultat

En samlet modtaget mængde kan stige af protokolsnak, mens tjenesten, du ønskede, stadig fejler. En stigning i transmission siger endnu mindre: den beviser, at kernen accepterede en pakke, ikke at noget svarede.

Notér det præcise udfald ved siden af tællerne: navneopløsning fejlede, forbindelsen timede ud, TLS blev afvist, eller et HTTP-svar ankom. Det er fire forskellige fejl, og kun én af dem handler om tunnelen. Hvis beviset skal længere ud, er det næste observationspunkt gatewayen eller tjenestegrænsen, hvor nogen kan se, om anmodningen ankom. At nulstille Mac'ens netværksindstillinger ødelægger den tilstand, du målte, og fortæller dig intet.

Skriv noten, den næste person har brug for

Interfacenavn, tælleretikette, interval, værdier før og efter samt appens resultat. Det er nok til, at en kollega kan genskabe observationen uden at gentage din eftermiddag. Tilføj klientversionen og macOS-versionen, da tællersemantik kan ændre sig mellem udgivelser.

Spring den fulde pakkefangst og systemdumpet over. De er sjældent nødvendige for at forklare, hvilken lokal tæller der flyttede sig under én anmodning, og de forsinker alle, der læser rapporten. Hvis klienten viser sin egen statistik, citér dens etiket ordret i stedet for at oversætte den til din. Pointen med noten er at registrere, hvad der blev målt, ikke at diskutere, hvad det betyder.

Relaterede artikler