उपयोगकर्ता के पहले VPN कनेक्शन से पहले क्या पहले से कॉन्फ़िगर करें

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

कनेक्शन प्रोफ़ाइल वास्तव में क्या ले जाती है

VPN प्रोफ़ाइल कोई शॉर्टकट या बुकमार्क नहीं है। यह ऑपरेटिंग सिस्टम के कनेक्शन भंडार में एक नामित ऑब्जेक्ट है, जिसमें सर्वर का पता, टनल का प्रकार, प्रमाणीकरण विधि और अक्सर मार्ग, DNS प्रत्यय तथा ट्रिगर नियम होते हैं जो तय करते हैं कि कब जुड़ना है। Windows पर वे फ़ील्ड VPNv2 कॉन्फ़िगरेशन सेवा प्रदाता के नोड्स से मेल खाते हैं, इसीलिए एक प्रोफ़ाइल Intune, Configuration Manager, प्रोविज़निंग पैकेज या हाथ से आयात की गई XML फ़ाइल के ज़रिए आ सकती है।

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

भरोसा-सामग्री वह फ़ील्ड है जिसे सबसे अधिक हाथ से घुसाया जाता है। गेटवे पर हस्ताक्षर करने वाला CA प्रमाणपत्र पहले प्रयास से पहले मौजूद होना चाहिए, और सर्वर-नाम सत्यापन मेल खाते नाम के साथ चालू रहना चाहिए; परीक्षण पास कराने के लिए सत्यापन बंद करना प्रमाणीकरण की समस्या को ऐसी खामोश अवरोधन में बदल देता है जिसे कोई उपयोगकर्ता पकड़ नहीं सकता।

चार निर्णय जो उपयोगकर्ताओं को कभी नहीं लेने चाहिए

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

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

कनेक्शन का नाम उबाऊ और स्थिर रखें। उपयोगकर्ता इसे सहायता को ज़ोर से पढ़ते हैं, क्लाइंट सूची में ढूँढ़ते हैं और पासवर्ड रीसेट के बीच याद रखते हैं; माइग्रेशन के बीच में इसका नाम बदलना ऐसा सहायता-उछाल पैदा करता है जिसका VPN के चलने से कोई संबंध नहीं है।

पहचान प्रति व्यक्ति या प्रति डिवाइस भेजें

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

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

पंजीकरण वह जगह भी है जहाँ पुनर्प्राप्ति का मार्ग तय होता है। प्रमाणपत्र नवीनीकरण या पासवर्ड परिवर्तन डिवाइस तक तब पहुँचना चाहिए जब टनल बंद हो, इसलिए प्रोविज़निंग, पहचान प्रदाता और गेटवे को सहमत होना चाहिए कि यह कैसे होगा; यदि प्रोफ़ाइल ठीक करने का एकमात्र रास्ता उसी टनल से जाता है जो वह प्रोफ़ाइल देती है, तो कुंजी बक्से के भीतर बंद है।

डिलीवरी चैनल को क्लाइंट से मिलाएँ

मूल और तृतीय-पक्ष क्लाइंट अलग-अलग तरह से भेजे जाते हैं। Windows प्रोफ़ाइल Intune या Configuration Manager के ज़रिए VPNv2 ProfileXML के रूप में भेजी जा सकती हैं, पर हर नोड हर प्रबंधन सतह पर खुला नहीं होता, और रूटिंग, DNS तथा ट्रिगर सेटिंग्स उपकरण और Windows संस्करण के अनुसार बदलती हैं। शून्य-स्पर्श रोलआउट का वादा करने से पहले पुष्टि करें कि कौन-सा फ़ील्ड तैनात किया जा सकता है, क्योंकि प्रोफ़ाइल विकल्प संदर्भ ऐसी सेटिंग्स का दस्तावेज़ीकरण करता है जिन्हें कुछ डिलीवरी मार्ग अभी भी सेट नहीं कर सकते।

विक्रेता क्लाइंट दूसरी परत जोड़ते हैं, क्योंकि बाइनरी, प्रोफ़ाइल और हेडएंड नीति अलग-अलग कलाकृतियाँ हैं। उदाहरण के लिए Cisco Secure Client पैकेज और उसकी प्रोफ़ाइल दोनों की पूर्व-तैनाती का समर्थन करता है, और क्लाइंट संस्करण को गेटवे कॉन्फ़िगरेशन के साथ समन्वित करना होता है; केवल पैकेज स्थापित करने से उपयोगकर्ता विज़ार्ड में रह जाता है।

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

हैंडऑफ़ को नए उपयोगकर्ता के रूप में जाँचें, फिर पुनर्प्राप्ति जाँचें

किसी ऐसे डिवाइस पर सामान्य खाते से पायलट करें जिसने कभी कनेक्ट नहीं किया, प्रशासक के सहेजे सत्र या पहले से पंजीकृत प्रमाणपत्र के बिना। पुष्टि करें कि प्रोफ़ाइल सूची में दिखती है, साइन-इन संकेत निर्देशों से मेल खाता है और नाम वाला आंतरिक संसाधन खुलता है, फिर कनेक्टेड आइकन पर रुकने के बजाय नाम-समाधान और रूटिंग दायरा जाँचें।

डिवाइस के प्रोफ़ाइल भंडार से प्रश्न करें ताकि परीक्षण प्रभाव के बजाय प्रमाण दे।

Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType, AuthenticationMethod, SplitTunneling
Get-VpnConnection -Name "Corp VPN" | Format-List
Test-NetConnection intranet.example.com -Port 443

फिर उन घटनाओं से गुज़रें जिनका उपयोगकर्ता वास्तव में सामना करते हैं: ज़बरदस्ती पासवर्ड रीसेट, नवीनीकृत प्रमाणपत्र, धकेला गया क्लाइंट अपडेट और ऐसा नेटवर्क जिसे पायलट में किसी ने पहले इस्तेमाल नहीं किया। हर एक को या तो काम करना चाहिए या निर्देशों में बताए तरीके से विफल होना चाहिए। ऐसा नेटवर्क भी आज़माएँ जो VPN पोर्ट अवरुद्ध करता है, क्योंकि होटल Wi-Fi पर पहला प्रयास वह जगह है जहाँ घर की सफलता मदद करना बंद कर देती है। हर परिणाम के बगल में क्लाइंट संस्करण और OS बिल्ड लिखें, क्योंकि अगली रिपोर्ट उनके बिना आएगी।

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