Pierdere de Ping într-o VPN: grupați cererile Echo înainte de procent

O captură conține șase cereri Echo și trei răspunsuri, iar cineva scrie în tichet o pierdere de pachete de 50 la sută. Acel număr poate fi adevărat pentru captură și fals pentru tunel. Cele șase cereri pot aparține la două conversații diferite cu două contracte de livrare diferite. Grupați-le înainte de a împărți, iar raportul nu mai este partea interesantă a raportului.

Pasul 1: separați fluxurile după sursă și destinație

O cerere Echo poartă o sursă și o destinație, iar aceste două câmpuri definesc cărei conversații îi aparține. O sondă generată de poartă folosește adresa tunelului porții, în timp ce o sondă redirecționată în numele unui host LAN păstrează adresa acelui host. Partea îndepărtată poate avea o rută de retur pentru una și nu pentru cealaltă, ceea ce face ca cele două grupuri să se comporte diferit din motive care nu au nimic de-a face cu tunelul.

Împărțiți captura pe aceste câmpuri înainte de a număra ceva, și păstrați destinația ca parte a cheii. Două fluxuri către parteneri diferiți nu sunt comparabile chiar dacă împart o sursă.

Notați grupurile cu numărătorile lor, deoarece pasul următor decide ce răspunsuri aparțin cărui grup. Un grup cu trei cereri și niciun răspuns potrivit este o constatare. Un grup cu trei cereri și trei răspunsuri este o linie de bază.

Pasul 2: potriviți după identificator și secvență

Formatul Echo din RFC 792 poartă un identificator și un număr de secvență, și le tratează ca câmpurile care împerechează un răspuns cu cererea sa. Ambele sunt necesare pentru această sarcină. Un număr de secvență singur nu este unic, deoarece expeditori sau procese diferite pot reutiliza aceeași valoare într-o fereastră de captură. Identificatorul restrânge expeditorul, iar secvența poziția, și perechea împreună face potrivirea justificabilă.

Un răspuns inversează direcția adreselor cererii sale, deci o potrivire este o pereche cerere-răspuns, nu două tupluri identice. Comparați sursa cererii cu destinația răspunsului și destinația cererii cu sursa răspunsului, apoi confirmați că identificatorul și secvența coincid.

Păstrați și fereastra de observare, deoarece o captură lungă poate conține reutilizare legitimă a ambelor câmpuri. Tăierea ferestrei la un singur val elimină cea mai mare parte a acestei ambiguități. Face și numărătorile reproductibile pentru oricine citește tichetul.

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

Pasul 3: comparați tuplurile la aceeași graniță

Dacă traducerea adreselor de rețea se află între punctul de captură și partener, adresele din cerere și răspuns vor diferi prin proiectare. Comparați tuplurile la o singură graniță, sau purtați maparea explicit pentru ca diferența să fie luată în calcul. Amestecarea cererilor de dinainte de traducere cu răspunsuri de după traducere inventează nepotriviri care nu au existat niciodată pe fir.

Decideți granița înainte de a începe numărarea, și menționați-o în raport pentru ca următoarea persoană să poată reproduce gruparea. O captură pe partea clientului și alta pe partea serverului sunt două granițe diferite. Fiecare răspunde la o întrebare diferită despre unde a dispărut răspunsul.

Un grup de sonde traduse moștenește și starea proprie a dispozitivului de traducere, care poate fi motivul real pentru care un răspuns nu ajunge niciodată. Verificați acea stare înainte de a învinui calea de dincolo.

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

Pasul 4: spuneți ce poate și ce nu poate dovedi captura

Un gol observat nu stabilește că gazda îndepărtată a tăcut. Punctul de captură poate vedea doar o direcție, un filtru poate arunca răspunsul, sau tamponul poate fi suprasolicitat în timpul ferestrei. Fiecare dintre acestea produce aceeași absență și o concluzie diferită.

Notați locația capturii, expresia filtrului și contoarele de aruncare lângă numărători, deoarece un raport fără ele nu poate fi auditat. Acele trei linii fac numărul justificabil mai târziu.

Apoi separați ce stabilește observația de ce sugerează ea, în două propoziții în loc de una. Prima propoziție indică numărătorile și granița. A doua indică ipoteza și ce ar confirma-o.

Când întrebarea este dacă o anumită cale aruncă pachete, o sondă controlată cu o adresă de sursă explicită este o dovadă mai puternică decât o numărare pasivă a traficului amestecat. Trimiteți-o de pe aceeași mașină, în același moment, către același partener. Schimbați o variabilă și comparația rămâne valabilă.

Raportați grupurile și următoarea graniță

Raportul are trei linii: definiția grupului, numărătorile potrivite din fiecare grup și granița la care s-a făcut comparația. Cititorul poate vedea atunci că un grup a răspuns complet și altul nu, ceea ce indică o rută sau o permisiune și nu o pierdere aleatorie.

Atașați fișierul capturii și expresiile filtrelor pentru ca gruparea să poată fi reprodusă. Un rezumat fără fișier este o afirmație, nu un rezultat.

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

Când un grup arată cinci răspunsuri, iar celălalt niciunul, constatarea este că o sursă are o rută de retur funcțională, iar cealaltă nu. Este un tichet mult mai bun decât un procent amestecat și îndreaptă verificarea următoare spre ruta de retur în loc de o instanță VPN necorelată.