तुमची स्क्रिप्ट VPN सुरू करते; ती तयार करत नाही

तुम्ही कनेक्शनच्या नावासह scutil --nc start चालवणारी स्क्रिप्ट लिहिता, ती तुमच्या Mac वर चालते, आणि ऑफिसमधील प्रत्येक नव्याने इन्स्टॉल केलेल्या मशीनवर अयशस्वी होते। स्क्रिप्ट खराब नाही। तिला असे काही सांगितले जात आहे जे ती कधीही करू शकली नाही: विद्यमान कनेक्शन सुरू करणे हे नवीन तयार करण्यासारखेच कार्य नाही।

तयारी आणि सत्र नियंत्रण ही दोन मालक असलेली दोन कामे आहेत, आणि उलट गृहीत धरणारा वर्कफ्लो जिथे लिहिला गेला त्या मशीनवर प्रत्येक चाचणी उत्तीर्ण होईल।

स्टार्ट कमांड प्रत्यक्षात कुणाशी बोलते

सत्र-नियंत्रण कमांड अशा कॉन्फिगरेशनला संबोधते जे आधीच अस्तित्वात आहे आणि आधीच मंजूर आहे। ती सिस्टमला ते नावाचे कनेक्शन वर आणण्यास सांगते, यापूर्वी साठवलेल्या सर्व्हर सेटिंग्ज, ओळख संदर्भ आणि धोरण वापरून। जर ते कधीही इन्स्टॉल झाले नाहीत, तर सुरू करण्यासाठी काहीही नाही।

म्हणूनच अयशस्वीता नवीन हार्डवेअरवर दिसते, प्रशासकाच्या लॅपटॉपवर नाही। लॅपटॉप महिन्यांपूर्वी असे केल्याचे विसरलेल्या व्यक्तीने तयार केला होता। स्टार्ट कमांडला गेल्या तिमाहीत कोणी वायर केलेली दाराची घंटी समजा। ती दाबणे हे वायरिंग टाकण्यासारखे नाही।

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

संस्थेद्वारे व्यवस्थापित प्रोफाइल डिव्हाइस व्यवस्थापनातून येते। प्रोफाइल सर्व्हरचे पत्ते, प्रमाणीकरणाची रचना आणि संस्थेला आवश्यक धोरण वाहून नेते, आणि VPN प्रशासक ती व्यक्ती आहे जी ती पुरवते। स्क्रिप्टने यादीत सापडलेल्या प्रदर्शित नावावरून ती सेटिंग्ज पुन्हा तयार करू नयेत।

मूळ वैयक्तिक VPN कॉन्फिगरेशन Apple च्या Network Extension API द्वारे तयार केले जाते, जे अंगभूत IPsec आणि IKEv2 प्रोटोकॉल व्यापते। हे सेव्ह टप्पा आणि वापरकर्ता मंजुरीसह अ‍ॅप्लिकेशन इंटरफेस आहे, विक्रेता पुरवतो तो कोणताही टनेल प्रकार गुपचूप तयार करणारी shell कमांड नाही।

तृतीय-पक्ष क्लायंट ही तिसरी केस आहे, ज्याचे स्वतःचे आयात स्वरूप, स्वतःचे व्यवस्थापन साधन आणि अनेकदा स्वतःचा विशेषाधिकारप्राप्त सहाय्यक असतो। त्याचे सत्र त्या विक्रेत्याच्या प्रोसेसच्या मालकीचे आहे। समान नावाची सिस्टम सेवा सापडणे हा सिस्टम कमांड टनेल नियंत्रित करते याचा पुरावा नाही, आणि असे गृहीत धरल्यास विक्रेता क्लायंट अद्ययावत करेपर्यंत काम करत असल्यासारख्या दिसणाऱ्या स्क्रिप्ट तयार होतात।

मूळ तयारीत सेव्ह आणि मंजुरी असते

Apple चे मॉडेल आहे लोड करा, बदला, सेव्ह करा। अ‍ॅप्लिकेशन लॉन्चनंतरच्या त्याच्या पहिल्या सेव्हपूर्वी विद्यमान प्राधान्ये लोड करते, कॉन्फिगरेशन बदलते आणि नंतर ते सेव्ह करते। टिकू शकत नाही तेव्हा सेव्ह त्रुटी नोंदवते, आणि तो निकाल दुर्लक्षित केल्यास तयारीची अयशस्वीता तीन पावले नंतर कनेक्शनच्या अयशस्वीतेत बदलते।

