Strata Ping vo VPN: zoskupte požiadavky Echo pred percentom

Jedno zachytenie obsahuje šesť požiadaviek Echo a tri odpovede a niekto do tiketu napíše 50 percent straty paketov. To číslo môže platiť pre zachytenie a neplatiť pre tunel. Šesť požiadaviek môže patriť dvom rôznym konverzáciám s dvomi rôznymi dodacími zmluvami. Zoskupte ich, kým začnete deliť, a pomer prestane byť zaujímavou časťou správy.

Krok 1: rozdeľte toky podľa zdroja a cieľa

Požiadavka Echo nesie zdroj a cieľ a tieto dve polia určujú, do ktorej konverzácie patrí. Sonda vytvorená bránou používa tunelovú adresu brány, zatiaľ čo sonda preposlaná v mene hostiteľa LAN si zachováva adresu tohto hostiteľa. Protistrana môže mať spätnú trasu pre jednu a nie pre druhú, čo spôsobuje, že sa obe skupiny správajú odlišne z dôvodov, ktoré s tunelom nemajú nič spoločné.

Rozdeľte zachytenie podľa týchto polí, kým čokoľvek spočítate, a ponechajte cieľ ako súčasť kľúča. Dva toky k rôznym partnerom nie sú porovnateľné, aj keď zdieľajú zdroj.

Zapíšte skupiny s ich počtami, pretože ďalší krok rozhoduje, ktoré odpovede patria ktorej skupine. Skupina s tromi požiadavkami a bez zodpovedajúcej odpovede je zistenie. Skupina s tromi požiadavkami a tromi odpoveďami je základná línia.

Krok 2: párujte podľa identifikátora a poradia

Formát Echo v RFC 792 nesie identifikátor a poradové číslo a považuje ich za polia, ktoré spájajú odpoveď s jej požiadavkou. Na túto úlohu sú potrebné obe. Samotné poradové číslo nie je jedinečné, pretože rôzni odosielatelia alebo procesy môžu znovu použiť rovnakú hodnotu v jednom okne zachytenia. Identifikátor zužuje odosielateľa a poradie pozíciu, a práve dvojica spolu robí zhodu obhájiteľnou.

Odpoveď obracia smer adries svojej požiadavky, takže zhoda je dvojica požiadavka-odpoveď, nie dve identické n-tice. Porovnajte zdroj požiadavky s cieľom odpovede a cieľ požiadavky so zdrojom odpovede, potom potvrďte, že identifikátor a poradie súhlasia.

Ponechajte aj pozorovacie okno, pretože dlhé zachytenie môže obsahovať legitímne opätovné použitie oboch polí. Orezanie okna na jednu dávku odstráni väčšinu tejto nejednoznačnosti. Tiež robí počty reprodukovateľnými pre každého, kto tiket číta.

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

Krok 3: porovnajte n-tice na tej istej hranici

Ak preklad sieťových adries stojí medzi miestom zachytenia a partnerom, adresy v požiadavke a odpovedi sa budú líšiť zámerne. Porovnajte n-tice na jednej hranici, alebo prenášajte mapovanie explicitne, aby sa rozdiel zohľadnil. Miešanie požiadaviek pred prekladom s odpoveďami po preklade vytvára nezhody, ktoré na drôte nikdy neexistovali.

Rozhodnite o hranici, kým začnete počítať, a uveďte ju v správe, aby ďalší človek mohol zoskupenie reprodukovať. Jedno zachytenie na strane klienta a druhé na strane servera sú dve rôzne hranice. Každé odpovedá na inú otázku o tom, kde odpoveď zmizla.

Skupina preložených sond tiež dedí vlastný stav prekladového zariadenia, čo môže byť skutočný dôvod, prečo odpoveď nikdy nedorazí. Skontrolujte tento stav, kým obviníte cestu za ním.

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

Krok 4: povedzte, čo zachytenie môže a čo nemôže dokázať

Pozorovaná medzera nepreukazuje, že vzdialený hostiteľ mlčal. Miesto zachytenia môže vidieť len jeden smer, filter môže odpoveď zahodiť alebo sa buffer mohol počas okna preplniť. Každé z toho dáva rovnakú neprítomnosť a iný záver.

Zaznamenajte miesto zachytenia, výraz filtra a počítadlá zahození vedľa počtov, pretože pomer bez nich nemožno auditovať. Práve tieto tri riadky robia číslo neskôr obhájiteľným.

Potom oddeľte, čo pozorovanie potvrdzuje, od toho, čo naznačuje, v dvoch vetách namiesto jednej. Prvá veta uvádza počty a hranicu. Druhá uvádza hypotézu a čo by ju potvrdilo.

Keď je otázkou, či konkrétna cesta zahadzuje pakety, kontrolovaná sonda s explicitnou zdrojovou adresou je silnejší dôkaz než pasívny počet zmiešanej prevádzky. Pošlite ju z rovnakého stroja, v rovnakom čase, rovnakému partnerovi. Zmeňte jednu premennú a porovnanie zostane.

Nahláste skupiny a ďalšiu hranicu

Správa má tri riadky: definíciu skupiny, spárované počty v každej skupine a hranicu, na ktorej sa porovnanie urobilo. Čitateľ potom vidí, že jedna skupina odpovedala úplne a druhá nie, čo ukazuje na trasu alebo oprávnenie, nie na náhodnú stratu.

Priložte súbor zachytenia a výrazy filtrov, aby sa zoskupenie dalo reprodukovať. Zhrnutie bez súboru je tvrdenie, nie výsledok.

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

Keď jedna skupina ukazuje päť odpovedí a druhá žiadnu, zistením je, že jeden zdroj má funkčnú spätnú trasu a druhý nie. To je oveľa lepší tiket než zmiešané percento a nasmeruje ďalšiu kontrolu na spätnú trasu namiesto nesúvisiacej inštancie VPN.