आपका ऑपरेटिंग सिस्टम पहले से कौन-से VPN प्रोटोकॉल समझता है?

दूसरा क्लाइंट डाउनलोड करने से पहले देखें कि ऑपरेटिंग सिस्टम पहले से क्या लागू करता है, क्योंकि जवाब अक्सर इंस्टॉलर को पूरी तरह छोड़ देने के लिए काफी होता है। Windows, macOS और ChromeOS में से हर एक के साथ टनल प्रोटोकॉल की एक स्थिर और छोटी सूची आती है, और इनमें से किसी एक को बोलने वाले गेटवे को कोई अतिरिक्त ड्राइवर, सेवा या अपडेट पथ नहीं चाहिए। इसे ब्रोशर पर लिखे विक्रेता के नाम से तय नहीं होता। इसे प्रोटोकॉल तय करता है, यह कि एंडपॉइंट कैसे प्रमाणित करता है, और यह कि वह किस पते की अपेक्षा करता है।

प्रोटोकॉल माँगें, उत्पाद का नाम नहीं

उत्पाद का नाम इस बारे में बहुत कम कहता है कि तार पर क्या जाता है। एक ही लेबल के तहत बिकने वाले दो गेटवे पूरी तरह अलग टनल माँग सकते हैं, और एक अंतर्निहित क्लाइंट स्वीकार कर सकता है जबकि दूसरा अपने पोर्टल के अलावा सब कुछ मना कर देता है। एक ही बॉक्स का वर्णन करने वाले दो प्रशासक असहमत हो सकते हैं और दोनों सही हो सकते हैं, क्योंकि वे अलग परतों का वर्णन करते हैं। नीचे की टनल ही तय करती है कि इंस्टॉलर चाहिए या नहीं।

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

इतनी सारी टिकटों में उत्पाद का नाम टिके रहने की एक वजह है। पोर्टल का URL ही उपयोगकर्ता देखते हैं, और टनल तब तक अदृश्य रहती है जब तक काम करती है। हैंडओवर नोट में प्रोटोकॉल लिखने में एक पंक्ति लगती है और बाद में आने वाले हर किसी के लिए अस्पष्टता हट जाती है।

अंतर्निहित सूची कहाँ रुकती है

मूल सूचियाँ छोटी हैं, और उनके किनारे उनकी सामग्री से ज़्यादा मायने रखते हैं। जो प्लेटफ़ॉर्म IPsec पर L2TP पहले से साझा कुंजी के साथ बोलता है, वह SSTP नहीं बोलेगा, और यही अंतर क्लाइंट तय करता है। तालिका विक्रेता के बजाय टनल के अनुसार क्रमबद्ध है, इसलिए आप गेटवे द्वारा बताया गया प्रोटोकॉल खोज सकते हैं।

ग्रिड को ब्रोशर के बजाय गेटवे की आवश्यकताओं के सामने पढ़ें। अगर जवाब पहले से साझा कुंजी के साथ 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 हार्डवेयर पर बने परिनियोजन अक्सर वहीं पहुँचते हैं, और उनमें अंतर्निहित क्लाइंट शॉर्टकट नहीं है। तीसरे पक्ष का प्रतिस्थापन जुड़ सकता है और फिर भी नीति का उल्लंघन कर सकता है, जो इसे सुविधा के बजाय सुरक्षा का निर्णय बनाता है। नीति जो माँगती है वह इंस्टॉल करें और इंस्टॉलर संस्करण के पास कारण लिखें।

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