VPN वर Ping तोटा: टक्केवारीपूर्वी Echo विनंत्या गटात टाका

एका कॅप्चरमध्ये सहा Echo विनंत्या आणि तीन उत्तरे असतात, आणि कोणीतरी तिकिटात 50 टक्के पॅकेट तोटा लिहितो। ती संख्या कॅप्चरसाठी खरी आणि बोगद्यासाठी खोटी असू शकते। त्या सहा विनंत्या दोन वेगवेगळ्या वितरण करारांसह दोन वेगवेगळ्या संभाषणांच्या असू शकतात। विभागण्यापूर्वी त्यांना गटात टाका, आणि प्रमाण अहवालाचा मनोरंजक भाग राहणार नाही।

पायरी 1: स्रोत आणि गंतव्यानुसार प्रवाह वेगळे करा

Echo विनंती स्रोत आणि गंतव्य घेऊन जाते, आणि ती दोन क्षेत्रे ती कोणत्या संभाषणाची आहे हे ठरवतात। गेटवे तयार करतो तो प्रोब गेटवेचा बोगदा पत्ता वापरतो, तर LAN होस्टच्या वतीने पाठवलेला प्रोब त्या होस्टचा पत्ता ठेवतो। पलीकडे एकासाठी परतीचा मार्ग असू शकतो आणि दुसऱ्यासाठी नाही, त्यामुळे बोगद्याशी संबंध नसलेल्या कारणांमुळे दोन्ही गट वेगळे वागतात।

काहीही मोजण्यापूर्वी कॅप्चर त्या क्षेत्रांवर विभागा, आणि गंतव्य किल्लीचा भाग म्हणून ठेवा। वेगवेगळ्या पीअर्सकडे जाणारे दोन प्रवाह स्रोत सामायिक करत असले तरी तुलनीय नाहीत।

गट त्यांच्या संख्येसह लिहा, कारण पुढील पायरी कोणती उत्तरे कोणत्या गटाची आहेत हे ठरवते। तीन विनंत्या आणि जुळणारे उत्तर नसलेला गट हा एक शोध आहे। तीन विनंत्या आणि तीन उत्तरे असलेला गट आधाररेषा आहे।

पायरी 2: ओळखकर्ता आणि क्रमानुसार जुळवा

RFC 792 मधील Echo स्वरूप ओळखकर्ता आणि क्रम क्रमांक घेऊन जाते, आणि ते उत्तराला त्याच्या विनंतीशी जोडणारी क्षेत्रे म्हणून वापरते। त्या कामासाठी दोन्ही लागतात। फक्त क्रम क्रमांक अद्वितीय नाही, कारण वेगवेगळे प्रेषक किंवा प्रक्रिया एकाच कॅप्चर विंडोमध्ये तोच मूल्य पुन्हा वापरू शकतात। ओळखकर्ता प्रेषक आणि क्रम स्थान अरुंद करतो, आणि जोडी एकत्र जुळणीचे समर्थन करते।

उत्तर आपल्या विनंतीची पत्ता दिशा उलटते, म्हणून जुळणी म्हणजे विनंती-उत्तर जोडी, दोन एकसारखे ट्यूपल नाहीत। विनंतीचा स्रोत उत्तराच्या गंतव्याशी आणि विनंतीचे गंतव्य उत्तराच्या स्रोताशी तुलना करा, नंतर ओळखकर्ता आणि क्रम जुळतात याची खात्री करा।

निरीक्षण विंडोही ठेवा, कारण लांब कॅप्चरमध्ये दोन्ही क्षेत्रांचा कायदेशीर पुनर्वापर असू शकतो। विंडो एका स्फोटापर्यंत कमी केल्यास ती अस्पष्टता बहुतेक निघून जाते। तिकीट वाचणाऱ्या प्रत्येकासाठी मोजणी पुनरुत्पादनीय होते।

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: त्याच सीमेवर ट्यूपलची तुलना करा

