Wireshark Ethernet इंटरफेसवर अगदी व्यवस्थित चालतो आणि नंतर, VPN अडॉप्टरवर, कॅप्चर सुरू होताच टनेल ट्रॅफिक पुढे जाऊ देत नाही। कॅप्चर विंडो भरत राहते, त्यामुळे साधन निरोगी दिसते, पण त्याखालील कनेक्शन मरत असते। प्रॉमिस्क्युअस मोड हे नेहमीचे कारण आहे, कारण ज्याच्याकडे नाही अशा सेगमेंटवरील प्रत्येक फ्रेम मागितले जाणारे टनेल ड्रायव्हर काहीच बाहेर न जाता अशा स्थितीत जाऊ शकते।

प्रथम तो पर्याय बंद करा, मग प्रत्यक्षात कोणता स्तर पाहणे आवश्यक आहे ते ठरवा।

दोन अडॉप्टर, दोन वेगळे दृश्य

VPN क्लायंट सहसा दोन इंटरफेस सादर करतो: एन्क्रिप्टेड ट्रान्सपोर्ट वाहून नेणारा भौतिक, आणि डिक्रिप्ट झालेला अंतर्गत ट्रॅफिक वाहून नेणारा वर्च्युअल। ते वेगवेगळ्या प्रश्नांची उत्तरे देतात। भौतिक कॅप्चर टोकबिंदू, पोर्ट आणि पॅकेटचे आकार दाखवते, तर वर्च्युअल टनेल जसे पोहोचवते तसे अनुप्रयोग प्रोटोकॉल दाखवते। कोणता प्रश्न विचारत आहात हे न जाणता एक निवडल्यास कॅप्चर वाया जाते।

कोणतेही दृश्य दुसऱ्याचा सुपरसेट नाही, आणि एक कॅप्चर एकाच वेळी दोन्ही प्रश्नांची उत्तरे क्वचित देते।

इंटरफेस यादीच्या क्रमाने नाही, प्रश्नाने निवडा, कारण PPP शैलीचा क्लायंट त्याचा अडॉप्टर Ethernet उपकरण म्हणून सादर करू शकतो आणि दाखवलेल्या नावावरून तुम्ही कोणता स्तर निवडला हे कळणार नाही। गेटवे किंवा मिरर पोर्टवरील कॅप्चर तिसरे दृश्य जोडते, जे फॉरवर्डिंगनंतरचा मार्ग दाखवते, आणि असममित राउटिंग व फिल्टरिंग तिथेच दिसते।

Capture pointWhat it showsWhat it cannot show
Physical interfaceOuter endpoints, ports, packet sizesAny inner payload
Tunnel interfaceDecrypted inner trafficWhat the VPN added around it
Gateway or mirrorForwarded path after the tunnelThe client's own decision process

प्रॉमिस्क्युअस मोड टनेल अडॉप्टर का तोडतो

प्रॉमिस्क्युअस मोड ड्रायव्हरला होस्टला पत्ता नसलेल्या फ्रेम देण्यास सांगतो, जे सामायिक Ethernet सेगमेंटवर अर्थपूर्ण आहे आणि पॉइंट-टू-पॉइंट टनेलवर फारच कमी अर्थपूर्ण। काही ड्रायव्हर विनंती शांतपणे हाताळतात; इतर ट्रान्समिट ट्रॅफिक रांगेतून काढणे थांबवतात आणि इंटरफेस शांतपणे काळ्या छिद्रात बदलतो। कॅप्चर येणारे नोंदवत राहते, त्यामुळे फाइल कार्यरत लिंकचा पुरावा वाटते। फाइल काय दाखवते आणि इंटरफेसने काय केले यातील तीच दरी हा संपूर्ण सापळा आहे।

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

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

IPsec कॅप्चर वाचनीय करणे

IPsec कॅप्चर एकटे वाचनीय नाही, कारण ESP पेलोड एन्क्रिप्ट करते। तुम्ही सेशन की दिल्यावर किंवा त्या निर्माण करणारी IKE बोलणी अनुसरता आल्यावर Wireshark ते डीकोड करू शकते, याचा अर्थ हातमिळवणी त्याच फाइलमध्ये असणे आवश्यक आहे।

की संपतात। दोन्ही बाजूंनी की नूतनीकृत केल्यावर जुन्या कींचा संच कॅप्चरच्या मध्यात काम करणे थांबवतो, आणि निकाल वेळेची मर्यादा नसून डीकोडर बगसारखा दिसतो।

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

सुरक्षितपणे सामायिक करता येणारे कॅप्चर

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

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

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

संबंधित लेख