प्याकेट क्याप्चरमा पहिलो 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

पढ्न अनुमति भएको ठाउँमा त्यही प्रयासलाई सर्भर-पक्षको लगसँग जोड्नुहोस्। अनुरोध पुग्यो, सेवाले जवाफ दियो, र जवाफ कहाँ रोकियो? ती तीन जवाफले तपाईंलाई मार्गको समस्या वा नीतिको समस्यातर्फ पठाउँछन्, र चौथो पटक प्रमाणपत्र बदल्नुभन्दा कम खर्चिला हुन्छन्।