Pingverlies op 'n VPN: groepeer Echo-versoeke voordat jy die persentasie bereken

'n Opname bevat ses Echo-versoeke en drie antwoorde, en iemand skryf 50 persent pakkieverlies in die kaartjie. Daardie syfer kan waar wees vir die opname en onwaar vir die tonnel. Die ses versoeke kan aan twee verskillende gesprekke met twee verskillende afleweringskontrakte behoort. Groepeer hulle voordat jy deel, en die verhouding hou op om die interessante deel van die verslag te wees.

Stap 1: skei die strome volgens bron en bestemming

'n Echo-versoek dra 'n bron en 'n bestemming, en daardie twee velde bepaal aan watter gesprek dit behoort. 'n Peiling wat deur die gateway gegenereer word, gebruik die gateway se tonneladres, terwyl 'n peiling wat namens 'n LAN-gasheer gestuur word, daardie gasheer se adres behou. Die ander kant kan 'n retourroete vir die een hê en nie vir die ander nie, wat die twee groepe anders laat optree om redes wat niks met die tonnel te doen het nie.

Skei die opname op daardie velde voordat jy enigiets tel, en hou die bestemming as deel van die sleutel. Twee strome na verskillende eweknieë is nie vergelykbaar nie, selfs wanneer hulle 'n bron deel.

Skryf die groepe met hul tellings neer, want die volgende stap besluit watter antwoorde aan watter groep behoort. 'n Groep met drie versoeke en geen ooreenstemmende antwoord is 'n bevinding. 'n Groep met drie versoeke en drie antwoorde is 'n basislyn.

Stap 2: pas op die identifiseerder en die volgorde

Die Echo-formaat in RFC 792 dra 'n identifiseerder en 'n volgordenommer, en dit behandel hulle as die velde wat 'n antwoord met sy versoek paar. Beide is vir daardie taak nodig. 'n Volgordenommer alleen is nie uniek nie, want verskillende senders of prosesse kan dieselfde waarde binne een opnamevenster hergebruik. Die identifiseerder vernou die sender en die volgorde vernou die posisie, en die paar saam is wat 'n passing verdedigbaar maak.

'n Antwoord keer die adresrigting van sy versoek om, so 'n passing is 'n versoek-antwoord-paar eerder as twee identiese tupels. Vergelyk die versoek se bron met die antwoord se bestemming en die versoek se bestemming met die antwoord se bron, en bevestig dan dat die identifiseerder en volgorde ooreenstem.

Behou ook die waarnemingsvenster, want 'n lang opname kan wettige hergebruik van beide velde bevat. Om die venster tot een sarsie te snoei, verwyder die meeste van daardie dubbelsinnigheid. Dit maak ook die tellings herproduseerbaar vir elkeen wat die kaartjie lees.

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

Stap 3: vergelyk tupels by dieselfde grens

As netwerkadresvertaling tussen die opnamepunt en die eweknie sit, sal die adresse in die versoek en die antwoord per ontwerp verskil. Vergelyk die tupels by een grens, of dra die kartering eksplisiet sodat die verskil verreken word. Om versoeke voor vertaling met antwoorde ná vertaling te meng, skep wanpassings wat nooit op die draad bestaan het nie.

Besluit die grens voordat jy begin tel, en noem dit in die verslag sodat die volgende persoon die groepering kan herproduseer. Een opname aan die kliëntkant en 'n ander aan die bedienerkant is twee verskillende grense. Elkeen beantwoord 'n ander vraag oor waar die antwoord verdwyn het.

'n Groep vertaalde peilings erf ook die vertaaltoestel se eie toestand, wat die werklike rede kan wees waarom 'n antwoord nooit aankom nie. Kontroleer daardie toestand voordat jy die pad anderkant blameer.

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

Stap 4: sê wat die opname kan en nie kan bewys nie

'n Waargenome gaping bewys nie dat die verre gasheer stilgebly het nie. Die opnamepunt kan net een rigting sien, 'n filter kan die antwoord laat val, of die buffer kan tydens die venster oorstroom het. Elkeen van dié lewer dieselfde afwesigheid en 'n ander gevolgtrekking.

Teken die opnameligging, die filteruitdrukking en die verwerp-tellers saam met die tellings aan, want 'n verhouding sonder hulle kan nie geouditeer word nie. Daardie drie reëls is wat die syfer later verdedigbaar maak.

Skei dan wat die waarneming vestig van wat dit voorstel, in twee sinne eerder as een. Die eerste sin noem die tellings en die grens. Die tweede noem die hipotese en wat dit sou bevestig.

Waar die vraag is of 'n spesifieke pad pakkies laat val, is 'n beheerde peiling met 'n eksplisiete bronadres sterker bewyse as 'n passiewe telling van gemengde verkeer. Stuur dit van dieselfde masjien, op dieselfde tyd, na dieselfde eweknie. Verander een veranderlike en die vergelyking hou stand.

Rapporteer die groepe en die volgende grens

Die verslag het drie reëls: die groepsdefinisie, die gepaarde tellings binne elke groep, en die grens waar die vergelyking gemaak is. 'n Leser kan dan sien dat een groep volledig geantwoord het en 'n ander nie, wat na 'n roete of 'n toestemming wys eerder as na toevallige verlies.

Heg die opnamelêer en die filteruitdrukkings aan sodat die groepering herproduseer kan word. 'n Opsomming sonder die lêer is 'n bewering eerder as 'n resultaat.

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

Wanneer een groep vyf antwoorde toon en die ander geen, is die bevinding dat een bron 'n werkende retourpad het en die ander nie. Dit is 'n veel beter kaartjie as 'n gemengde persentasie, en dit wys die volgende kontrole na die retourroete eerder as na 'n onverwante VPN-instansie.