Pingtab på en VPN: gruppér Echo-anmodninger før procenten

En optagelse indeholder seks Echo-anmodninger og tre svar, og nogen skriver 50 procent pakketab i billetten. Det tal kan være sandt for optagelsen og falskt for tunnelen. De seks anmodninger kan tilhøre to forskellige samtaler med to forskellige leveringskontrakter. Gruppér dem, før du dividerer, og forholdet holder op med at være den interessante del af rapporten.

Trin 1: opdel strømmene efter kilde og destination

En Echo-anmodning bærer en kilde og en destination, og de to felter afgør, hvilken samtale den hører til. En probe, som gatewayen genererer, bruger gatewayens tunneladresse, mens en probe, der videresendes på vegne af en LAN-vært, beholder denne værters adresse. Den anden side kan have en returrute for den ene og ikke for den anden, hvilket får de to grupper til at opføre sig forskelligt af grunde, der intet har med tunnelen at gøre.

Opdel optagelsen på de felter, før du tæller noget, og behold destinationen som en del af nøglen. To strømme til forskellige peers kan ikke sammenlignes, selv når de deler en kilde.

Skriv grupperne ned med deres antal, fordi næste trin afgør, hvilke svar der hører til hvilken gruppe. En gruppe med tre anmodninger og intet matchende svar er et fund. En gruppe med tre anmodninger og tre svar er en baseline.

Trin 2: match på identifikatoren og sekvensen

Echo-formatet i RFC 792 bærer en identifikator og et sekvensnummer og behandler dem som de felter, der parrer et svar med dets anmodning. Begge er nødvendige for den opgave. Et sekvensnummer alene er ikke unikt, da forskellige afsendere eller processer kan genbruge den samme værdi inden for ét optagelsesvindue. Identifikatoren indsnævrer afsenderen, og sekvensen indsnævrer positionen, og parret sammen er det, der gør et match forsvarligt.

Et svar vender adresseretningen af sin anmodning, så et match er et anmodnings-svar-par og ikke to identiske tupler. Sammenlign anmodningens kilde med svarets destination og anmodningens destination med svarets kilde, og bekræft derefter, at identifikatoren og sekvensen stemmer overens.

Behold også observationsvinduet, fordi en lang optagelse kan indeholde legitim genbrug af begge felter. At skære vinduet ned til ét burst fjerner det meste af den uklarhed. Det gør også antallene reproducerbare for alle, der læser billetten.

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

Trin 3: sammenlign tupler på samme grænse

Hvis netværksadresseoversættelse ligger mellem optagelsespunktet og peeren, vil adresserne i anmodningen og svaret afvige med vilje. Sammenlign tuplerne på én grænse, eller bær mappingen eksplicit, så forskellen bliver regnet med. At blande anmodninger før oversættelse med svar efter oversættelse opfinder uoverensstemmelser, der aldrig fandtes på ledningen.

Beslut grænsen, før du begynder at tælle, og angiv den i rapporten, så den næste person kan reproducere grupperingen. Én optagelse på klientsiden og en anden på serversiden er to forskellige grænser. Hver især besvarer de et forskelligt spørgsmål om, hvor svaret forsvandt hen.

En gruppe oversatte prober arver også oversættelsesenhedens egen tilstand, som kan være den egentlige grund til, at et svar aldrig ankommer. Kontrollér den tilstand, før du bebrejder vejen bag 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

Trin 4: sig, hvad optagelsen kan og ikke kan bevise

Et observeret hul godtgør ikke, at den fjerne vært forholdt sig tavs. Optagelsespunktet ser måske kun én retning, et filter kan droppe svaret, eller bufferen kan være løbet over i vinduet. Hver af dem giver den samme mangel og en forskellig konklusion.

Notér optagelsesstedet, filterudtrykket og drop-tællerne sammen med antallene, fordi et forhold uden dem ikke kan revideres. Det er de tre linjer, der gør tallet forsvarligt senere.

Adskil derefter, hvad observationen fastslår, fra hvad den antyder, i to sætninger i stedet for én. Den første sætning angiver antallene og grænsen. Den anden angiver hypotesen og hvad der ville bekræfte den.

Når spørgsmålet er, om en bestemt vej dropper pakker, er en kontrolleret probe med en eksplicit kildeadresse stærkere bevis end en passiv optælling af blandet trafik. Send den fra den samme maskine, på det samme tidspunkt, til den samme peer. Ændr én variabel, og sammenligningen holder.

Rapportér grupperne og den næste grænse

Rapporten har tre linjer: gruppedefinitionen, de matchede antal i hver gruppe og den grænse, hvor sammenligningen blev foretaget. Så kan læseren se, at én gruppe svarede fuldstændigt og en anden ikke, hvilket peger på en rute eller en tilladelse frem for på tilfældigt tab.

Vedlæg optagelsesfilen og filterudtrykkene, så grupperingen kan genskabes. Et resumé uden filen er en påstand, ikke et 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 én gruppe viser fem svar og den anden ingen, er fundet, at én kilde har en fungerende returvej og den anden ikke. Det er en meget bedre billet end en blandet procentdel, og den peger den næste kontrol mod returruten i stedet for mod en urelateret VPN-instans.