आपकी स्क्रिप्ट VPN शुरू करती है; वह उसे तैयार नहीं करती

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

तैयारी और सत्र नियंत्रण दो काम हैं जिनके दो मालिक हैं, और उल्टा मानने वाला वर्कफ़्लो उसी मशीन पर हर परीक्षण पास करेगा जहाँ वह लिखा गया था।

स्टार्ट कमांड असल में किससे बात करता है

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

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

VPN कॉन्फ़िगरेशन के तीन मालिक

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

मूल व्यक्तिगत VPN कॉन्फ़िगरेशन Apple के Network Extension API से बनाई जाती है, जो अंतर्निहित IPsec और IKEv2 प्रोटोकॉल को कवर करती है। यह एक एप्लिकेशन इंटरफ़ेस है जिसमें सेव का चरण और उपयोगकर्ता की मंज़ूरी है, ऐसा शेल कमांड नहीं जो चुपचाप विक्रेता द्वारा दिया गया कोई भी टनल प्रकार बना दे।

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

मूल तैयारी में सेव और मंज़ूरी होती है

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

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

Apple यह भी सलाह देता है कि API पर भरोसा करने से पहले कॉन्फ़िगरेशन प्रोफ़ाइल से सर्वर की संगतता जाँच लें। यह जाँच पहले करने से «सर्वर इस क्लाइंट को स्वीकार नहीं करेगा» और «क्लाइंट ने कभी सेटिंग्स संग्रहीत नहीं कीं» अलग हो जाते हैं, जो अलग टीमों के लिए अलग टिकट हैं।

दोहराया जा सकने वाला स्टार्ट कमांड क्या मान सकता है

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

मूल कनेक्शन के लिए scutil --nc start जैसा नामित सत्र अनुरोध एक नियंत्रण क्रिया है। यह सर्वर सेटिंग्स इंस्टॉल नहीं करता, क्रेडेंशियल आयात नहीं करता और पहले-सेव का प्राधिकरण नहीं करता। इसे श्रृंखला का अंतिम चरण मानें, कभी पूरी श्रृंखला नहीं।

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

दो स्वीकृति जाँच

पहली जाँच तैयारी है: नई इंस्टॉल की गई Mac लें और साबित करें कि कॉन्फ़िगरेशन मौजूद है, सही प्रबंधक के स्वामित्व में है और पूरी तरह मंज़ूर है। कनेक्टिविटी जाँचने से पहले यह करें, क्योंकि बिना तैयारी वाली मशीन पर कनेक्शन परीक्षण स्क्रिप्ट के बारे में कुछ साबित नहीं करता।

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