पहिल्या सेव्हसाठी वापरकर्त्याने अ‍ॅप्लिकेशन मंजूर करणेही आवश्यक आहे। ही जाणीवपूर्वक केलेली सुरक्षा सीमा आहे, आणि त्याचा अर्थ नवीन Mac वर पहिली रन संवादात्मक असते, जरी पुढील प्रत्येक कनेक्ट आणि डिस्कनेक्ट स्वयंचलित करता आले तरी। पहिली रन व्यक्ती उपस्थित असलेले मानवी कार्य म्हणून नियोजित करा। दुसऱ्या रनपासून स्वयंचलित करा, आणि कोणीही अशक्य वचन देऊ नये म्हणून ते रनबुकमध्ये लिहा। पूर्णपणे देखरेखीविरहित पहिल्या रनचे वचन देणारी उपयोजन योजना प्लॅटफॉर्म देत नाही असे काहीतरी वचन देते।

Apple API वर अवलंबून राहण्यापूर्वी कॉन्फिगरेशन प्रोफाइलसह सर्व्हरची सुसंगतता सत्यापित करण्याची शिफारसही करते। ती तपासणी आधी केल्यास «सर्व्हर हा क्लायंट स्वीकारणार नाही» आणि «क्लायंटने कधीही सेटिंग्ज साठवल्या नाहीत» वेगळे होतात, आणि ही वेगवेगळ्या संघांसाठी वेगवेगळी तिकिटे आहेत।

पुनरावृत्तीयोग्य स्टार्ट कमांड काय गृहीत धरू शकते

तयारीनंतर स्क्रिप्ट त्याच्या मालकाच्या इंटरफेसद्वारे सुरक्षितपणे विद्यमान कनेक्शनला लक्ष्य करू शकते। त्याला कनेक्शनची स्थिर ओळख आणि तुम्हाला हवी ती क्रिया द्या, दुसरे काहीही नाही। तिने अंदाज केलेला प्राधान्य मार्ग वाचू नये, आणि मेनूमध्ये दिसणारे नाव संपूर्ण सिस्टममध्ये अद्वितीय आहे असे गृहीत धरू नये।

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

रहस्ये कमांड-लाइन आर्ग्युमेंट्स आणि सामान्य निदान आउटपुटपासून दूर ठेवा। उपयोजनाने निवडलेले कोणतेही ओळख यंत्रणा हेच स्टार्ट कमांडने अवलंबणे आवश्यक आहे, आणि shell इतिहासात पेस्ट केलेला पासवर्ड कोणत्याही पुनरावलोकनात एक शोध आहे।

दोन स्वीकृती तपासण्या

पहिली तपासणी तयारी आहे: नव्याने इन्स्टॉल केलेला Mac घ्या आणि कॉन्फिगरेशन उपस्थित आहे, योग्य व्यवस्थापकाच्या मालकीचे आहे आणि पूर्णपणे मंजूर आहे हे सिद्ध करा। कनेक्टिव्हिटी तपासण्यापूर्वी हे करा, कारण तयार न केलेल्या मशीनवरील कनेक्शन चाचणी स्क्रिप्टबद्दल काहीही सिद्ध करत नाही।

दुसरी तपासणी सत्र आहे: कनेक्ट व्हा, अधिकृत संसाधनापर्यंत पोहोचा आणि स्वच्छपणे डिस्कनेक्ट व्हा। आता प्रत्येक अयशस्वीतेला मालक आहे, आणि दोन कामे वेगळी करण्याचा हाच व्यावहारिक फायदा आहे। गहाळ प्रोफाइल ही वितरणाची समस्या आहे, सेव्ह त्रुटी मंजुरीची समस्या आहे, नाकारलेला लॉगिन प्रमाणीकरणाची समस्या आहे, आणि यशस्वी स्टार्टनंतरची मुदत संपणे सत्र स्तर आहे। त्यातील कोणतेही «स्क्रिप्ट खराब आहे» नाही।