ike-scan काम कर रहे IPsec गेटवे से कोई उत्तर नहीं पाता

गेटवे हर दिन फ़ोन और लैपटॉप को सेवा देता है, फिर भी 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: जो आपने सिद्ध किया उसे दर्ज करें

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

जिस जाँच ने कभी उत्तर नहीं दिया, उसने फिर भी कुछ उत्तर दिया: यह दिखाता है कि यह डिवाइस किन प्रस्तावों पर चर्चा करने को तैयार है, और किन्हें ज़मीन पर गिराना पसंद करता है।