पैकेट कैप्चर में पहले 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

उसी प्रयास को सर्वर-पक्ष लॉग से उन जगहों पर मिलाएँ जहाँ आपको उन्हें पढ़ने की अनुमति है। क्या अनुरोध पहुँचा, क्या सेवा ने उत्तर दिया, और उत्तर कहाँ रुका? वे तीन उत्तर आपको मार्ग की समस्या या नीति की समस्या की ओर भेजते हैं, और उनका खर्च चौथी बार क्रेडेंशियल बदलने से कम है।