ट्यूटोरियल कहता है RemoteEnable चलाएँ और फिर कनेक्ट करें, और यह ऐसा पढ़ा जाता है जैसे ये दो चरण एक ही तरह की चीज़ हों। वे नहीं हैं। RemoteEnable किसी दूसरी मशीन को इस कंप्यूटर पर चल रही SoftEther VPN क्लाइंट सेवा का प्रशासन करने की अनुमति देता है। जबकि कनेक्ट करना एक VPN खाता है जो किसी सर्वर से प्रमाणित होता है, और इसमें कोई प्रबंधन अनुमति शामिल ही नहीं है।

भ्रम: RemoteEnable VPN चालू करता है

भ्रम निकटता से आता है। कोई मार्गदर्शिका दूरस्थ प्रबंधन चालू करती है, क्लाइंट सेवा को पुनः आरंभ करती है, फिर कनेक्ट करती है, और कनेक्शन बाद में काम करता है, इसलिए दोनों चरण कारण-संबंधित लगते हैं। वास्तव में जो बदला वह यह है कि सेवा से कौन बात कर सकता है, न कि यह कि सेवा किसी सर्वर तक पहुँच सकती है या नहीं। सही ढंग से कॉन्फ़िगर किए गए क्लाइंट पर दूरस्थ प्रबंधन बंद करें और VPN कनेक्शन फिर भी बनता है।

मूल स्रोत में कमांड सहायता दायरे के बारे में स्पष्ट है: VPN Client Manager या vpncmd के ज़रिए localhost के बाहर से दूरस्थ प्रबंधन। उस विवरण में किसी टनल, खाते या मार्ग का ज़िक्र नहीं है। दी जाने वाली अनुमति प्रशासनिक पहुँच है, और उसका विषय कनेक्शन नहीं बल्कि क्लाइंट सेवा है।

एक ही पासवर्ड शब्द साझा करती तीन पहचानें

पुरानी मार्गदर्शिकाएँ तीन असंबंधित क्रेडेंशियल के लिए एक ही शब्द इस्तेमाल करती हैं, और इसी तरह परिनियोजन गलत फ़ील्ड में चिपके रहस्य के साथ समाप्त होते हैं।

क्लाइंट सेवा का प्रबंधन पासवर्ड स्थानीय SoftEther क्लाइंट के प्रशासन की रक्षा करता है। VPN खाते का पासवर्ड उस सर्वर की नीति के अंतर्गत सर्वर से प्रमाणित होता है। सर्वर प्रमाणपत्र पासवर्ड तो बिल्कुल नहीं है, पर वह बताता है कि क्लाइंट को कौन-सा अंतिम बिंदु स्वीकार करना चाहिए। इनमें से एक बदलने से बाकी नहीं बदलते, और उनके बीच कोई मान कॉपी करने से सरल नहीं बल्कि अलग कॉन्फ़िगरेशन बनता है।

प्रबंधन पासवर्ड पर केवल-दूरस्थ विकल्प दूसरी नज़र का हक़दार है, क्योंकि यह तय करता है कि पासवर्ड की आवश्यकता स्थानीय मशीन से प्रबंधन पर भी लागू होती है या नहीं। उस दायरे को संकरा करना एकल-उपयोगकर्ता लैपटॉप के लिए जानबूझकर लिया गया निर्णय है, किसी ऐसे पासवर्ड का बहाना नहीं जिसे किसी ने दर्ज नहीं किया।

दूरस्थ प्रबंधन चालू करने से वास्तव में क्या बदलता है

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

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

इच्छित प्रबंधन मार्ग को परिनियोजन नोट्स में लिखें, जिसमें पोर्ट और वह पता-परास जो इसे उपयोग कर सकता है शामिल हो। वही नोट इस बात को दर्ज करने की जगह भी है कि यह क्षमता किसने माँगी और इसे कब वापस लिया जाना चाहिए।

तय करें कि इस क्लाइंट का प्रबंधन कौन कर सकता है

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

कमांड स्थानीय सेवा पर चलाएँ ताकि परिवर्तन स्क्रीनशॉट में नहीं बल्कि आपके अपने शेल इतिहास में दर्ज हो: vpncmd localhost /client /cmd RemoteDisable क्षमता बंद करता है, और RemoteEnable के साथ वही कमांड उसे चालू करता है। बाद में सेवा पुनः आरंभ करें, वरना सेटिंग लागू नहीं रहेगी।

यदि कोई ट्यूटोरियल इसे बिना व्याख्या के प्रारंभिक चरण के रूप में चालू करता है, तो उसे अनुसरण करने के निर्देश के बजाय एक अनसुलझा प्रश्न मानें। पूछें कि कौन-सा प्रबंधन स्टेशन इसे उपयोग करने वाला है, और यदि उत्तर न हो तो क्षमता बंद ही रखें।

प्रबंधन पहुँच और कनेक्टिविटी अलग-अलग जाँचें

दो परीक्षण दो अलग प्रश्नों के उत्तर देते हैं, और इनमें से केवल एक चलाना ही वह तरीका है जिससे परिनियोजन ऐसे दूरस्थ प्रशासन के साथ समाप्त होता है जो किसी ने नहीं चाहा था।

vpncmd localhost /client /cmd RemoteDisable
systemctl restart vpnclient
vpncmd localhost /client /cmd AccountList
vpncmd localhost /client /cmd NicList

पहली दो पंक्तियाँ क्लाइंट को फिर से स्थानीय प्रशासन के अधीन लाती हैं और परिवर्तन लागू करती हैं। अंतिम दो पुष्टि करती हैं कि VPN खाते और वर्चुअल एडाप्टर अभी भी कॉन्फ़िगर हैं, जैसा होना चाहिए, क्योंकि प्रबंधन दायरा और कनेक्शन स्थिति स्वतंत्र सेटिंग्स हैं। यदि पुनः आरंभ के बाद खातों की सूची खाली लौटे, तो कुछ और टूटा है और दूरस्थ प्रबंधन सेटिंग इसका कारण नहीं है।

फिर कनेक्शन स्वयं क्लाइंट से जाँचें और पुष्टि करें कि एडाप्टर अपेक्षित पता और मार्ग रखता है। सफल vpncmd सत्र नियंत्रण संबंध सिद्ध करता है और इस बारे में कुछ नहीं कहता कि ट्रैफ़िक टनल से बाहर जाता है या नहीं।

संबंधित लेख