अर्को क्लाइन्ट डाउनलोड गर्नु अघि अपरेटिङ सिस्टमले पहिले नै के लागू गर्छ हेर्नुहोस्, किनकि उत्तरले प्रायः इन्स्टलर पूर्ण रूपमा छोड्न पर्याप्त हुन्छ। Windows, macOS र ChromeOS प्रत्येकले स्थिर र छोटो सुरुङ प्रोटोकल सूची ल्याउँछ, र तीमध्ये एउटा बोल्ने गेटवेलाई थप ड्राइभर, सेवा वा अद्यावधिक मार्ग आवश्यक पर्दैन। यो ब्रोसरमा लेखिएको आपूर्तिकर्ताको नामले निर्धारण गर्दैन। यो प्रोटोकलले, अन्त्य बिन्दुले कसरी प्रमाणित गर्छ र कुन ठेगाना अपेक्षा गर्छ भन्नेले निर्धारण गर्छ।

प्रोटोकल सोध्नुहोस्, उत्पादनको नाम होइन

उत्पादनको नामले तारबाट के जान्छ भन्नेबारे धेरै थोरै भन्छ। एउटै लेबलमुनि बेचिने दुई गेटवेले पूर्ण रूपमा भिन्न सुरुङ माग्न सक्छन्, र एउटाले अन्तर्निहित क्लाइन्ट स्वीकार गर्न सक्छ जबकि अर्कोले आफ्नै पोर्टलबाहेक सबै अस्वीकार गर्छ। एउटै बाकसको वर्णन गर्ने दुई प्रशासक असहमत हुन सक्छन् र दुवै सही हुन सक्छन्, किनकि तिनीहरू फरक तहको वर्णन गर्छन्। तलको सुरुङले नै इन्स्टलर आवश्यक छ कि छैन निर्धारण गर्छ।

गेटवे चलाउनेलाई तीन प्रश्न सोध्नुहोस्: कुन सुरुङ प्रोटोकल, कुन प्रमाणीकरण विधि, र क्लाइन्टले कुन ठेगाना र DNS प्रत्यय स्वीकार गर्नुपर्छ। प्रोटोकल नामले सोध्नुहोस्, र उत्तर उत्पादनको नामको रूपमा आएमा तपाईंलाई प्रोटोकल किन चाहिन्छ भनी व्याख्या गर्नुहोस्। ती तीन उत्तरले कुनै पनि सफ्टवेयर डाउनलोड हुनु अघि क्लाइन्टको प्रश्न टुङ्गोमा पुर्याउँछन्।

यति धेरै टिकटमा उत्पादनको नाम टिकिरहनुको कारण छ। पोर्टलको URL प्रयोगकर्ताले देख्ने कुरा हो, र सुरुङ काम गर्दा अदृश्य हुन्छ। हस्तान्तरण नोटमा प्रोटोकल लेख्न एक लाइन लाग्छ र पछि आउने सबैका लागि अस्पष्टता हटाउँछ।

अन्तर्निहित सूची कहाँ रोकिन्छ

मौलिक सूचीहरू छोटा छन्, र तिनका किनारा तिनका सामग्रीभन्दा महत्त्वपूर्ण छन्। IPsec माथि L2TP पहिले नै साझा गरिएको कुञ्जीसँग बोल्ने प्लेटफर्मले SSTP बोल्दैन, र त्यही भिन्नताले क्लाइन्ट निर्धारण गर्छ। तालिका आपूर्तिकर्ताअनुसार नभई सुरुङअनुसार मिलाइएको छ, त्यसैले गेटवेले नाम दिएको प्रोटोकल खोज्न सक्नुहुन्छ।

TunnelWindowsmacOSChromeOSLinux
PPTPbuilt inremoved in 10.12nopackage
L2TP over IPsec, pre-shared keybuilt inbuilt inbuilt inpackage
L2TP over IPsec, certificatebuilt inbuilt inbuilt inpackage
SSTPbuilt innonopackage
IKEv2built inbuilt innopackage
Cisco IPsec with XAuthnobuilt innopackage
OpenVPNnonobuilt inpackage

तालिका ब्रोसरसँग नभई गेटवेका आवश्यकतासँग तुलना गरेर पढ्नुहोस्। उत्तर पहिले नै साझा गरिएको कुञ्जीसहित L2TP over IPsec भए, पहिला तीन प्लेटफर्म थप केही नइन्स्टल गरी जोडिन्छन्। उत्तर OpenVPN भए, केही इन्स्टल गर्नु अघि ChromeOS मात्र समेटिएको छ। कुनै पनि अन्तर्निहित स्तम्भमा नदेखिने प्रोटोकल इन्स्टलर आउँदै छ भन्ने इमानदार सङ्केत हो।

Linux सामान्यीकरणको प्रतिरोध गर्ने स्तम्भ हो। यसको प्रोटोकल समर्थन वितरणले प्याकेज गर्न छान्ने डेमन र प्लगइनमा बस्छ, त्यसैले न्यूनतम इमेजले तपाईंले थप्नुअघि तीमध्ये कुनै पनि नबोल्न सक्छ, र एउटै डेस्कटप भएका दुई वितरण फरक हुन सक्छन्।

कमाण्ड लाइनबाट प्रोफाइल बनाउनुहोस्

