Vad en byteräknare i en Mac-VPN bevisar och inte bevisar

Öppna klientens statusfönster och siffrorna ser lugnande ut: byte ökar, tunneln är ansluten. Stäng fönstret och kontorsapplikationen misslyckas fortfarande, vilket betyder att räknarna svarade på en fråga som ingen ställde. Att räkna byte på ett gränssnitt mäter trafik vid just den observationspunkten och inget mer. Gå från siffran du tittar på till lagret den rapporterar om, och vidare till resultatet applikationen faktiskt gav dig.

Välj gränssnittet innan du väljer siffran

Börja där siffran visas och läs etiketten bredvid. Ett klientfönster kan visa sessionstotaler, ett tunnelgränssnitt kan visa inre IP-byte och en fysisk adapter kan visa krypterade yttre byte; tre olika räknare som råkar uttryckas i byte. På kommandoraden skriver netstat -ibn ut en rad per adress på varje gränssnitt, så en tunnel kan förekomma flera gånger. Matcha raden mot det gränssnitt som klienten faktiskt äger och bekräfta det mot den rutt som destinationen väljer. En enhet som heter utun kan tillhöra VPN:en, en annan tunnel eller något du inte bryr dig om.

Byt inte till en Wi-Fi-räknare bara för att den är lättare att läsa. En annan observationspunkt svarar på en annan fråga.

Ta en differens, inte en total sedan starten

Läs raden, gör en liten auktoriserad begäran och läs sedan samma rad igen. Differensen är beviset, eftersom en total sedan starten omfattar allt maskinen har gjort. Håll intervallet kort så att bakgrundstrafik har mindre chans att förorena det. På en upptagen maskin kan nettop tillskriva genomströmning till en process, vilket snävar in fältet innan du återvänder till gränssnittsräknarna.

Acceptera att differensen inte är ren. E-post, uppdateringar och klientens egna keepalive-meddelanden bidrar alla, så behandla siffran som en övre gräns och inte som en mätning. Om applikationen var det enda du gjorde under intervallet är gränsen vanligtvis tillräckligt tight för att vara användbar.

Inre och yttre räknare mäter olika saker

Den fysiska adaptern räknar krypterade paket inklusive deras yttre rubriker, medan tunnelgränssnittet redovisar den nyttolast det tar emot eller lämnar. Att lägga ihop de två räknar en överföring dubbelt. Overhead, omsändningar och inkapsling gör också en enkel likhet omöjlig.

Två räknare som rör sig i motsatta riktningar är ett fynd, inte en motsägelse. Det betyder vanligtvis att trafik gick in i ett lager och aldrig lämnade det andra.

Koppla räknaren till appens resultat

En mottagen total kan stiga av protokollprat medan tjänsten du ville ha fortfarande misslyckas. En ökning i sändning säger ännu mindre: den bevisar att kärnan accepterade ett paket, inte att något svarade.

Anteckna det exakta utfallet bredvid räknarna: namnuppslagningen misslyckades, anslutningen tog timeout, TLS avvisades eller ett HTTP-svar anlände. Det är fyra olika fel och bara ett av dem handlar om tunneln. Om beviset måste gå längre är nästa observationspunkt gatewayen eller tjänstegränsen, där någon kan se om begäran kom fram. Att återställa Macens nätverksinställningar förstör det tillstånd du mätte och säger dig ingenting.

Skriv anteckningen som nästa person behöver

Gränssnittsnamn, räknaretikett, intervall, värden före och efter samt applikationens resultat. Det räcker för en kollega att återskapa observationen utan att upprepa din eftermiddag. Lägg till klientversionen och macOS-versionen, eftersom räknarnas semantik kan ändras mellan utgåvor.

Hoppa över full paketinsamling och systemdump. De behövs sällan för att förklara vilken lokal räknare som flyttade sig under en begäran, och de saktar ner alla som läser rapporten. Om klienten visar sin egen statistik, citera dess etikett ordagrant i stället för att översätta den till din. Poängen med anteckningen är att registrera vad som mättes, inte att diskutera vad det betyder.