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 कागजात अनलक चरणका लागि सही सुरुवात बिन्दु हो। त्यसपछिको सबै क्लाइन्ट र पहिचानको प्रश्न हो, जो किन्नुअघि विक्रेताको वक्तव्यले टुंग्याउनुपर्छ।