macOS पर लॉगिन से पहले VPN: अनलॉक, लॉगिन विंडो, सत्र
FileVault अनलॉक, लॉगिन विंडो और उपयोगकर्ता सत्र अलग-अलग चरण हैं। लॉगिन पर शुरू होने वाला डेस्कटॉप क्लाइंट केवल अंतिम चरण का समाधान करता है।
यहाँ एक मान्यता है जो लोगों को एक सप्ताह का नुकसान पहुँचाती है: कि Mac के पास लॉगिन से पहले नाम का एक ही क्षण है, और VPN क्लाइंट या तो तब शुरू होता है या नहीं। वास्तव में मशीन में कम से कम तीन क्षण हैं जहाँ नेटवर्क पहुँच मायने रखती है, और उन्हें यह बात अलग करती है कि उस समय किसे क्रेडेंशियल रखने की अनुमति है। लॉगिन आइटम से शुरू होने वाला क्लाइंट उनमें से ठीक एक को कवर करता है, और वह अंतिम है।
यह भ्रांति कि एक सेटिंग पूरे बूट को कवर करती है
उत्पाद पृष्ठ फिर से पढ़ें और देखें कि सुविधा किस चरण का नाम लेती है। लॉगिन पर शुरू करें लिखा चेकबॉक्स लॉगिन आइटम का अर्थ है, जो उपयोगकर्ता सत्र बनने के बाद चलता है। माँग पर कनेक्ट करें लिखा चेकबॉक्स का अर्थ है कि क्लाइंट तब कनेक्शन खोलता है जब ट्रैफ़िक किसी नियम से मेल खाता है, जिसके लिए अभी भी क्लाइंट और उसके क्रेडेंशियल उपलब्ध होना ज़रूरी है।
इनमें से कोई भी बूट प्रक्रिया तक नहीं पहुँचता। यह ऐसी सीमा नहीं है जिसे विक्रेता हटाना भूल गया हो; यह वही है जिसकी ऑपरेटिंग सिस्टम अनुमति देता है। वॉल्यूम अनलॉक होने से पहले कोई चल रहा सिस्टम नहीं है जिससे क्लाइंट शुरू किया जा सके, और लॉगआउट के बाद उपयोगकर्ता के रहस्य सत्र के साथ चले जाते हैं। दो अलग दीवारें, और कोई भी किसी दूसरे चेकबॉक्स के आगे नहीं झुकती।
चरणों को अलग करते ही मूल प्रश्न का आकार बदल जाता है। यह पूछने के बजाय कि VPN लॉगिन से पहले शुरू होता है या नहीं, आप पूछते हैं कि तीन विशिष्ट क्षणों में से कौन काम करना चाहिए, और तब पाते हैं कि हर एक का मालिक अलग है: एन्क्रिप्शन स्टैक, नेटवर्क एक्सटेंशन या उपयोगकर्ता सत्र।
हर चरण में वास्तव में क्या होता है
बूट एक एन्क्रिप्टेड वॉल्यूम से शुरू होता है जिसे किसी सामान्य काम के लिए उपयोगी सिस्टम होने से पहले अनलॉक करना पड़ता है। वह अनलॉक सीमित संदर्भ में सीमित क्रेडेंशियल के साथ होता है, और Apple स्पष्ट रूप से दस्तावेज़ करता है कि वैध अनलॉक के बिना एन्क्रिप्टेड डेटा अगम्य रहता है।
फिर लॉगिन विंडो आती है, जहाँ सिस्टम चल रहा है पर अभी कोई उपयोगकर्ता सत्र नहीं है। यदि उपयोगकर्ता लॉगआउट कर चुका है तो उपयोगकर्ता-संदर्भ का एक्सटेंशन पहले ही समाप्त हो चुका है, और वैश्विक सिस्टम एक्सटेंशन अभी भी चल सकता है, पर चलना उन क्रेडेंशियल को रखने के बराबर नहीं है जो आपके VPN को चाहिए।
फिर सत्र आता है, जहाँ एक सामान्य क्लाइंट लॉगिन कीचेन पढ़ सकता है, दूसरा कारक माँग सकता है और धकेले गए रूट लागू कर सकता है। लोग लॉगिन से पहले जिन सुविधाओं का वर्णन करते हैं उनमें से अधिकांश वास्तव में यही चरण हैं, जो लॉगिन से पहले नहीं बल्कि सत्र की शुरुआत में सक्रिय होते हैं।
| Stage | What it can use | What it cannot do |
|---|---|---|
| FileVault unlock | Credentials supplied at the console to unlock the volume | Run an ordinary VPN app or read a user keychain |
| Login window | System context, possibly a joined network | Use a user secret that only exists after login |
| User session | Login keychain, interactive MFA, full client features | Exist before the volume unlocks |
launch daemon किसी अनुपस्थित उपयोगकर्ता के लिए साइन इन क्यों नहीं कर सकता
बढ़ा हुआ विशेषाधिकार लगता है कि समस्या हल कर देगा, और यह नहीं करता। launch daemon पीछे उपयोगकर्ता सत्र के बिना सिस्टम प्रक्रिया के रूप में चलता है, इसलिए अनलॉक करने के लिए कोई कीचेन नहीं है और अनुरोध का उत्तर देने के लिए कोई मनुष्य नहीं है। यह सॉकेट खोल सकता है और फ़ाइल पढ़ सकता है; जो नहीं कर सकता वह है उस उपयोगकर्ता बन जाना जिसके पास क्रेडेंशियल हैं। विशेषाधिकार पहचान नहीं है, और ठीक यहीं दोनों उलझ जाते हैं।
लोग उस अंतराल में जो बनाते हैं वह अंदर पासवर्ड वाली स्क्रिप्ट है, जो उनकी शुरुआती समस्या से भी बदतर समस्या है।
आवश्यकता का ईमानदार संस्करण अधिक संकीर्ण है। यदि मशीन को किसी के उपस्थित न होने पर संरक्षित संसाधन तक पहुँचना है, तो वह पहचान जिसे वह संसाधन स्वीकार करता है, ऐसी होनी चाहिए जिसे मशीन बिना किसी व्यक्ति के रख सके: डिवाइस प्रमाणपत्र, सिस्टम कीचेन में क्रेडेंशियल, या ऐसा खाता जिसका दूसरा कारक किसी की जेब के फ़ोन पर पुश न हो। उस पहचान को जानबूझकर डिज़ाइन करें, और चरण का प्रश्न सामान्यतः स्वयं उत्तर दे देता है।
Windows की लॉगिन-पूर्व सुविधा यहाँ लागू नहीं होती
Windows में कुछ दूरस्थ पहुँच उत्पादों के लिए प्रलेखित लॉगिन-पूर्व पहुँच तंत्र है, और नाम क्षमता से बेहतर यात्रा करता है। Windows परिनियोजन मार्गदर्शिका में वर्णित सुविधा इस बारे में कुछ नहीं कहती कि वही विक्रेता macOS पर समतुल्य लागू करता है या नहीं।
ऐसा वक्तव्य माँगें जो Mac हार्डवेयर, macOS संस्करण, क्लाइंट संस्करण और वह प्रमाणीकरण विधि कवर करे जो आप वास्तव में उपयोग करते हैं। सामान्य समर्थन दावा पर्याप्त नहीं है, क्योंकि काम करने और न करने का अंतर अक्सर उन चार में से एक में होता है।
यदि विक्रेता उत्तर नहीं दे सकता, तो वही उत्तर है। सत्र चरण की योजना बनाएँ और बिना किसी की उपस्थिति वाले मामले के लिए विकल्प डिज़ाइन करें, परिनियोजन के दौरान अंतराल खोजने के बजाय।
इसके बजाय क्या माँगें
आवश्यकता को चरणों की भाषा में लिखें। कौन सा संसाधन, किसे चाहिए, किस संदर्भ में, और जब कनेक्शन अभी न हो तो कितनी स्वीकार्य देरी?
यदि उत्तर ऐसा उपयोगकर्ता है जो साइन इन करता है और फिर टनल चाहता है, तो माँग पर कनेक्शन और स्टार्टअप आइटम पर्याप्त और सस्ते हैं। यदि उत्तर ऐसी मशीन है जो रात भर में रीबूट होती है और रिपोर्ट करनी होती है, तो डिज़ाइन को समर्थित डिस्क अनलॉक मार्ग, डिवाइस पहचान और ऐसी रिकवरी प्रक्रिया चाहिए जो तब काम करे जब नेटवर्क कभी न उठे। यदि उत्तर टनल पर निर्भर संगठन लॉगिन है, तो लॉगिन, पहचान और VPN डिज़ाइन साथ बनाने होंगे, अलग खरीदने नहीं।
Apple का FileVault दस्तावेज़ अनलॉक चरण के लिए सही प्रारंभ बिंदु है। इसके बाद सब कुछ क्लाइंट और पहचान का प्रश्न है जिसे खरीदने से पहले विक्रेता के वक्तव्य से तय होना चाहिए।