कॅप्चरमध्ये नवीन IKE_SA_INIT देवाणघेवाण कशी वाचावी

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

प्रथम, कॅप्चर सुरुवातीपासून सुरू झाले आहे याची खात्री करा

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

कॅप्चर दोन टोकांपर्यंत आणि UDP 500 व 4500 पर्यंत मर्यादित करा जेणेकरून फाइल वाचण्याइतकी लहान राहील। व्यस्त होस्टवर फिल्टर नसलेले कॅप्चर बोलणीला असंबंधित रहदारीखाली पुरते।

tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'

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

दुसरे, पेलोडपूर्वी हेडर वाचा

IKE हेडर सुरक्षा मापदंड निर्देशांक, देवाणघेवाणीचा प्रकार आणि संदेश ID घेऊन जाते, आणि नवीन बोलणीत ही मूल्ये वेगळी असतात। सुरुवात करणारा शून्येतर SPI तयार करतो, सुरुवातीची विनंती उत्तरदात्याचा शून्य SPI घेऊन जाते कारण अजून कोणतेही उत्तर दिसले नाही, देवाणघेवाणीचा प्रकार IKE_SA_INIT आहे, आणि संदेश ID शून्य आहे। बाकी जे काही असेल ते त्याच बोलणीच्या पुढील टप्प्याचे किंवा पूर्णपणे वेगळ्या प्रयत्नाचे।

या पहिल्या देवाणघेवाणीतील प्रस्ताव, की देवाणघेवाण आणि nonce पेलोड उघडपणे वाचनीय आहेत। वाचनीय म्हणजे प्रमाणित नाही, आणि या टप्प्यावर कोणत्याही पक्षाने आपली ओळख सिद्ध केलेली नाही।

खाजगी Diffie-Hellman मूल्य कधीही तारेवरून जात नाही, म्हणून कॅप्चर तुम्हाला सत्र की काढण्यास परवानगी देत नाही। प्रमाणीकरण पुढील देवाणघेवाणीत होते, जे पहिल्याने ठरवलेल्या गोष्टींनी संरक्षित आहे। कोणी विचारले की पक्ष खरा आहे का, तर ही देवाणघेवाण त्या प्रश्नाचे उत्तर देऊ शकत नाही। ती फक्त एवढे दाखवू शकते की दोन्ही बाजूंनी प्रस्तावावर सहमती दिली आणि फाइलमध्ये नसलेले सामायिक रहस्य तयार केले।

तिसरे, विनंतीची तिच्या उत्तराशी जुळणी करा

SPI जोडी, देवाणघेवाणीचा प्रकार आणि संदेश ID वर जुळणी करा, नंतर उत्तराचा ध्वज तपासा। पुनर्प्रसारण मूळचा संदेश ID पुनरावृत्त करते आणि तो दुसरा लॉगिन प्रयत्न नाही। देवाणघेवाणींऐवजी पॅकेट मोजणे हाच मार्ग आहे ज्याने निरोगी बोलणी भुताटकीच्या पळवाटेत बदलते।

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

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

चौथे, 4500 वर IKE ला बाकी सर्वांपासून वेगळे करा

4500 पोर्ट सारांश दृश्यात सारखीच दिसणारी तीन गोष्टी घेऊन जातो: चार-बाइट शून्य non-ESP मार्करच्या मागे IKE, मार्करच्या जागी शून्येतर SPI असलेले एन्कॅप्सुलेटेड ESP, आणि लहान keepalive। IKE ला एन्कॅप्सुलेटेड ESP पासून वेगळे करणारा तोच मार्कर आहे, म्हणून रहदारीला IKE म्हणण्यापूर्वी ते बाइट वाचा। 4500 वाचणारे कॅप्चर लेबल पोर्ट क्रमांक आहे, प्रोटोकॉल नाही।

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

त्याच प्रयत्नासाठी दोन्ही पोर्ट पाहा, कारण NAT ओळखीनंतर IKE 4500 वर जाऊ शकते जरी ते 500 वर उघडले होते। फक्त 500 वर फिल्टर केलेला माग स्पष्टपणे शांत दिसतो तेव्हाच जेव्हा बोलणी यशस्वी होऊन जागा बदलली। फिल्टर रुंद करा आणि अनुपस्थितीवरून कोणताही निष्कर्ष काढण्यापूर्वी तीच वेळ-खिडकी पुन्हा वाचा।

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

क्लायंटवर उत्तर नसणे हे फक्त त्या बिंदूने पाहिलेले सिद्ध करते। फिल्टरिंग, राउटिंग, चुकीचा दूरचा पत्ता, बंद सेवा आणि प्रोटोकॉल असंगती—सर्व तोच कोरडा माग निर्माण करतात।

संबंधित ICMP unreachable पुरावा जोडते, पण त्यातील उद्धृत पॅकेट वाचा आणि ते पाठवणाऱ्या उपकरणाचा पत्ता नोंदवा।

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