Pingtap på en VPN: grupper Echo-forespørsler før prosenten

En opptak inneholder seks Echo-forespørsler og tre svar, og noen skriver 50 prosent pakketap i saken. Tallet kan være sant for opptaket og usant for tunnelen. De seks forespørslene kan tilhøre to forskjellige samtaler med to forskjellige leveringskontrakter. Grupper dem før du deler, og forholdet slutter å være den interessante delen av rapporten.

Trinn 1: skill strømmene etter kilde og destinasjon

En Echo-forespørsel bærer en kilde og en destinasjon, og disse to feltene avgjør hvilken samtale den hører til. En probe som gatewayen genererer, bruker gatewayens tunneladresse, mens en probe som videresendes på vegne av en LAN-vert, beholder den vertens adresse. Den andre siden kan ha en returrute for den ene og ikke for den andre, noe som gjør at de to gruppene oppfører seg forskjellig av grunner som ikke har noe med tunnelen å gjøre.

Del opptaket på disse feltene før du teller noe, og behold destinasjonen som en del av nøkkelen. To strømmer til forskjellige parter er ikke sammenlignbare selv når de deler en kilde.

Skriv ned gruppene med antallene deres, fordi neste trinn avgjør hvilke svar som hører til hvilken gruppe. En gruppe med tre forespørsler og ingen samsvarende svar er et funn. En gruppe med tre forespørsler og tre svar er en grunnlinje.

Trinn 2: match på identifikatoren og sekvensen

Echo-formatet i RFC 792 bærer en identifikator og et sekvensnummer, og det behandler dem som feltene som parer et svar med forespørselen. Begge trengs for den jobben. Et sekvensnummer alene er ikke unikt, siden forskjellige sendere eller prosesser kan gjenbruke samme verdi innenfor ett opptaksvindu. Identifikatoren snevrer inn senderen og sekvensen posisjonen, og paret sammen er det som gjør en match forsvarlig.

Et svar reverserer adresseretningen til forespørselen, så en match er et forespørsel-svar-par og ikke to identiske tupler. Sammenlign forespørselens kilde med svarets destinasjon og forespørselens destinasjon med svarets kilde, og bekreft deretter at identifikatoren og sekvensen stemmer.

Behold også observasjonsvinduet, fordi et langt opptak kan inneholde legitim gjenbruk av begge feltene. Å kutte vinduet til én utblåsning fjerner det meste av denne uklarheten. Det gjør også antallene reproduserbare for alle som leser saken.

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

Trinn 3: sammenlign tupler på samme grense

Hvis nettverksadresseoversettelse ligger mellom opptakspunktet og parten, vil adressene i forespørselen og svaret avvike ved design. Sammenlign tuplene på én grense, eller bær mappingen eksplisitt slik at forskjellen blir regnet med. Å blande forespørsler før oversettelse med svar etter oversettelse finner opp avvik som aldri fantes på ledningen.

Bestem grensen før du begynner å telle, og oppgi den i rapporten slik at neste person kan reprodusere grupperingen. Ett opptak på klientsiden og et annet på serversiden er to forskjellige grenser. Hver av dem svarer på et forskjellig spørsmål om hvor svaret forsvant.

En gruppe oversatte prober arver også oversettelsesenhetens egen tilstand, som kan være den egentlige grunnen til at et svar aldri kommer. Kontroller den tilstanden før du klandrer veien bak 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

Trinn 4: si hva opptaket kan og ikke kan bevise

Et observert hull beviser ikke at den fjerne verten forble taus. Opptakspunktet ser kanskje bare én retning, et filter kan droppe svaret, eller bufferen kan ha gått over i vinduet. Hver av dem gir samme fravær og en annen konklusjon.

Noter opptaksstedet, filteruttrykket og dropptellerne ved siden av antallene, fordi et forhold uten dem ikke kan revideres. Det er de tre linjene som gjør tallet forsvarlig senere.

Skill deretter hva observasjonen fastslår fra hva den antyder, i to setninger i stedet for én. Den første setningen oppgir antallene og grensen. Den andre oppgir hypotesen og hva som ville bekrefte den.

Når spørsmålet er om en bestemt vei dropper pakker, er en kontrollert probe med en eksplisitt kildeadresse sterkere bevis enn en passiv telling av blandet trafikk. Send den fra samme maskin, på samme tid, til samme part. Endre én variabel, og sammenligningen holder.

Rapporter gruppene og neste grense

Rapporten har tre linjer: gruppedefinisjonen, de matchede antallene i hver gruppe og grensen der sammenligningen ble gjort. Da kan leseren se at én gruppe svarte fullstendig og en annen ikke, noe som peker på en rute eller en tillatelse i stedet for tilfeldig tap.

Legg ved opptaksfilen og filteruttrykkene slik at grupperingen kan reproduseres. Et sammendrag uten 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 andre ingen, er funnet at én kilde har en fungerende returvei og den andre ikke. Det er en mye bedre sak enn en blandet prosent, og det retter neste kontroll mot returruten i stedet for mot en urelatert VPN-forekomst.