अवकाशप्राप्त VPN क्लाइन्टहरू: पहिले गेटवे प्रोटोकल पहिचान गर्नुहोस्
Cisco VPN Client, Junos Pulse, SonicWall GVC र Shrew Soft अब समर्थित छैनन्। उत्तराधिकारी क्लाइन्ट छान्नु अघि गेटवे प्रोटोकल पहिचान गर्नुहोस्।
वर्षौं अघि सेवा अन्त्य भएका VPN क्लाइन्टका इन्स्टलरहरू अझै चल्छन्, अझै प्रोफाइल माग्छन्, र त्यसपछि एउटै प्याकेट पनि नपठाउने लगइन पूरा गर्छन्। मेसिन अद्यावधिक छ र प्रमाणहरू सही छन्, तैपनि गेटवे कम्पनीले दशक अघि किनेको त्यही उपकरण हो। क्लाइन्ट बदल्नु सही कदम हो, तर त्यो गेटवेले कुन प्रोटोकल प्रकाशित गर्छ भन्ने थाहा पाएपछि मात्र। यस कुनाका चार अवकाशप्राप्त क्लाइन्ट एउटै प्रोटोकल बोल्दैनन्।
किन ब्रान्ड नामले प्रोटोकल बताउँदैन
एउटा उपकरण परिवारले धेरै रिमोट-पहुँच प्रोटोकल अन्त्य गर्न सक्छ, र बाकसमा लेखिएको मार्केटिङ नामले तपाईंको खाताले कुन प्रयोग गर्छ भन्ने बारे केही बताउँदैन। Cisco का उपकरणहरूले एकै समयमा XAuth सहित IPsec र SSL VPN AnyConnect मार्फत बोकेका छन्; SonicWall बाकसहरूले IPsec माथि Global VPN Client र SSL VPN माथि NetExtender दिन्छन्; Juniper परिनियोजनहरूले Network Connect वा नयाँ Pulse प्रोटोकल खोल्न सक्छन्। सबैभन्दा आधुनिक देखिने उत्तराधिकारी स्थापना गर्नु अनुमान हो। गलत अनुमानले या त जोडिँदैन या ट्राफिक नबोक्ने सत्रमा प्रमाणित गर्छ।
ब्राउजरमा पोर्टल पृष्ठ लोड हुनुले वेब सेवा जवाफ दिइरहेको प्रमाणित गर्छ, कुनै निश्चित क्लाइन्टले त्यससँग वार्ता गर्नेछ भन्ने होइन। यी दुईलाई छुट्टाछुट्टै तथ्य मान्नुहोस्।
गेटवेसँग सोध्नुहोस् कि यो के बोल्छ
विकल्पहरू साँघुरो पार्ने सबैभन्दा सस्तो तरिका भनेको एन्डपोइन्टले के फर्काउँछ पढ्नु हो, र त्यसपछि क्लाइन्ट प्रयास गर्दा प्रोटोकल स्पष्ट रूपमा नाम दिनु हो। दुवैमध्ये कुनै कदमले सर्भरमा केही बदल्दैन।
curl -sS -I https://vpn.example.com/ | head -n 5
openconnect --protocol=anyconnect vpn.example.comप्रतिक्रिया हेडर र लगइन मार्गले त्यो ठेगानामा SSL VPN पोर्टल छ कि भनेर देखाउँछ, जसले IPsec क्लाइन्टको सट्टा AnyConnect, NetExtender वा Pulse तर्फ संकेत गर्छ। openconnect ले प्रोटोकल छनोट कमाण्ड लाइनमा राख्छ, त्यसैले असफलताले उत्पादनको होइन, प्रोटोकलको नाम भन्छ; परिनियोजन Juniper भए --protocol=npulse प्रयोग गर्नुहोस्। तपाईंलाई दिइएका छैनन् त्यस्ता प्रमाणहरू माग्ने पहिलो सङ्केतमै रोकिनुहोस्, किनकि चल्ने टनेललाई पनि स्वीकृत खाता चाहिन्छ। अर्को मेसिनका लागि परिवर्तन टिकटमा प्रोटोकल र मार्ग लेख्नुहोस्।
प्रतिस्थापनका चार उम्मेदवार तौलनुहोस्
चार मार्गहरूले लगभग हरेक अवस्था ढाक्छन्, र ती एक-अर्काको सट्टा प्रयोग गर्न मिल्दैन। संस्थाले गेटवेको स्वामित्व राख्ने र इजाजतपत्र दिन तयार भएको बेला विक्रेताको उत्तराधिकारी समर्थित मार्ग हो। OpenConnect व्यावहारिक खुला क्लाइन्ट हो, किनकि प्रोटोकल अनुमान गर्न दिनुको सट्टा नाम दिँदा यसले AnyConnect, Network Connect र Pulse सँग बोल्छ।
strongSwan ले तेस्रो-पक्ष क्लाइन्टलाई अनुमति दिने संस्थाहरूका लागि IPsec-XAuth अवस्था सम्हाल्छ, र त्यागिएको Cisco IPsec कोडलाई पूर्ण रूपमा बेवास्ता गर्छ। Shrew Soft क्लाइन्टले Cisco प्रोफाइल फाइलहरू पढ्न जारी राख्छ र केही Windows बिल्डमा चल्छ, तर यसको अन्तिम रिलिज 2013 मा थियो। समर्थित मार्ग मिलाइएसम्म यसलाई अस्थायी उपाय मान्नुहोस्।
मर्मत र प्रतिस्थापनबीच निर्णय गर्नुहोस्
केही असफलता स्थानीय हुन्छन्: हराएको लाइब्रेरी, पुरानो भर्चुअल एडाप्टर, वा विक्रेताको मर्मत विकल्प चाहिने इन्स्टलर। क्लाइन्ट समर्थित रहेसम्म यी एक प्रयासको योग्य छन्, किनकि केही मिनेट मात्र लाग्छ। बाइनरी समर्थनबाहिर भएर खराबी अपरेटिङ सिस्टम अपग्रेडसँगै आएको बेला गणना बदलिन्छ, किनकि यी क्लाइन्ट लेखिएपछि ड्राइभर हस्ताक्षर र कर्नेल विस्तारका नियम बदलिएका छन्। टनेल काउन्टरले शून्य स्थापित सत्र देखाउँदा जोडिने क्लाइन्ट सामान्यतया मर्मतभन्दा पर हुन्छ, एक पुनःस्थापना टाढा होइन।
पुरानो क्लाइन्टलाई यसको प्रोफाइल निर्यात गर्न पुग्ने जति मात्र स्थापित राख्नुहोस्, त्यसपछि हटाउनुहोस्। एउटै मार्गका लागि प्रतिस्पर्धा गर्ने दुई VPN क्लाइन्टले कुनैसँग पनि नमिल्ने लक्षण उत्पन्न गर्छन्।
टिकटमा क्रम लेख्नुहोस्: मालिकबाट प्रोटोकल र स्वीकृत क्लाइन्ट, स्थापना भए समर्थित उत्तराधिकारी, नभए एउटै मेसिनमा परीक्षण गरिएको एक खुला क्लाइन्ट, र दुवैमध्ये केही नचले समर्थित पहुँच मार्ग। यो क्रमले अर्को व्यक्तिलाई अर्को अवकाशप्राप्त बाइनरी डाउनलोड गर्नबाट रोक्छ।