पॅकेट कॅप्चरमधील पहिला IKEv2 देवाणघेवाण कसा वाचावा

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

तुम्ही सुरुवातीची देवाणघेवाण पाहत आहात याची खात्री करा

IKEv2 वाटाघाटी IKE_SA_INIT ने सुरू होते, देवाणघेवाण प्रकार 34, संदेश आयडी 0. सुरुवात करणारा शून्येतर SPI निवडतो, आणि प्रतिसाद देणाऱ्याचा SPI त्या पहिल्या विनंतीत शून्य आणि प्रतिसादात शून्येतर असतो. ही तीन तथ्ये नवीन प्रयत्नाला किल्ली नूतनीकरणापासून किंवा कॅप्चरच्या वरच्या टोकाला अपघाताने असलेल्या IKE_AUTH संदेशापासून वेगळे करतात.

हेडर फील्ड वाचनीय आहेत, आणि प्रस्ताव, किल्ली देवाणघेवाण व nonce पेलोडही वाचनीय आहेत. वाचनीय म्हणजे प्रमाणित नाही: या टप्प्यावर कोणत्याही बाजूने ओळख सिद्ध केलेली नाही, आणि Diffie-Hellman चे खाजगी मूल्य तारेवर कधीही दिसत नाही.

डीकोड पॅनेल स्क्रोल करण्याऐवजी फील्ड टेबल म्हणून छापा, कारण पुनःप्रेषण आणि न जुळणारे SPI स्तंभांमध्ये स्पष्ट होतात.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

आउटपुट जोड्यांमध्ये वाचा. संदेश आयडी 0 असलेल्या विनंतीनंतर तोच आयडी आणि शून्येतर प्रतिसादक SPI घेऊन येणारा प्रतिसाद ही एकच देवाणघेवाण आहे, विनंती पुन्हा पाठवल्यामुळे ती तीन वेळा दिसली तरीही. तीन सारख्या विनंत्या तीन लॉगिन नाहीत, आणि त्या तशा मानल्यामुळेच लोक निष्कर्ष काढतात की क्लायंट लूपमध्ये फिरत आहे, तो फक्त संयमी आहे. संदेश आयडीनुसार, नंतर वेळेच्या ठशानुसार क्रम लावा, आणि संपूर्ण संभाषण प्रयत्नांच्या छोट्या यादीत आकुंचन पावेल.

यश वाचण्यापूर्वी नकार वाचा

प्रतिसाद हा स्वयंचलित प्रगती नाही. प्रतिसाद देणारा cookie सूचनेने उत्तर देऊन सुरुवात करणाऱ्याने पुन्हा प्रयत्न करावा अशी अपेक्षा करू शकतो, किंवा त्याऐवजी स्वीकारल्या जाणाऱ्या गटाचे नाव देणाऱ्या INVALID_KE_PAYLOAD ने. दोन्ही योग्य रचनेचे IKE संदेश म्हणून येतात, आणि फक्त पॅकेट मोजणाऱ्या फिल्टरला दोन्ही पूर्ण झालेली देवाणघेवाण वाटतात.

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

फक्त IKE_AUTH, म्हणजे दुसरी देवाणघेवाण, एन्क्रिप्टेड ओळख आणि प्रमाणीकरण पेलोड घेऊन जाते. म्हणून पूर्ण झालेला IKE_SA_INIT तुम्हाला सांगतो की दोन्ही बाजू अल्गोरिदम आणि व्युत्पन्न किल्ल्यांवर सहमत आहेत, आणि ओळखपत्रे स्वीकारली जातील का याबद्दल काहीही सांगत नाही. तिथेही दोन संदेश अपेक्षित धरा, आणि सत्र किल्ल्यांशिवाय दोन्ही अपारदर्शक राहतील अशी अपेक्षा धरा.

पोर्ट 4500 हा एकच प्रोटोकॉल नाही

सुरुवातीची देवाणघेवाण सामान्यतः UDP 500 वाहून नेते. NAT शोध चालल्यानंतर IKE 4500 वर जाते आणि प्रत्येक संदेशापूर्वी चार बाइटचा शून्य बिगर-ESP मार्कर लावते. त्याच पोर्टवरील एन्कॅप्सुलेटेड ESP मात्र शून्येतर ESP SPI ने सुरू होते, आणि एक बाइटचा NAT keepalive हा तिसरा आकार आहे जो दुसरे काही घडत नसताना दिसतो.

फक्त पोर्ट जुळवणारा फिल्टर तिन्ही एकत्र करतो, आणि म्हणूनच "4500 वर रहदारी आहे" इतके कमी ठरवते. दूरच्या टोकाबद्दल काही निष्कर्ष काढण्यापूर्वी दृश्य प्रोटोकॉलनुसार विभागा.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

शांतता निरीक्षण बिंदूचे वर्णन करते

प्रतिसाद नसलेल्या विनंत्या नेमके एकच स्थापित करतात: त्या कॅप्चर बिंदूवर कोणताही प्रतिसाद आलेला नाही. फिल्टरिंग, प्रतिसाद दुसरीकडे पाठवणारा मार्ग, अगम्य प्रतिसाद देणारा, किंवा प्रस्ताव आवडत नसलेला प्रतिसाद देणारा — सर्वांचा परिणाम तोच रिकामा असतो, आणि सामान्य UDP तपासणी त्यांना वेगळे करणार नाही.

ICMP अगम्यता हा वेगळ्या प्रकारचा पुरावा आहे. त्यातील उद्धृत पॅकेट वाचा आणि कोणत्या उपकरणाने ते पाठवले ते ओळखा, कारण राउटरचा प्रशासकीय नकार ही दूरच्या टोकाकडून आलेली प्रमाणित त्रुटी नाही.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

वाचण्याची परवानगी असलेल्या ठिकाणी तोच प्रयत्न सर्व्हर-बाजूच्या लॉगशी जुळवा. विनंती पोहोचली का, सेवेने उत्तर दिले का, आणि उत्तर कुठे थांबले? ती तीन उत्तरे तुम्हाला मार्गाच्या समस्येकडे किंवा धोरणाच्या समस्येकडे पाठवतात, आणि चौथ्यांदा ओळखपत्रे बदलण्यापेक्षा ती कमी खर्चिक असतात.