ग्राफिकल प्यानलले लेख्ने सबै तपाईं पुग्न सक्ने ठाउँमा भण्डारण हुन्छ, र यसैले अन्तर्निहित प्रोफाइल स्वचालित बनाउँछ। Windows ले VPN प्रविष्टिहरू .pbk फाइलमा प्रयोगकर्ता प्रोफाइलमुनि र ProgramData मुनि राख्छ, र rasphone ले नेटवर्क सूचीले नदेखाउने प्रविष्टि सूचीबद्ध र सम्पादन गर्न सक्छ। मेसिन स्क्रिप्टले तयार हुँदा र कसैले विजार्डमा क्लिक नगर्दा यो महत्त्वपूर्ण हुन्छ। प्रोफाइल कहिल्यै ट्रेमा नदेखिई कसरी रहन सक्छ भन्ने पनि यसले व्याख्या गर्छ।

rasdial
rasdial "VpnName" alice
rasdial "VpnName" /disconnect

हातले .pbk फाइल सम्पादन गर्न काम गर्छ, र त्यो यसलाई बिगार्ने सबैभन्दा छिटो तरिका पनि हो, त्यसैले ढाँचा उपकरणकै रहन दिनुहोस्। macOS ले आफ्ना सेवाहरू प्रणाली कन्फिगरेसनमा राख्छ, र networksetup ले तिनलाई सेवाको नामले सम्बोधन गर्छ; केही फ्ल्यागले होस्टनामको सट्टा ठेगाना चाहन्छन्, त्यसैले पहिले अन्त्य बिन्दु समाधान गरी क्लाइन्टले वास्तवमा प्रयोग गर्ने मान भण्डारण गर्नुहोस्। त्यो भिन्नताले स्वचालनमा टोक्छ, किनकि ठेगानासँग काम गर्ने स्क्रिप्ट नामसँग असफल हुन सक्छ, र त्रुटि अस्वीकृत आर्गुमेन्टजस्तो नभई बिग्रिएको गेटवेजस्तो देखिन्छ।

networksetup -listallnetworkservices
networksetup -getinfo "ServiceName"
networksetup -setmanualwithdhcprouter "ServiceName" 198.51.100.20

सेवाका नाम स्थानीयकृत र प्रयोगकर्ताद्वारा सम्पादनयोग्य छन्, त्यसैले Wi-Fi हार्डकोड गर्ने स्क्रिप्ट अर्को भाषामा सेट गरिएको पहिलो मेसिनमा टुट्छ। सूची आदेशबाट नाम पढ्नुहोस् र अनुमान गर्नुको सट्टा अगाडि पठाउनुहोस्।

स्वामित्वको क्लाइन्टबिना प्रमाणपत्रहरू

केही परिनियोजनलाई क्लाइन्ट प्रमाणपत्र चाहिन्छ र अरू केही स्वामित्वको हुँदैन, र ड्राइभर स्वीकार गर्नु अघि परीक्षण गर्न लायकको मध्य अवस्था यही हो। प्लेटफर्मको स्टोरमा प्रमाणपत्र राख्नु समर्थित छ; यो आपूर्तिकर्ताको जरा हालेर क्लाइन्टले भेट्टाउँछ भन्ने आशा गर्नुजस्तै कार्य होइन। पहिलो जानाजान राख्नु हो; दोस्रो सहयोग टिकट टाँसिएको अनुमान हो।

मानिसलाई समात्ने विवरण भनेको क्लाइन्टले कुन स्टोर पढ्छ भन्ने हो। प्रयोगकर्ता स्टोरको प्रमाणपत्र मेसिन स्टोरका लागि कन्फिगर गरिएको क्लाइन्टलाई अदृश्य हुन्छ, र प्राप्त सन्देशले प्रमाणपत्र हराएको भन्छ, गलत ठाउँमा छ भन्दैन। प्रमाणपत्र गलत छ भन्ने निष्कर्षमा पुग्नु अघि दुवै स्टोर जाँच्नुहोस्। काम गर्ने कन्फिगरेसनले कुन प्रयोग गर्छ लेख्नुहोस्, किनकि मेसिन पुनर्निर्माण हुँदा त्यो टिप्पणी प्रमाणपत्रभन्दा बढी टिक्छ।

Windows ले दुई स्टोर स्पष्ट रूपमा अलग गर्छ, र macOS ले लगइन किचेनलाई प्रणाली किचेनबाट अलग गर्छ। नाम फरक छन्, तर असफलताको ढाँचा उस्तै छ: एउटा वैध प्रमाणपत्र जसलाई क्लाइन्टले कहिल्यै हेर्दैन।

के ले इन्स्टलर बाध्यकारी बनाउँछ

केही गेटवेले क्लाइन्टलाई निजी प्रमाणपत्र स्टोर, पोस्चर एजेन्ट, वा अपरेटिङ सिस्टमले गर्न नसक्ने साइन-अन आदानप्रदानसँग बाँध्छन्। Check Point, Cisco वा Fortinet हार्डवेयरमा बनेका परिनियोजन प्रायः त्यहीँ पुग्छन्, र तिनमा अन्तर्निहित क्लाइन्ट सर्टकट होइन। तेस्रो पक्षको प्रतिस्थापन जोडिन सक्छ र तैपनि नीति उल्लङ्घन गर्न सक्छ, जसले यसलाई सुविधाको निर्णय नभई सुरक्षाको निर्णय बनाउँछ। नीतिले मागेको इन्स्टल गर्नुहोस् र इन्स्टलर संस्करणको छेउमा कारण लेख्नुहोस्।

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

सम्बन्धित लेखहरू