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 प्रोफाइल छ कि छैन सोध्नुहोस्। छ भने, समूह पहिचानकर्ता र समूह गोप्य अलग-अलग बुँदाका रूपमा माग्नुहोस्, किनकि ती प्रयोगकर्ता पासवर्ड होइनन्, र अदलबदल भएको जोडी असफल सुरुङको अर्को सामान्य कारण हो। जब जडान अन्तमा सफल हुन्छ, कुन प्रोटोकल तय भयो लेख्नुहोस्, ताकि अर्को व्यक्तिले त्यही अनुमान दोहोर्याउनुभन्दा तथ्यबाट सुरु गरोस्।