Pingtap på ein VPN: grupper Echo-førespurnader før prosenten

Eit opptak inneheld seks Echo-førespurnader og tre svar, og nokon skriv 50 prosent pakketap i saka. Talet kan vere sant for opptaket og usant for tunnelen. Dei seks førespurnadene kan høyre til to ulike samtalar med to ulike leveringskontraktar. Grupper dei før du deler, og tilhøvet sluttar å vere den interessante delen av rapporten.

Steg 1: skil straumane etter kjelde og mål

Ein Echo-førespurnad ber ei kjelde og eit mål, og desse to felta avgjer kva samtale han høyrer til. Eit probe som gatewayen genererer, brukar tunneladressa til gatewayen, medan eit probe som blir sendt vidare på vegner av ein LAN-vert, held på adressa til den verten. Den andre sida kan ha ein returrute for den eine og ikkje for den andre, noko som gjer at dei to gruppene oppfører seg ulikt av grunnar som ikkje har noko med tunnelen å gjere.

Del opptaket på desse felta før du tel noko, og hald på målet som ein del av nøkkelen. To straumar til ulike partar er ikkje samanliknbare sjølv når dei deler ei kjelde.

Skriv ned gruppene med tala deira, fordi neste steg avgjer kva svar som høyrer til kva gruppe. Ei gruppe med tre førespurnader og ingen samsvarande svar er eit funn. Ei gruppe med tre førespurnader og tre svar er ei grunnlinje.

Steg 2: match på identifikatoren og sekvensen

Echo-formatet i RFC 792 ber ein identifikator og eit sekvensnummer, og det behandlar dei som felta som parar eit svar med førespurnaden. Begge trengst for den jobben. Eit sekvensnummer åleine er ikkje unikt, sidan ulike sendarar eller prosessar kan bruke same verdi om att innanfor eitt opptaksvindauge. Identifikatoren snevrar inn sendaren og sekvensen posisjonen, og paret saman er det som gjer ein match forsvarleg.

Eit svar snur adresseretninga til førespurnaden, så ein match er eit førespurnad-svar-par og ikkje to identiske tuplar. Samanlikn kjelda til førespurnaden med målet til svaret og målet til førespurnaden med kjelda til svaret, og stadfest deretter at identifikatoren og sekvensen stemmer.

Hald òg på observasjonsvindauget, fordi eit langt opptak kan innehalde legitim gjenbruk av begge felta. Å kutte vindauget til éin utblåsing fjernar det meste av denne uklarleiken. Det gjer òg tala reproduserbare for alle som les saka.

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: samanlikn tuplar på same grense

Viss nettverksadresseomsetjing ligg mellom opptakspunktet og parten, vil adressene i førespurnaden og svaret skilje seg ved design. Samanlikn tuplane på éi grense, eller ber mappinga eksplisitt slik at skilnaden blir rekna med. Å blande førespurnader før omsetjing med svar etter omsetjing finn opp avvik som aldri fanst på leidningen.

Avgjer grensa før du byrjar å telje, og oppgje ho i rapporten slik at neste person kan reprodusere grupperinga. Eitt opptak på klientsida og eit anna på serversida er to ulike grenser. Kvar av dei svarar på eit ulikt spørsmål om kvar svaret forsvann.

Ei gruppe omsette probar arvar òg den eigne tilstanden til omsetjingseininga, som kan vere den verkelege grunnen til at eit svar aldri kjem. Kontroller den tilstanden før du klandrar vegen bak han.

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: sei kva opptaket kan og ikkje kan bevise

Eit observert hol beviser ikkje at den fjerne verten var taus. Opptakspunktet ser kanskje berre éi retning, eit filter kan droppe svaret, eller bufferen kan ha gått over i vindauget. Kvar av dei gir same fråvær og ein annan konklusjon.

Noter opptaksstaden, filteruttrykket og dropptellarane ved sida av tala, fordi eit tilhøve utan dei ikkje kan reviderast. Det er dei tre linjene som gjer talet forsvarleg seinare.

Skil deretter kva observasjonen fastslår frå kva han antyder, i to setningar i staden for éi. Den første setninga oppgir tala og grensa. Den andre oppgir hypotesen og kva som ville stadfeste han.

Når spørsmålet er om ein bestemt veg droppar pakkar, er eit kontrollert probe med ei eksplisitt kjeldeadresse sterkare bevis enn ei passiv teljing av blanda trafikk. Send det frå same maskin, på same tid, til same part. Endre éin variabel, og samanlikninga held.

Rapporter gruppene og neste grense

Rapporten har tre linjer: gruppedefinisjonen, dei matcha tala i kvar gruppe og grensa der samanlikninga vart gjord. Då kan lesaren sjå at éi gruppe svara fullstendig og ei anna ikkje, noko som peikar på ein rute eller ei løyve i staden for tilfeldig tap.

Legg ved opptaksfila og filteruttrykka slik at grupperinga kan reproduserast. Eit samandrag utan fila er ein påstand, ikkje eit 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 éi gruppe viser fem svar og den andre ingen, er funnet at éi kjelde har ein fungerande returveg og den andre ikkje. Det er ei mykje betre sak enn ein blanda prosent, og det rettar neste kontroll mot returruta i staden for mot ein urelatert VPN-førekomst.