जर नेटवर्क पत्ता अनुवाद कॅप्चर बिंदू आणि पीअर दरम्यान असेल, तर विनंती आणि उत्तरातील पत्ते रचनेनुसार वेगळे असतील। ट्यूपलची तुलना एका सीमेवर करा, किंवा फरक विचारात घेण्यासाठी मॅपिंग स्पष्टपणे न्या। अनुवादापूर्वीच्या विनंत्या अनुवादानंतरच्या उत्तरांसोबत मिसळल्यास तारेवर कधीही नसलेल्या विसंगती तयार होतात।

मोजायला सुरुवात करण्यापूर्वी सीमा ठरवा, आणि पुढच्या व्यक्तीला गटीकरण पुनरुत्पादित करता यावे म्हणून अहवालात ती नमूद करा। क्लायंट बाजूला एक कॅप्चर आणि सर्व्हर बाजूला दुसरे अशा दोन वेगळ्या सीमा आहेत। प्रत्येक उत्तर कुठे गायब झाले याबद्दल वेगळ्या प्रश्नाचे उत्तर देते।

अनुवादित प्रोबचा गट अनुवाद उपकरणाची स्वतःची स्थितीही वारसा घेतो, जी उत्तर कधीही न येण्याचे खरे कारण असू शकते। त्यापुढील मार्गाला दोष देण्यापूर्वी ती स्थिती तपासा।

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: कॅप्चर काय सिद्ध करू शकते आणि काय नाही ते सांगा

निरीक्षण केलेली पोकळी हे सिद्ध करत नाही की दूरचा होस्ट गप्प राहिला। कॅप्चर बिंदूला फक्त एक दिशा दिसू शकते, फिल्टर उत्तर टाकून देऊ शकतो, किंवा विंडो दरम्यान बफर ओसंडून वाहू शकतो। त्यापैकी प्रत्येक समान अनुपस्थिती आणि वेगळा निष्कर्ष देतो।

मोजणीसोबत कॅप्चरचे स्थान, फिल्टर अभिव्यक्ती आणि ड्रॉप काउंटर नोंदवा, कारण त्यांशिवाय प्रमाणाचे ऑडिट होऊ शकत नाही। त्या तीन ओळीच संख्येचे नंतर समर्थन करतात।

मग निरीक्षण काय स्थापित करते आणि काय सुचवते हे एका नाही दोन वाक्यांत वेगळे करा। पहिले वाक्य मोजणी आणि सीमा सांगते। दुसरे गृहीतक आणि ते काय पुष्टी करेल ते सांगते।

ठराविक मार्ग पॅकेट टाकून देतो का हा प्रश्न असेल, तर स्पष्ट स्रोत पत्त्यासह नियंत्रित प्रोब मिश्र रहदारीच्या निष्क्रिय मोजणीपेक्षा मजबूत पुरावा आहे। तो त्याच मशीनमधून, त्याच वेळी, त्याच पीअरकडे पाठवा। एक चल बदला आणि तुलना टिकते।

गट आणि पुढील सीमा नोंदवा

अहवालात तीन ओळी असतात: गटाची व्याख्या, प्रत्येक गटातील जुळलेली मोजणी, आणि तुलना ज्या सीमेवर केली ती। मग वाचकाला दिसते की एका गटाने पूर्ण उत्तर दिले आणि दुसऱ्याने नाही, जे यादृच्छिक तोट्याऐवजी मार्ग किंवा परवानगीकडे निर्देश करते।

गटीकरण पुनरुत्पादनीय व्हावे म्हणून कॅप्चर फाइल आणि फिल्टर अभिव्यक्ती जोडा। फाइलशिवाय सारांश हा दावा आहे, निकाल नाही।

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

जेव्हा एक गट पाच उत्तरे दाखवतो आणि दुसरा काहीही नाही, तेव्हा शोध हा आहे की एका स्रोताकडे कार्यरत परतीचा मार्ग आहे आणि दुसऱ्याकडे नाही। हे मिश्र टक्केवारीपेक्षा खूप चांगले तिकीट आहे, आणि ते पुढील तपासणी असंबंधित VPN उदाहरणाकडे नाही तर परतीच्या मार्गाकडे वळवते।