Hva en byteteller i en Mac-VPN beviser og ikke beviser

Åpne statusvinduet til klienten, og tallene ser betryggende ut: byte går opp, tunnelen er tilkoblet. Lukk vinduet, og kontorapplikasjonen feiler fortsatt, som betyr at tellerne svarte på et spørsmål ingen stilte. Å telle byte på et grensesnitt måler trafikk på nettopp det observasjonspunktet og ikke noe mer. Gå fra tallet du ser på til laget det rapporterer om, og videre til resultatet applikasjonen faktisk ga deg.

Velg grensesnittet før du velger tallet

Start der tallet vises, og les etiketten ved siden av. Et klientvindu kan vise sesjonstotaler, et tunellgrensesnitt kan vise indre IP-byte, og en fysisk adapter kan vise krypterte ytre byte; tre forskjellige tellere som tilfeldigvis måles i byte. På kommandolinjen skriver netstat -ibn ut én rad per adresse på hvert grensesnitt, så en tunnel kan dukke opp flere ganger. Koble raden til grensesnittet klienten faktisk eier, og bekreft det mot ruten destinasjonen velger. En enhet som heter utun kan tilhøre VPN-en, en annen tunnel eller noe du ikke bryr deg om.

Ikke bytt til en Wi-Fi-teller bare fordi den er lettere å lese. Et annet observasjonspunkt svarer på et annet spørsmål.

Ta en differanse, ikke en total siden oppstart

Les raden, gjør én liten autorisert forespørsel, og les deretter samme rad igjen. Differansen er beviset, fordi en total siden oppstart omfatter alt maskinen har gjort. Hold intervallet kort slik at bakgrunnstrafikk har mindre sjanse til å forurense det. På en travel maskin kan nettop tilskrive gjennomstrømning til en prosess, noe som snevrer inn feltet før du går tilbake til grensesnittstellerne.

Aksepter at differansen ikke er ren. E-post, oppdateringer og klientens egne keepalives bidrar alle, så behandl tallet som en øvre grense og ikke som en måling. Hvis applikasjonen var det eneste du gjorde i intervallet, er grensen vanligvis stram nok til å være nyttig.

Indre og ytre tellere måler forskjellige ting

Den fysiske adapteren teller krypterte pakker inkludert deres ytre headere, mens tunellgrensesnittet regner med nyttelasten det mottar eller leverer. Å legge de to sammen teller én overføring dobbelt. Overhead, retransmisjoner og innkapsling gjør også en enkel likhet umulig.

To tellere som beveger seg i motsatte retninger er et funn, ikke en motsetning. Det betyr vanligvis at trafikk gikk inn i ett lag og aldri forlot det andre.

Koble telleren til resultatet applikasjonen ga

En mottatt total kan stige av protokollprat mens tjenesten du ønsket fortsatt feiler. En økning i sending sier enda mindre: den beviser at kjernen godtok en pakke, ikke at noe svarte.

Noter det nøyaktige utfallet ved siden av tellerne: navneoppslag feilet, tilkoblingen timet ut, TLS ble avvist, eller et HTTP-svar ankom. Det er fire forskjellige feil, og bare én av dem handler om tunnelen. Hvis beviset må gå lenger, er neste observasjonspunkt gatewayen eller tjenestegrensen, der noen kan se om forespørselen ankom. Å tilbakestille nettverksinnstillingene på Mac ødelegger tilstanden du målte og forteller deg ingenting.

Skriv notatet den neste personen trenger

Grensesnittnavn, telleretikett, intervall, verdier før og etter, og resultatet applikasjonen ga. Det er nok for en kollega å gjenskape observasjonen uten å gjenta ettermiddagen din. Legg til klientversjonen og macOS-versjonen, siden tellersemantikken kan endre seg mellom utgivelser.

Hopp over full pakkefangst og systemdump. De er sjelden nødvendige for å forklare hvilken lokal teller som flyttet seg under én forespørsel, og de bremser alle som leser rapporten. Hvis klienten viser sin egen statistikk, siter etiketten ordrett i stedet for å oversette den til din. Poenget med notatet er å registrere hva som ble målt, ikke å diskutere hva det betyr.