Check Point या Nortel के सामने vpnc: यह क्यों अटकता है

लक्षण को गलत पढ़ना आसान है: vpnc शुरू होता है, समूह का पासवर्ड माँगता है, और फिर बातचीत के एक चरण पर बैठा रहता है जब तक कि वह न बताए कि लक्ष्य से कोई प्रतिक्रिया नहीं आ रही। आउटपुट में कहीं भी गेटवे उत्पाद का ज़िक्र नहीं है, और खाता ब्राउज़र से काम करता है, इसलिए स्पष्ट निष्कर्ष गलत पासवर्ड या अवरुद्ध पोर्ट है। इनमें से अधिकांश मामलों में गेटवे बिल्कुल भी IPsec साथी नहीं है, इसलिए आदान-प्रदान कभी क्रेडेंशियल जाँचने तक नहीं पहुँचता। प्रोफ़ाइल में कुछ और बदलने से पहले इस पैटर्न को जाँचना उचित है।

प्रोफ़ाइल का कोई और फ़ील्ड संपादित करने से पहले उत्पाद की पहचान करें।

विफलता गलत क्रेडेंशियल जैसी दिखती है

vpnc UDP 500 पर IKE भेजकर शुरू करता है और, यदि NAT ट्रैवर्सल प्रस्तावित हो, तो UDP 4500 पर। जो गेटवे IPsec के बजाय SSL समाप्त करता है, वह दोनों में से किसी को उत्तर नहीं देता, इसलिए क्लाइंट फिर से प्रयास करता है और अंत में सामान्य त्रुटि के साथ हार मान लेता है। यदि वही खाता एक ब्राउज़र पोर्टल से काम करता है जो एक छोटा सहायक ऐप्लिकेशन लोड करता है, तो यह प्रबल संकेत है कि सुरंग SSL आधारित है और क्लाइंट गलत सवाल पूछ रहा है।

यहाँ असफल प्रयास उपयोगकर्ता खाते के बारे में कुछ नहीं कहता, क्योंकि गेटवे को कभी कोई क्रेडेंशियल प्रस्तुत नहीं किया गया।

जाँचें कि गेटवे कौन-सा प्रोटोकॉल प्रदान करता है

दो मिनट की जाँच IPsec साथी को SSL पोर्टल से अलग करती है। इन्हें उसी नेटवर्क से चलाएँ जिसे क्लाइंट उपयोग करेगा, और पढ़ें कि कौन-से पोर्ट उत्तर देते हैं, न कि कौन-से किसी दस्तावेज़ में दिखते हैं। परिणाम रखें, क्योंकि वही पोर्ट तय करते हैं कि गेटवे के मालिक को कौन-सा क्लाइंट समर्थन देना चाहिए। गेटवे के पास के होस्ट से नहीं, क्लाइंट नेटवर्क से जाँचें।

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

लॉगिन पृष्ठ पर रीडायरेक्ट के साथ खुला 443 और 500 तथा 4500 पर सन्नाटा SSL VPN की ओर इशारा करता है। 443 पर प्रदान किए गए प्रमाणपत्र के साथ 500 और 4500 खुले हों तो यह ऐसे IPsec गेटवे का संकेत है जो वेब फ्रंटएंड भी चलाता है, और vpnc ठीक इसी स्थिति के लिए बनाया गया था।

Check Point का SSL Network Extender और Nortel का Aventail क्लाइंट दोनों दूसरी श्रेणी में आते हैं, और इनमें से कोई भी IKEv1 समूह रहस्य स्वीकार नहीं करता।

vpnc प्रोफ़ाइल क्या व्यक्त कर सकता है और क्या नहीं

अंदर से vpnc समूह की पूर्व-साझा कुंजी के सामने IKEv1 चलाता है, फिर XAuth के माध्यम से व्यक्तिगत उपयोगकर्ता के क्रेडेंशियल भेजता है। उसकी कॉन्फ़िगरेशन फ़ाइल में सब कुछ उसी आदान-प्रदान का है: गेटवे, समूह का नाम, समूह रहस्य, उपयोगकर्ता नाम और उपयोगकर्ता पासवर्ड। ये फ़ील्ड एक ही प्रोटोकॉल का वर्णन करते हैं, और इनका कोई संयोजन क्लाइंट को दूसरा प्रोटोकॉल बोलने पर विवश नहीं कर सकता।

इसीलिए सिफ़र सूची बढ़ाना या प्रमाणपत्र जाँच बंद करना इस प्रकार की विफलता को कभी नहीं सुधारता। वे परिवर्तन ऐसी बातचीत को कमज़ोर करते हैं जिसे गेटवे सुन ही नहीं रहा।

गेटवे से मेल खाने वाला क्लाइंट चुनना

Check Point गेटवे के लिए उस गेटवे संस्करण के लिए बनाया गया SNX पैकेज उपयोग करें, जिसे विक्रेता अपने दूरस्थ पहुँच दस्तावेज़ीकरण के साथ प्रकाशित करता है। पुराने SNX बिल्ड वर्तमान वितरणों पर अक्सर विफल होते हैं क्योंकि वे 32-bit लाइब्रेरी अपेक्षित करते हैं जो अब स्थापित नहीं हैं, और परित्यक्त पैकेज को पैच करना आम तौर पर समर्थित प्लेटफ़ॉर्म पर समर्थित क्लाइंट चलाने से बुरा है।

Aventail क्लाइंट ने बहुत पहले समर्थन खो दिया। जहाँ ऐसा गेटवे अभी भी सेवा में है, वहाँ वास्तविक विकल्प ब्राउज़र पोर्टल है यदि संगठन उसे सक्षम करता है, या समर्थित ऑपरेटिंग सिस्टम पर विक्रेता का समर्थित क्लाइंट।

गेटवे के मालिक से उत्पाद और संस्करण, Linux पर उनके द्वारा समर्थित क्लाइंट, और यह पूछें कि क्या कोई IPsec प्रोफ़ाइल है ही। यदि है, तो समूह पहचानकर्ता और समूह रहस्य अलग-अलग मदों के रूप में माँगें, क्योंकि वे उपयोगकर्ता पासवर्ड नहीं हैं और अदल-बदल की गई जोड़ी असफल सुरंग का दूसरा सामान्य कारण है। जब कनेक्शन आख़िरकार सफल हो, तो दर्ज करें कि कौन-सा प्रोटोकॉल तय हुआ, ताकि अगला व्यक्ति उसी अनुमान को दोहराने के बजाय तथ्य से शुरू करे।