कार्यरत IPsec गेटवेबाट ike-scan ले प्रतिक्रिया पाउँदैन

गेटवेले हरेक दिन फोन र ल्यापटपलाई सेवा दिन्छ, तर ike-scan ले कुनै पनि होस्टले जवाफ दिएन भनी रिपोर्ट गर्छ। त्यो आउटपुट यन्त्रमा IPsec छैन भन्ने प्रमाणजस्तो पढिन्छ। सामान्यतया यसको अर्थ यन्त्रले प्रोबमा भएका सबै प्रस्ताव फालिदियो र केही पनि जवाफ नदिन रोज्यो भन्ने हो। मौनता पनि एउटा प्रतिक्रिया हो, र यो उपकरणले तपाईंलाई दिन सक्ने सबैभन्दा कम सूचनामूलक प्रतिक्रिया हो।

तीन अलग प्रश्न क्रमैसँग जाँच्नुहोस्: प्याकेट पुग्यो कि, कुनै प्रस्ताव मिल्यो कि, र अरू केहीले पियरलाई अस्वीकार गर्यो कि?

चरण 1: उपकरणले पठाउने प्रस्ताव पढ्नुहोस्

मुख्य मोड सुरुकर्ताले स्वीकार गर्ने रूपान्तरण सूचीबद्ध गर्ने SA पेलोडबाट सुरु हुन्छ, र ike-scan ले त्यो सूची कम्पाइल गरिएको पूर्वनिर्धारितबाट भर्छ। पूर्वनिर्धारित सेट जानाजान पुरानो छ: इन्क्रिप्सनका लागि DES र 3DES, ह्यासिङका लागि MD5 र SHA1, कुञ्जी आदानप्रदानका लागि समूह 1 र 2, प्रमाणीकरणका लागि पहिल्यै साझा गरिएका कुञ्जीहरू। AES छैन, SHA-2 छैन, समूह 14 छैन। AES-256, SHA-256 र modp2048 का लागि कन्फिगर गरिएको गेटवेसँग यसको केही पनि साझा छैन।

केही कार्यान्वयनले नमिल्ने प्रोबलाई NO-PROPOSAL-CHOSEN सूचनाले जवाफ दिन्छन्। अरूले यसलाई यत्तिकै फालिदिन्छन्, जुन अज्ञात पियरलाई हल्लाको रूपमा लिने उपकरणहरूमा सामान्य छ। जसरी पनि स्क्यानले केही छाप्दैन, र त्यो «केही» बाहिरबाट देखिने फिल्टर गरिएको UDP 500 सँग ठ्याक्कै उस्तै हुन्छ, भनी ike-scan परियोजनाको कागजात ले पूर्वनिर्धारित सेटबारे स्पष्ट पार्छ।

चरण 2: एउटा आधुनिक प्रस्ताव दिनुहोस्

पूर्वनिर्धारित सेटलाई --trans ले बदल्नुहोस्। एट्रिब्युट ढाँचाले IKE एट्रिब्युट नम्बरहरू सिधै लिन्छ: इन्क्रिप्सनका लागि 1, ह्यासका लागि 2, प्रमाणीकरणका लागि 3, समूहका लागि 4 र एल्गोरिदमले लिन्छ भने कुञ्जी लम्बाइका लागि 14। बाहिर आउने कुरा परिवर्तन समीक्षामा ठूलो स्वरले पढ्न सकिने एक लाइन हो।

स्थितिजन्य ढाँचाले तीही मानहरू क्रममा बोक्छ र कोष्ठकबाट बच्छ, जुन आदेश शेलबाट जाँदा महत्त्वपूर्ण हुन्छ।

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

