Ping-perdo en VPN: grupigu Echo-petojn antaŭ la procento

Kaptaĵo enhavas ses Echo-petojn kaj tri respondojn, kaj iu skribas 50 procentan pakaĵperdon en la bileto. Tiu nombro povas esti vera por la kaptaĵo kaj malvera por la tunelo. La ses petoj eble apartenas al du malsamaj konversacioj kun du malsamaj liverkontraktoj. Grupigu ilin antaŭ ol dividi, kaj la proporcio ĉesas esti la interesa parto de la raporto.

Paŝo 1: apartigu la fluojn laŭ fonto kaj celo

Echo-peto portas fonton kaj celon, kaj tiuj du kampoj difinas al kiu konversacio ĝi apartenas. Sondilo generita de la pordego uzas la tunelan adreson de la pordego, dum sondilo plusendita nome de LAN-gastiganto konservas la adreson de tiu gastiganto. La malproksima flanko povas havi revenan itineron por unu kaj ne por la alia, kio igas la du grupojn konduti malsame pro kialoj tute ne rilataj al la tunelo.

Dividu la kaptaĵon laŭ tiuj kampoj antaŭ ol ion ajn kalkuli, kaj konservu la celon kiel parton de la ŝlosilo. Du fluoj al malsamaj kunuloj ne estas kompareblaj eĉ kiam ili dividas fonton.

Skribu la grupojn kun iliaj nombroj, ĉar la sekva paŝo decidas kiuj respondoj apartenas al kiu grupo. Grupo kun tri petoj kaj neniu kongrua respondo estas trovaĵo. Grupo kun tri petoj kaj tri respondoj estas bazlinio.

Paŝo 2: kongruigu laŭ la identigilo kaj la sinsekvo

La Echo-formato en RFC 792 portas identigilon kaj sinsekvan numeron, kaj traktas ilin kiel la kampojn, kiuj parigas respondon kun ĝia peto. Ambaŭ necesas por tiu tasko. Sinsekva numero sola ne estas unika, ĉar malsamaj sendintoj aŭ procezoj povas reuzi la saman valoron ene de unu kapta fenestro. La identigilo mallarĝigas la sendinton kaj la sinsekvo la pozicion, kaj la paro kune estas tio, kio faras kongruon defendebla.

Respondo inversigas la adresdirekton de sia peto, do kongruo estas peto-responda paro, ne du identaj opoj. Komparu la fonton de la peto kun la celo de la respondo kaj la celon de la peto kun la fonto de la respondo, poste konfirmu, ke la identigilo kaj la sinsekvo kongruas.

Konservu ankaŭ la observfenestron, ĉar longa kaptaĵo povas enhavi laŭleĝan reuzon de ambaŭ kampoj. Tranĉi la fenestron al unu rafalo forigas la plej grandan parton de tiu malklareco. Ĝi ankaŭ faras la nombrojn reprodukteblaj por iu ajn, kiu legas la bileton.

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

Paŝo 3: komparu opojn ĉe la sama limo

Se retadresa tradukado situas inter la kapta punkto kaj la kunulo, la adresoj en la peto kaj la respondo malsamos laŭdezajne. Komparu la opojn ĉe unu limo, aŭ portu la mapadon eksplicite, por ke la diferenco estu kalkulita. Miksi petojn antaŭ tradukado kun respondoj post tradukado elpensas malkongruojn, kiuj neniam ekzistis sur la drato.

Decidu la limon antaŭ ol vi komencos kalkuli, kaj deklaru ĝin en la raporto, por ke la sekva persono povu reprodukti la grupigon. Unu kaptaĵo ĉe la klienta flanko kaj alia ĉe la servila flanko estas du malsamaj limoj. Ĉiu respondas al malsama demando pri tio, kie la respondo malaperis.

Grupo de tradukitaj sondiloj ankaŭ heredas la propran staton de la traduka aparato, kio povas esti la reala kialo, ke respondo neniam alvenas. Kontrolu tiun staton antaŭ ol kulpi la vojon preter ĝi.

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

Paŝo 4: diru, kion la kaptaĵo povas kaj ne povas pruvi

Observita breĉo ne pruvas, ke la malproksima gastiganto restis silenta. La kapta punkto eble vidas nur unu direkton, filtrilo eble faligas la respondon, aŭ la bufro eble superfluis dum la fenestro. Ĉiu el tiuj produktas la saman foreston kaj malsaman konkludon.

Notu la kaptan lokon, la filtrilan esprimon kaj la faligajn nombrilojn apud la nombroj, ĉar proporcio sen ili ne povas esti reviziata. Tiuj tri linioj estas tio, kio faras la nombron defendebla poste.

Poste apartigu, kion la observado establas, de kion ĝi sugestas, en du frazoj anstataŭ unu. La unua frazo deklaras la nombrojn kaj la limon. La dua deklaras la hipotezon kaj kio konfirmus ĝin.

Kiam la demando estas, ĉu difinita vojo faligas pakaĵojn, kontrolita sondilo kun eksplicita fontadreso estas pli forta pruvo ol pasiva kalkulo de miksita trafiko. Sendu ĝin de la sama maŝino, en la sama tempo, al la sama kunulo. Ŝanĝu unu variablon kaj la komparo validas.

Raportu la grupojn kaj la sekvan limon

La raporto havas tri liniojn: la grupan difinon, la kongruitajn nombrojn ene de ĉiu grupo, kaj la limon, ĉe kiu la komparo estis farita. Tiam la leganto povas vidi, ke unu grupo respondis kompleta kaj alia ne, kio montras al itinero aŭ permeso anstataŭ al hazarda perdo.

Aldonu la kaptan dosieron kaj la filtrilajn esprimojn, por ke la grupigo estu reproduktebla. Resumo sen la dosiero estas aserto, ne rezulto.

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

Kiam unu grupo montras kvin respondojn kaj la alia neniun, la trovaĵo estas, ke unu fonto havas funkciantan revenan vojon kaj la alia ne. Tio estas multe pli bona bileto ol miksita procento, kaj ĝi direktas la sekvan kontrolon al la revena itinero anstataŭ al nerilata VPN-kazo.