Humbja e Ping në një VPN: gruponi kërkesat Echo para përqindjes

Një kapje përmban gjashtë kërkesa Echo dhe tre përgjigje, dhe dikush shkruan në tiketë një humbje paketash prej 50 për qind. Ky numër mund të jetë i vërtetë për kapjen dhe i rremë për tunelin. Gjashtë kërkesat mund t'i përkasin dy bisedave të ndryshme me dy kontrata të ndryshme dorëzimi. Gruponi ato përpara se të ndani, dhe raporti nuk është më pjesa interesante e raportit.

Hapi 1: ndani rrjedhat sipas burimit dhe destinacionit

Një kërkesë Echo mbart një burim dhe një destinacion, dhe këto dy fusha përcaktojnë se cilës bisedë i përket. Sonda që gjenerohet nga porta përdor adresën e tunelit të portës, ndërsa sonda që përcillet në emër të një hosti LAN ruan adresën e atij hosti. Ana e largët mund të ketë një rrugë kthimi për njërën dhe jo për tjetrën, gjë që bën që dy grupet të sillen ndryshe për arsye që nuk kanë lidhje me tunelin.

Ndani kapjen sipas këtyre fushave përpara se të numëroni çdo gjë, dhe mbani destinacionin si pjesë të çelësit. Dy rrjedha drejt partnerëve të ndryshëm nuk janë të krahasueshme edhe kur ndajnë një burim.

Shkruani grupet me numrat e tyre, sepse hapi tjetër vendos se cilat përgjigje i përkasin cilit grup. Një grup me tre kërkesa dhe pa përgjigje përkatëse është një gjetje. Një grup me tre kërkesa dhe tre përgjigje është një vijë bazë.

Hapi 2: përputhni sipas identifikuesit dhe sekuencës

Formati Echo në RFC 792 mbart një identifikues dhe një numër sekuence, dhe i trajton ata si fushat që çiftojnë një përgjigje me kërkesën e saj. Të dyja nevojiten për këtë punë. Vetëm numri i sekuencës nuk është unik, pasi dërgues ose procese të ndryshme mund të ripërdorin të njëjtën vlerë brenda një dritareje kapjeje. Identifikuesi ngushton dërguesin dhe sekuenca pozicionin, dhe çifti së bashku e bën përputhjen të mbrojtshme.

Një përgjigje përmbys drejtimin e adresave të kërkesës së saj, kështu që një përputhje është një çift kërkesë-përgjigje dhe jo dy tuple identike. Krahasoni burimin e kërkesës me destinacionin e përgjigjes dhe destinacionin e kërkesës me burimin e përgjigjes, pastaj konfirmoni që identifikuesi dhe sekuenca përputhen.

Mbani edhe dritaren e vëzhgimit, sepse një kapje e gjatë mund të përmbajë ripërdorim legjitim të të dyjave fushave. Shkurtimi i dritares në një shpërthim heq pjesën më të madhe të asaj paqartësie. Gjithashtu i bën numërimet të riprodhueshme për këdo që lexon tiketën.

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

Hapi 3: krahasoni tuplet në të njëjtin kufi

Nëse përkthimi i adresave të rrjetit ndodhet midis pikës së kapjes dhe partnerit, adresat në kërkesë dhe përgjigje do të ndryshojnë sipas projektimit. Krahasoni tuplet në një kufi të vetëm, ose mbartni hartëzimin në mënyrë eksplicite që diferenca të llogaritet. Përzierja e kërkesave para përkthimit me përgjigjet pas përkthimit shpik mospërputhje që nuk ekzistonin kurrë në tel.

Vendosni kufirin përpara se të filloni të numëroni, dhe deklarojeni në raport që personi tjetër të mund të riprodhojë grupimin. Një kapje në anën e klientit dhe një tjetër në anën e serverit janë dy kufij të ndryshëm. Secili përgjigjet një pyetjeje të ndryshme rreth asaj se ku u zhduk përgjigja.

Një grup sondash të përkthyera trashëgon gjithashtu gjendjen e vetë pajisjes së përkthimit, e cila mund të jetë arsyeja e vërtetë pse një përgjigje nuk arrin kurrë. Kontrolloni atë gjendje përpara se të fajësoni rrugën përtej saj.

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

Hapi 4: thoni çfarë kapja mund dhe nuk mund të provojë

Një boshllëk i vëzhguar nuk vërteton se hosti i largët qëndroi i heshtur. Pika e kapjes mund të shohë vetëm një drejtim, një filtër mund ta hedhë poshtë përgjigjen, ose buferi mund të jetë tejkaluar gjatë dritares. Secili prej tyre prodhon të njëjtën mungesë dhe një përfundim të ndryshëm.

Regjistroni vendndodhjen e kapjes, shprehjen e filtrit dhe numëruesit e hedhjes pranë numërimeve, sepse një raport pa ato nuk mund të auditohet. Janë pikërisht ato tre rreshta që e bëjnë numrin të mbrojtshëm më vonë.

Pastaj ndani atë që vëzhgimi vërteton nga ajo që sugjeron, në dy fjali në vend të një. Fjalia e parë thotë numërimet dhe kufirin. E dyta thotë hipotezën dhe çfarë do ta konfirmonte.

Kur pyetja është nëse një rrugë specifike hedh poshtë paketa, një sondë e kontrolluar me një adresë burimi të qartë është provë më e fortë sesa një numërim pasiv i trafikut të përzier. Dërgojeni nga i njëjti makinë, në të njëjtën kohë, te i njëjti partner. Ndryshoni një variabël dhe krahasimi mbahet.

Raportoni grupet dhe kufirin tjetër

Raporti ka tre rreshta: përkufizimin e grupit, numërimet e përputhura brenda çdo grupi dhe kufirin ku u bë krahasimi. Atëherë lexuesi mund të shohë se një grup u përgjigj plotësisht dhe tjetri jo, gjë që tregon një rrugë ose një leje dhe jo një humbje të rastësishme.

Bashkëngjitni skedarin e kapjes dhe shprehjet e filtrave që grupimi të mund të riprodhohet. Një përmbledhje pa skedarin është një pohim, jo një 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

Kur një grup tregon pesë përgjigje dhe tjetri asnjë, gjetja është se një burim ka një rrugë kthimi funksionale dhe tjetri jo. Është një tiketë shumë më e mirë sesa një përqindje e përzier, dhe e drejton kontrollin tjetër te rruga e kthimit në vend të një instance VPN të palidhur.