प्रत्येक प्याकेटमा एउटा प्रस्ताव गन्दा ढिलो हुन्छ, त्यसैले सम्भावित मानहरूमा लूप गर्नुहोस्: इन्क्रिप्सन 5, 7/128, 7/192, 7/256; ह्यास 1, 2, 5, 6, 7; समूह 1, 2, 5, 14, 15, 19, 20, 21; प्रमाणीकरण पहिल्यै साझा गरिएको कुञ्जीका लागि 1 र RSA हस्ताक्षरका लागि 3। प्रत्येक आदेश चलाउनुअघि छाप्नुहोस्, ताकि ट्रान्स्क्रिप्टले के प्रस्ताव गरियो र कुन क्रममा भन्ने देखाओस्।

चरण 3: प्रतिक्रियाको व्याख्या गर्नुहोस्

प्रतिक्रियाले ठ्याक्कै दुई कुरा प्रमाणित गर्छ: त्यो ठेगानामा IKE प्रतिक्रियाकर्ता पुग्न सकिन्छ, र प्रस्ताव गरिएको एउटा प्रस्ताव स्वीकार्य थियो। यसले पहिल्यै साझा गरिएको कुञ्जी, L2TP तह वा प्रयोगकर्ता खाता अवस्थित छ कि भन्नेबारे केही भन्दैन। सफल स्क्यान पछिका हरेक चरण असफल हुनुसँग पूर्ण रूपमा मेल खान्छ।

तपाईंले चलाउनुहुने गेटवेमा यो साँच्चै उपयोगी भाग हो। स्क्यानले उपकरणले अझै कुन प्रस्ताव स्वीकार्छ भनी बताउँछ, र पुराना रूपान्तरणमा सीमित नतिजा उपकरण नीतिबारेको खोज हो, क्लाइन्ट कमजोर बनाउने कारण होइन।

चरण 4: मौनताको व्याख्या गर्नुहोस्

मौनता देखिनेभन्दा कमजोर प्रमाण हो। हरेक प्रस्ताव अस्वीकार भएको हुन सक्छ, UDP 500 र 4500 फिल्टर भएका हुन सक्छन्, स्रोत विस्फोटपछि दर-सीमित भएको हुन सक्छ, वा सेवाले तपाईंले स्क्यान गरेको ठेगानाभन्दा फरक ठेगानामा सुनिरहेको हुन सक्छ। त्यो बाकसबारे कुनै निष्कर्ष निकाल्नुअघि गेटवेको IKE लगलाई वैध प्रमाणहरू प्रयोग गरी पहिल्यै जोडिएको क्लाइन्टसँग तुलना गर्नुहोस्।

विस्फोट व्यवहार त्यो सूचीमा पर्छ किनभने गणनाले छोटो अवधिमा धेरै प्याकेट उत्पन्न गर्छ। पहिला प्रयासहरूलाई जवाफ दिएर त्यसपछि चुप हुने गेटवेले आफ्नो प्रस्ताव सेट होइन, आफ्नो anti-DoS नीति वर्णन गरिरहेको हुन्छ।

चरण 5: तपाईंले के प्रमाणित गर्नुभयो त्यो लेख्नुहोस्

स्वीकार गरिएको संयोजन फर्मवेयर संस्करणको छेउमा लेख्नुहोस्, त्यसपछि तपाईंलाई महत्त्वपूर्ण क्लाइन्टहरूले पूर्वनिर्धारित रूपमा दिने रूपान्तरणसँग तुलना गर्नुहोस्। ती दुई सूचीबीचको खाडल नै कन्फिगरेसन समस्या हो, र स्क्यानले त्यसलाई मात्र देखिने बनायो। यदि स्वीकार गरिने प्रस्ताव तपाईंले नरोज्नेहरू मात्र हुन् भने, सुधार गेटवे नीति वा क्लाइन्ट प्रोफाइलमा पर्छ, प्रोबमा कहिल्यै पर्दैन।

कहिल्यै जवाफ नदिएको प्रोबले पनि केही कुराको जवाफ दिएको छ: यो उपकरण कुन प्रस्ताव छलफल गर्न तयार छ र कुनलाई भुइँमा फाल्न रुचाउँछ भनी यसले देखाउँछ।