कैप्चर में नया 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, एनकैप्सुलेटेड ESP जिसके मार्कर की जगह शून्येतर SPI है, और छोटे keepalive। वही मार्कर IKE को एनकैप्सुलेटेड ESP से अलग करता है, इसलिए ट्रैफ़िक को IKE कहने से पहले वे बाइट पढ़ें। 4500 पढ़ने वाला कैप्चर लेबल पोर्ट संख्या है, प्रोटोकॉल नहीं।

एनकैप्सुलेटेड ESP एन्क्रिप्टेड पेलोड है जिसे कुंजियों के बिना समझा नहीं जा सकता, और इसकी उपस्थिति खराबी के बजाय काम करती टनल का संकेत हो सकती है।

उसी प्रयास के लिए दोनों पोर्ट देखें, क्योंकि NAT पहचान के बाद IKE 4500 पर जा सकता है चाहे वह 500 पर खुला हो। केवल 500 पर फ़िल्टर किया गया ट्रेस ठीक तब शांत दिखता है जब बातचीत सफल होकर स्थान बदल चुकी हो। फ़िल्टर चौड़ा करें और अनुपस्थिति से कोई निष्कर्ष निकालने से पहले वही समय-खिड़की फिर पढ़ें।

एक अवलोकन बिंदु पर मौन का अर्थ

क्लाइंट पर जवाब न होना केवल वही साबित करता है जो उस बिंदु ने देखा। फ़िल्टरिंग, रूटिंग, गलत दूरस्थ पता, बंद सेवा और प्रोटोकॉल असंगति—सब वही खाली ट्रेस पैदा करते हैं।

प्रासंगिक ICMP unreachable साक्ष्य जोड़ता है, पर उसके अंदर उद्धृत पैकेट पढ़ें और भेजने वाले उपकरण का पता नोट करें।

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