Ztráta Ping na VPN: seskupte požadavky Echo před procentem
Šest požadavků a tři odpovědi nejsou tvrzení o 50 procentech ztráty. Seskupte echa podle zdroje, identifikátoru a pořadí, než cokoli vydělíte.
Zachycení obsahuje šest požadavků Echo a tři odpovědi a někdo do tiketu napíše 50 procent ztráty paketů. To číslo může platit pro zachycení a neplatit pro tunel. Šest požadavků může patřit dvěma různým konverzacím se dvěma různými smlouvami o doručení. Seskupte je, než začnete dělit, a poměr přestane být zajímavou částí zprávy.
Krok 1: rozdělte toky podle zdroje a cíle
Požadavek Echo nese zdroj a cíl a tato dvě pole určují, ke které konverzaci patří. Sonda vytvořená bránou používá tunelovou adresu brány, zatímco sonda předaná jménem hostitele LAN si zachovává adresu tohoto hostitele. Protější strana může mít zpětnou trasu pro jednu a ne pro druhou, což způsobuje, že se obě skupiny chovají odlišně z důvodů, které s tunelem nemají nic společného.
Rozdělte zachycení podle těchto polí, než cokoli spočítáte, a ponechte cíl jako součást klíče. Dva toky k různým peerům nejsou srovnatelné, i když sdílejí zdroj.
Zapište skupiny s jejich počty, protože další krok rozhoduje, které odpovědi patří které skupině. Skupina se třemi požadavky a bez odpovídající odpovědi je zjištění. Skupina se třemi požadavky a třemi odpověďmi je výchozí hodnota.
Krok 2: párujte podle identifikátoru a pořadí
Formát Echo v RFC 792 nese identifikátor a pořadové číslo a považuje je za pole, která párují odpověď s jejím požadavkem. Pro tento úkol jsou potřeba obě. Samotné pořadové číslo není jedinečné, protože různí odesílatelé nebo procesy mohou znovu použít stejnou hodnotu v jednom okně zachycení. Identifikátor zužuje odesílatele a pořadí zužuje pozici a právě dvojice společně činí shodu obhajitelnou.
Odpověď obrací směr adres svého požadavku, takže shoda je dvojice požadavek-odpověď, nikoli dvě identické n-tice. Porovnejte zdroj požadavku s cílem odpovědi a cíl požadavku se zdrojem odpovědi, poté potvrďte, že identifikátor a pořadí souhlasí.
Ponechte také pozorovací okno, protože dlouhé zachycení může obsahovat legitimní opětovné použití obou polí. Oříznutí okna na jednu dávku odstraní většinu této nejednoznačnosti. Také činí počty reprodukovatelnými pro každého, kdo tiket čte.
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.seqKrok 3: porovnejte n-tice na stejné hranici
Pokud mezi místem zachycení a peerem stojí překlad síťových adres, adresy v požadavku a odpovědi se budou záměrně lišit. Porovnejte n-tice na jedné hranici, nebo přenášejte mapování explicitně, aby rozdíl byl zohledněn. Míchání požadavků před překladem s odpověďmi po překladu vytváří neshody, které na drátě nikdy neexistovaly.
Rozhodněte o hranici, než začnete počítat, a uveďte ji ve zprávě, aby další člověk mohl seskupení reprodukovat. Jedno zachycení na straně klienta a druhé na straně serveru jsou dvě různé hranice. Každá odpovídá na jinou otázku o tom, kde odpověď zmizela.
Skupina přeložených sond také dědí vlastní stav překladového zařízení, což může být skutečný důvod, proč odpověď nikdy nedorazí. Zkontrolujte tento stav, než 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 -20Krok 4: řekněte, co zachycení může a co nemůže dokázat
Pozorovaná mezera neprokazuje, že vzdálený hostitel mlčel. Místo zachycení může vidět jen jeden směr, filtr může odpověď zahodit nebo se buffer mohl během okna přeplnit. Každé z toho dává stejnou nepřítomnost a jiný závěr.
Zaznamenejte místo zachycení, výraz filtru a počítadla zahození vedle počtů, protože poměr bez nich nelze auditovat. Právě tyto tři řádky činí číslo později obhajitelným.
Poté oddělte, co pozorování prokazuje, od toho, co naznačuje, ve dvou větách místo jedné. První věta uvádí počty a hranici. Druhá uvádí hypotézu a co by ji potvrdilo.
Když je otázkou, zda konkrétní cesta zahazuje pakety, kontrolovaná sonda s explicitní zdrojovou adresou je silnější důkaz než pasivní počet smíšeného provozu. Pošlete ji ze stejného stroje, ve stejnou dobu, stejnému peerovi. Změňte jednu proměnnou a srovnání zůstane.
Nahlaste skupiny a další hranici
Zpráva má tři řádky: definici skupiny, spárované počty uvnitř každé skupiny a hranici, na níž bylo srovnání provedeno. Čtenář pak vidí, že jedna skupina odpověděla úplně a druhá ne, což ukazuje na trasu nebo oprávnění, nikoli na náhodnou ztrátu.
Přiložte soubor zachycení a výrazy filtrů, aby seskupení bylo reprodukovatelné. Shrnutí bez souboru je tvrzení, ne výsledek.
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 | headKdyž jedna skupina ukazuje pět odpovědí a druhá žádnou, zjištěním je, že jeden zdroj má funkční zpětnou trasu a druhý ne. To je mnohem lepší tiket než smíšené procento a nasměruje další kontrolu na zpětnou trasu místo na nesouvisející instanci VPN.