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 प्रोफाइल अजिबात आहे का विचारा। असल्यास, गट ओळखकर्ता आणि गट रहस्य वेगवेगळ्या बाबी म्हणून मागा, कारण ते वापरकर्ता संकेतशब्द नाहीत आणि अदलाबदल झालेली जोडी अयशस्वी सुरंगाचे दुसरे सामान्य कारण आहे। जेव्हा कनेक्शन शेवटी यशस्वी होईल, तेव्हा कोणता प्रोटोकॉल ठरला ते नोंदवा, जेणेकरून पुढील व्यक्ती तोच अंदाज पुन्हा न करता तथ्यापासून सुरुवात करेल।