बुटमा Mac VPN: launchd ले कार्यको सुपरिवेक्षण गर्छ, टनेलको होइन
lint पास भएको plist ले क्रेडेन्सियल वा तयारीबारे केही पनि प्रमाणित गर्दैन। कार्यलाई यसको सत्रसँग मिलाउनुहोस्, क्लाइन्ट अगाडि राख्नुहोस् र त्यही सन्दर्भमा परीक्षण गर्नुहोस्।
लगइनमा कार्य चल्छ, लगले क्लाइन्ट सुरु भएको देखाउँछ, तर टनेल कहिल्यै माथि आउँदैन। वा आउँछ र केही सेकेन्डपछि हराउँछ। दुवै अवस्थामा गुण धर्म सूची सम्भवतः ठीक थियो। launchd ले कार्य स्वीकार गर्दा दुई वाचा गर्यो: यसले प्रक्रियाको सुपरिवेक्षण गर्नेछ, र त्यो प्रक्रिया चलिरहनेछ। VPN लाई दुवै चाहिन्छ, र सही XML फाइलले कुनै पनि दिँदैन।
वैध गुण धर्म सूची कार्यरत सेवा होइन
plutil -lint ले संरचना जाँच्छ। बाइनरी छ कि छैन, यो क्लाइन्ट संस्करणले आर्गुमेन्टहरूलाई समर्थन गर्छ कि गर्दैन, वा क्रेडेन्सियल उपलब्ध हुने सन्दर्भमा कार्य सुरु हुन्छ कि हुँदैन भन्ने यसले बताउन सक्दैन। यी अर्थशास्त्रीय प्रश्न हुन्, र launchd समस्या जस्तो देखिने अधिकांश असफलताको कारण यिनै हुन्।
plutil -lint /Library/LaunchDaemons/com.example.vpn.plist
launchctl print system/com.example.vpn
कार्य लोड भयो भनी मान्नुको सट्टा दोस्रो आदेशको आउटपुट पढ्नुहोस्। यसले अन्तिम निकास स्थिति र सेवा चलिरहेको छ कि छैन बताउँछ, जसले प्रोफाइल छुनुअघि "कहिल्यै सुरु भएन" र "सुरु भयो र मर्यो" बीच फरक पार्छ।
एजेन्टहरूले प्रयोगकर्ता सत्र वंशानुगत पाउँछन्, डेमनले पाउँदैनन्
Apple को launchd कागजातले प्रत्येक प्रयोगकर्ताका एजेन्टलाई प्रणाली डेमनबाट अलग गर्छ। एजेन्ट लगइन भएको प्रयोगकर्ताको सन्दर्भमा, त्यो प्रयोगकर्ताको किचेन र वातावरणसहित चल्छ। डेमन त्यो सत्रबिना चल्छ, र कार्यलाई प्रणाली डाइरेक्टरीमा सार्दा प्रयोगकर्ताको अन्तरक्रियात्मक क्रेडेन्सियल पुनः सिर्जना हुँदैन।
डिजाइन यही भिन्नताले निर्धारण गर्छ। यदि जडानका लागि व्यक्तिले लगइन गर्न वा MFA सूचना स्वीकृत गर्न आवश्यक छ भने, समर्थित व्यवस्था हो लगइनपछि चल्ने प्रयोगकर्ता सत्रको कार्य। यदि यो कोही पनि लगइन नभएको अवस्थामा चल्नुपर्छ भने, क्लाइन्टलाई आफ्नै नवीकरण र रद्दीकरण प्रक्रियासहित स्वीकृत मानवरहित पहिचान चाहिन्छ। गलत पंक्ति छान्दा सफा सुरु भएर पहिलो प्रमाणीकरण चरणमै असफल हुने कार्य बन्छ।
आर्गुमेन्ट एरेमा पासवर्ड राखेर वा प्रमाणपत्र जाँच बन्द गरेर यो भिन्नता लुकाउनु हुँदैन। दुवैले प्रमाणीकरण आवश्यकतालाई पढ्न मिल्ने फाइलमा स्थायी रहस्य बनाउँछन्, र दोस्रोको अर्थ टनेलले जवाफ दिने जुनसुकैलाई प्रमाणीकरण गर्छ भन्ने हो।
प्रक्रिया अगाडि रहेमा मात्र सुपरिवेक्षण काम गर्छ
आफैंलाई डेमन बनाउने क्लाइन्टले नियन्त्रण तुरुन्तै launchd लाई फर्काउँछ, र त्यसपछि सुपरिवेक्षकले पहिले नै सकिएको प्रक्रियालाई हेर्छ। टनेल माथि हुन सक्छ, तर launchd लाई कार्य असफल भयो भन्ने लाग्छ, र यसको पुनःसुरु नीतिले तपाईंले नचाहेको काम गर्छ।
क्लाइन्टको कागजातमा उल्लेखित अगाडिको वा सेवा मोड प्रयोग गर्नुहोस्। उत्पादनसँग आफ्नै समर्थित स्टार्टअप सुविधा छ भने, त्यो सुविधालाई अगाडि कसरी रहने र नेटवर्क स्ट्याकमा कसरी हस्तान्तरण गर्ने पहिले नै थाहा छ; अनुकूलित कार्य छुट्टै डिजाइन हो, त्यसको सुधार होइन।
कार्यलाई अद्वितीय लेबल, इच्छित एक्जिक्युटेबल र जानाजानी आर्गुमेन्ट एरे दिनुहोस्। एरे shell आदेश रेखा होइन, त्यसैले पाइप र पुनर्निर्देशन त्यहाँ चल्दैनन्, र उद्धरणको व्यवहार फरक हुन्छ। प्रशासकको टर्मिनलमा सफल हुने आदेश बढीमा प्रारम्भिक जाँच मात्र हो।
क्रेडेन्सियलहरू सूचनाबिना चल्नुपर्छ
मानवरहित सञ्चालनले क्रेडेन्सियल समस्या हटाउँदैन, सार्छ। कसैले पहिचानको स्वामित्व लिनुपर्छ, त्यो कति समय बाँच्ने निर्णय गर्नुपर्छ र कसरी प्रतिस्थापन हुन्छ कागजात गर्नुपर्छ। म्याद निगरानी नभएको प्रमाणपत्र क्यालेन्डरमा मिति भएको अवरोध बन्छ।
रहस्यहरू आर्गुमेन्ट र कार्यको मानक आउटपुटबाट टाढा राख्नुहोस्। क्लाइन्टले सुरक्षित भण्डारबाट क्रेडेन्सियल पढ्न समर्थन गर्छ भने, त्यो मार्ग प्रयोग गर्नुहोस्, र कार्यको कार्यान्वयन सन्दर्भ भण्डारसम्म पुग्न सक्छ कि सक्दैन जाँच्नुहोस्। root का रूपमा चल्ने डेमनले सामान्यतया लगइन किचेन वस्तु पढ्न सक्दैन, र यो प्रणाली सन्दर्भमा मात्र देखिने विवरण हो।
तयार भन्नाले के बुझिन्छ परिभाषित गर्नुहोस्, त्यसपछि त्यहीँ परीक्षण गर्नुहोस्
सफल प्रक्षेपणले प्रक्रिया सुरु भयो भनी प्रमाणित गर्छ। नेटवर्क माथि छ, गेटवेले पहिचान स्वीकार गर्यो, वा निजी अनुप्रयोग पुग्न सकिन्छ भनी प्रमाणित गर्दैन। अरू केही टनेलमा निर्भर छ भने, त्यसलाई कार्यको सुरु समय होइन, जडान प्रतिबिम्बित गर्ने तयारी सङ्केत चाहिन्छ।
पुनःप्रयासहरू सीमित हुनुपर्छ र हराएको नेटवर्क र अस्वीकृत क्रेडेन्सियलबीच फरक गर्नुपर्छ। हरेक असफलतामा पुनः सुरु गर्दा म्याद सकिएको प्रमाणपत्र सुधार्न सक्दैन र साँचो प्रयास लुकाउने समान प्रयासले भरिएको लग बनाउँछ।
कार्यलाई यो वास्तवमा चल्ने सन्दर्भमा स्वीकार गर्नुहोस्: बुटमा नेटवर्क छैन, सामान्य लगइन, निद्राबाट उठ्ने र नियन्त्रित रोकावट। त्यसपछि कार्यको लेबल, क्लाइन्ट संस्करण र प्रोफाइल पुनरावृत्ति सँगै लेख्नुहोस्, ताकि अर्को व्यक्तिले एकपटक चलेको फाइलको सट्टा श्रेय दिन सकिने सेवा पाऊन्।