क्याप्चरमा नयाँ IKE_SA_INIT आदानप्रदान कसरी पढ्ने
नयाँ IKEv2 वार्तालाप कुञ्जी बन्नुअघि नै पढ्न सकिन्छ। प्रयास क्याप्चर गर्नुहोस्, हेडर पढ्नुहोस्, जवाफ मिलाउनुहोस् र 4500 पोर्टमा IKE लाई ESP बाट छुट्याउनुहोस्।
प्रयासको पहिलो प्याकेटभन्दा अघि सुरु हुने क्याप्चरबाट सुरु गर्नुहोस्, नत्र तपाईं कुराकानीको बीच पढ्नुहुनेछ। पहिले नै चलिरहेको वार्तालाप एन्क्रिप्टेड आदानप्रदान र कुञ्जी नवीकरण देखाउँछ, र तीमध्ये कुनै पनि सुरुवातजस्तो देखिँदैन। सुरुवात त्यो भाग हो जुन कुञ्जीबिना डिकोड गर्न सकिन्छ, त्यसैले यसले पहुँचसम्बन्धी प्रश्नको यति राम्रो जवाफ दिन्छ। क्रमैसँग चार जाँचले तपाईंलाई ताजा क्याप्चरबाट कुन पक्षले बोल्न छोड्यो भन्ने तर्कसंगत भनाइसम्म पुर्याउँछ।
पहिले, क्याप्चर सुरुदेखि नै सुरु भएको पुष्टि गर्नुहोस्
टनेल उठेपछि सुरु भएको क्याप्चरमा इन्क्याप्सुलेटेड डेटा स्ट्रिम र नियमित 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 प्रमाण थप्छ, तर त्यभित्रको उद्धृत प्याकेट पढ्नुहोस् र पठाउने यन्त्रको ठेगाना नोट गर्नुहोस्।
राउटरको अस्वीकृति पक्षले फर्काएको प्रमाणित त्रुटिभन्दा फरक घटना हो, र सेवा जीवित छ भन्ने दोस्रोले मात्र प्रमाणित गर्छ। त्यही प्रयासलाई सर्भर लग वा स्वीकृत अवलोकनसँग जोड्नुहोस् ताकि अनुरोध आयो कि र जवाफ गयो कि थाहा होस्। क्याप्चर सीमित र निजी राख्नुहोस्, किनकि पढ्न सकिने ह्यान्डशेक फिल्डले बाँकी फाइललाई हानिरहित बनाउँदैन। मूल्यवान नतिजा एउटा मिलाइएको अनुरोध र जवाफ, वा नाम दिइएको अवलोकन बिन्दुसहित एउटा अभिलेखित खाडल हो।