Ping-vesztés VPN-en: csoportosítsa az Echo-kéréseket a százalék előtt

Egy rögzítés hat Echo-kérést és három választ tartalmaz, és valaki 50 százalék csomagvesztést ír a jegybe. Ez a szám igaz lehet a rögzítésre és hamis az alagútra. A hat kérés tartozhat két különböző beszélgetéshez, két különböző kézbesítési szerződéssel. Csoportosítsa őket, mielőtt oszt, és az arány többé nem lesz a jelentés érdekes része.

1. lépés: válassza szét a folyamokat forrás és cél szerint

Az Echo-kérés forrást és célt hordoz, és ez a két mező határozza meg, melyik beszélgetéshez tartozik. Az átjáró által létrehozott próba az átjáró alagút-címét használja, míg a LAN-gazdagép nevében továbbított próba megtartja annak a gazdagépnek a címét. A túloldalnak lehet visszatérési útvonala az egyikhez, és nem a másikhoz, ami miatt a két csoport eltérően viselkedik olyan okokból, amelyeknek semmi közük az alagúthoz.

Bontsa fel a rögzítést ezekre a mezőkre, mielőtt bármit számol, és tartsa meg a célt a kulcs részeként. Két különböző peer felé menő folyam nem hasonlítható össze akkor sem, ha közös forrást osztanak.

Írja fel a csoportokat a darabszámukkal, mert a következő lépés dönti el, mely válaszok melyik csoporthoz tartoznak. A három kérést és egyetlen megfelelő választ sem tartalmazó csoport lelet. A három kérést és három választ tartalmazó csoport alapvonal.

2. lépés: párosítson az azonosító és a sorrend alapján

Az RFC 792-ben szereplő Echo-formátum azonosítót és sorszámot hordoz, és ezeket tekinti azoknak a mezőknek, amelyek egy választ a kéréséhez párosítanak. Mindkettőre szükség van ehhez a munkához. A sorszám önmagában nem egyedi, mivel különböző küldők vagy folyamatok ugyanazt az értéket újra felhasználhatják egy rögzítési ablakon belül. Az azonosító szűkíti a küldőt, a sorrend a pozíciót, és a pár együtt teszi védhetővé a párosítást.

A válasz megfordítja a kéréséhez tartozó címirányt, tehát a párosítás kérés-válasz pár, és nem két azonos tuple. Hasonlítsa össze a kérés forrását a válasz céljával, és a kérés célját a válasz forrásával, majd erősítse meg, hogy az azonosító és a sorrend megegyezik.

Tartsa meg a megfigyelési ablakot is, mert egy hosszú rögzítés tartalmazhatja mindkét mező jogszerű újrafelhasználását. Az ablak egyetlen sorozatra vágása eltávolítja e bizonytalanság nagy részét. Azzá is teszi a számokat, hogy bárki, aki a jegyet olvassa, reprodukálhassa őket.

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

3. lépés: hasonlítsa össze a tuple-öket ugyanazon a határon

Ha a hálózaticím-fordítás a rögzítési pont és a peer között van, a kérés és a válasz címei tervezés szerint eltérnek. Hasonlítsa össze a tuple-öket egy határon, vagy vigye magával a leképezést kifejezetten, hogy a különbség elszámolható legyen. A fordítás előtti kérések és a fordítás utáni válaszok keverése olyan eltéréseket talál ki, amelyek soha nem léteztek a vezetéken.

Döntse el a határt, mielőtt elkezd számolni, és adja meg a jelentésben, hogy a következő személy reprodukálhassa a csoportosítást. Egy rögzítés az ügyfél oldalán és egy másik a kiszolgáló oldalán két különböző határ. Mindegyik más kérdésre válaszol arról, hol tűnt el a válasz.

A lefordított próbák csoportja a fordítóeszköz saját állapotát is örökli, ami az igazi oka lehet annak, hogy egy válasz soha nem érkezik meg. Ellenőrizze ezt az állapotot, mielőtt az azon túli útvonalat hibáztatná.

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

4. lépés: mondja el, mit tud és mit nem tud bizonyítani a rögzítés

Egy megfigyelt rés nem bizonyítja, hogy a távoli gazdagép hallgatott. A rögzítési pont csak egy irányt láthat, egy szűrő eldobhatja a választ, vagy a puffer túlcsordulhatott az ablak alatt. Mindegyik ugyanazt a hiányt és más következtetést eredményezi.

Jegyezze fel a rögzítés helyét, a szűrőkifejezést és az eldobási számlálókat a számok mellett, mert ezek nélkül az arány nem auditálható. Ez a három sor teszi később védhetővé a számot.

Ezután válassza szét, mit állapít meg a megfigyelés és mit sugall, két mondatban egy helyett. Az első mondat megadja a számokat és a határt. A második megadja a hipotézist és azt, mi erősítené meg.

Amikor a kérdés az, hogy egy adott útvonal eldob-e csomagokat, a kifejezett forráscímmel rendelkező ellenőrzött próba erősebb bizonyíték, mint a vegyes forgalom passzív számlálása. Küldje ugyanarról a gépről, ugyanabban az időben, ugyanahhoz a peerhez. Változtasson meg egy változót, és az összehasonlítás érvényben marad.

Jelentse a csoportokat és a következő határt

A jelentésnek három sora van: a csoport meghatározása, a párosított számok az egyes csoportokon belül, és a határ, ahol az összehasonlítás történt. Ekkor a olvasó láthatja, hogy az egyik csoport teljesen válaszolt, a másik pedig nem, ami útvonalra vagy engedélyre utal, nem véletlen veszteségre.

Csatolja a rögzítési fájlt és a szűrőkifejezéseket, hogy a csoportosítás reprodukálható legyen. A fájl nélküli összefoglaló állítás, nem eredmény.

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

Amikor az egyik csoport öt választ mutat, a másik pedig egyet sem, a lelet az, hogy az egyik forrásnak működő visszatérési útvonala van, a másiknak pedig nincs. Ez sokkal jobb jegy, mint egy kevert százalék, és a következő ellenőrzést a visszatérési útvonalra irányítja egy független VPN-példány helyett.