Pingförlust på en VPN: gruppera Echo-förfrågningar före procenten

En inspelning innehåller sex Echo-förfrågningar och tre svar, och någon skriver 50 procents paketförlust i ärendet. Talet kan vara sant för inspelningen och falskt för tunneln. De sex förfrågningarna kan tillhöra två olika samtal med två olika leveransavtal. Gruppera dem innan du delar, och förhållandet slutar vara den intressanta delen av rapporten.

Steg 1: dela upp strömmarna efter källa och destination

En Echo-förfrågan bär en källa och en destination, och dessa två fält avgör vilket samtal den hör till. En probe som gatewayen genererar använder gatewayens tunneladress, medan en probe som vidarebefordras på uppdrag av en LAN-värd behåller den värdens adress. Den andra sidan kan ha en returväg för den ena men inte för den andra, vilket gör att de två grupperna beter sig olika av skäl som inte har något med tunneln att göra.

Dela upp inspelningen på dessa fält innan du räknar något, och behåll destinationen som en del av nyckeln. Två strömmar till olika parter är inte jämförbara även när de delar en källa.

Skriv ned grupperna med deras antal, eftersom nästa steg avgör vilka svar som hör till vilken grupp. En grupp med tre förfrågningar och inget matchande svar är ett fynd. En grupp med tre förfrågningar och tre svar är en baslinje.

Steg 2: matcha på identifieraren och sekvensen

Echo-formatet i RFC 792 bär en identifierare och ett sekvensnummer, och det behandlar dem som fälten som parar ett svar med dess förfrågan. Båda behövs för det arbetet. Ett sekvensnummer ensamt är inte unikt, eftersom olika avsändare eller processer kan återanvända samma värde inom ett inspelningsfönster. Identifieraren snävar in avsändaren och sekvensen positionen, och paret tillsammans är det som gör en matchning försvarbar.

Ett svar vänder adressriktningen för sin förfrågan, så en matchning är ett förfrågan-svar-par och inte två identiska tupler. Jämför förfrågans källa med svarets destination och förfrågans destination med svarets källa, och bekräfta sedan att identifieraren och sekvensen stämmer.

Behåll också observationsfönstret, eftersom en lång inspelning kan innehålla legitim återanvändning av båda fälten. Att klippa fönstret till en enda burst tar bort det mesta av den otydligheten. Det gör också antalen reproducerbara för alla som läser ärendet.

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

Steg 3: jämför tupler på samma gräns

Om nätverksadressöversättning ligger mellan inspelningspunkten och parten kommer adresserna i förfrågan och svaret att skilja sig av design. Jämför tuplarna på en enda gräns, eller bär mappningen explicit så att skillnaden räknas in. Att blanda förfrågningar före översättning med svar efter översättning hittar på avvikelser som aldrig funnits på ledningen.

Bestäm gränsen innan du börjar räkna, och ange den i rapporten så att nästa person kan återskapa grupperingen. En inspelning på klientsidan och en annan på serversidan är två olika gränser. Var och en svarar på en annan fråga om var svaret försvann.

En grupp översatta prober ärver också översättningsenhetens eget tillstånd, vilket kan vara den verkliga orsaken till att ett svar aldrig kommer fram. Kontrollera det tillståndet innan du skyller på vägen bortom den.

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

Steg 4: säg vad inspelningen kan och inte kan bevisa

En observerad lucka bevisar inte att den avlägsna värden förblev tyst. Inspelningspunkten kanske bara ser en riktning, ett filter kan släppa svaret, eller bufferten kan ha svämmat över under fönstret. Var och en av dem ger samma frånvaro och en annan slutsats.

Anteckna inspelningsplatsen, filteruttrycket och droppräknarna bredvid antalen, eftersom ett förhållande utan dem inte kan granskas. Det är de tre raderna som gör talet försvarbart senare.

Separera sedan vad observationen fastställer från vad den antyder, i två meningar i stället för en. Den första meningen anger antalen och gränsen. Den andra anger hypotesen och vad som skulle bekräfta den.

När frågan är om en viss väg släpper paket är en kontrollerad probe med en explicit källadress starkare bevis än en passiv räkning av blandad trafik. Skicka den från samma maskin, vid samma tidpunkt, till samma part. Ändra en variabel och jämförelsen håller.

Rapportera grupperna och nästa gräns

Rapporten har tre rader: gruppdefinitionen, de matchade antalen inom varje grupp och gränsen där jämförelsen gjordes. Då kan läsaren se att en grupp svarade fullständigt och en annan inte, vilket pekar på en rutt eller en behörighet snarare än slumpmässig förlust.

Bifoga inspelningsfilen och filteruttrycken så att grupperingen kan återskapas. En sammanfattning utan filen är ett påstående, inte ett resultat.

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

När en grupp visar fem svar och den andra inget, är fyndet att en källa har en fungerande returväg och den andra inte. Det är ett mycket bättre ärende än en blandad procent, och det riktar nästa kontroll mot returvägen i stället för mot en orelaterad VPN-instans.