कार्यरत 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: तुम्ही काय सिद्ध केले ते नोंदवा

स्वीकारलेले संयोजन फर्मवेअर आवृत्तीच्या पुढे लिहा, नंतर तुम्हाला महत्त्वाच्या क्लायंट डीफॉल्टने देऊ करतात त्या ट्रान्सफॉर्मशी त्याची तुलना करा। त्या दोन याद्यांमधील अंतर हीच संरचना समस्या आहे, आणि स्कॅनने ती फक्त दृश्यमान केली। स्वीकारले जाणारे प्रस्ताव तुम्ही निवडले नसते असेच असतील, तर दुरुस्ती गेटवे धोरणात किंवा क्लायंट प्रोफाइलमध्ये असते, प्रोबमध्ये कधीही नाही।

कधीही उत्तर न देणाऱ्या प्रोबनेही काहीतरी उत्तर दिले: हे उपकरण कोणते प्रस्ताव चर्चा करण्यास तयार आहे आणि कोणते जमिनीवर टाकायला आवडेल हे ते दाखवते।