root का रूपमा नचलाई Tunnelblick बाट साझेदारी माउन्ट गर्ने

VPN क्लाइन्टलाई नेटवर्क पुनः कन्फिगर गर्न विशेषाधिकारप्राप्त सहयोग चाहिन्छ, र यो तथ्य त्यसको वरपरका सबै कुरामा धेरै व्यापक रूपमा लागू गरिन्छ। फाइल साझेदारी माउन्ट गर्ने स्क्रिप्टलाई root चाहिँदैन, किनकि साझेदारी साइन-इन भएको प्रयोगकर्ताको सत्र र उही प्रयोगकर्ताको प्रमाणहरूको हिस्सा हो। माउन्टलाई विशेषाधिकारको बाटोबाट बाहिर निकाल्दा sudo नियम, root हुक र सँगै आएका एपहरूमा परिवर्तनको आवश्यकता हट्छ। बाँकी रहने कुरा एउटा सानो एप्लेट हो, जो खुला रहन्छ, एउटा प्रोफाइल नियाल्छ र एकैचोटि प्रयास गर्छ।

यो प्रयोगकर्ता सत्रमा किन पर्छ

माउन्ट गरिएको भोल्युम त्यो माउन्ट गर्ने सत्रको गुण हो। अर्को प्रयोगकर्ताको सत्रले त्यो देख्दैन, र root को स्वामित्वको माउन्ट Finder ले बनाएको भन्दा फरक व्यवहार गर्छ। माउन्टलाई प्रयोगकर्ता सत्रमा राख्दा त्यही अर्थ कायम रहन्छ।

विशेषाधिकारप्राप्त सहायकहरू ती भागका लागि हुन्छन् जसलाई साँच्चै चाहिन्छ: टनेल इन्टरफेस बनाउने, मार्ग परिवर्तन गर्ने, रिजोल्भर अद्यावधिक गर्ने। SMB साझेदारी माउन्ट गर्ने त्यस्तो भाग होइन। त्यसलाई त्यस्तै हो भनेर व्यवहार गर्दा पासवर्डरहित sudo र कोही नभएको बेला चल्ने root स्क्रिप्टबीच छान्नुपर्छ। दुवै समस्याको औचित्यभन्दा ठूला जोखिम हुन्, र प्रयोगकर्ता सत्रको दृष्टिकोणले त्यो छनोट नै टार्छ।

Tunnelblick का आफ्नै जडान हुकहरू यहाँ विकल्प होइनन्, किनकि तिनीहरू डेस्कटप सत्रबाहिर चल्छन् र क्लाइन्टका स्क्रिप्टसँगको तिनको क्रम निर्धारित छैन। प्रयोगकर्ता एप्लेटबाट स्थिति सोध्नु कम अनुमान भएको सानो संयन्त्र हो।

पहिले हातैले जाँच्नुहोस् कि साझेदारी चल्छ

स्वचालनले नभएको मार्ग, अनुमति वा खाता दिन सक्दैन। कुनै पनि स्क्रिप्ट लेख्नुअघि VPN मा हातैले जोडिनुहोस् र साझेदारी Finder मा खोल्नुहोस्। यो असफल भयो भने स्क्रिप्ट अझ अन्योलमा पार्ने तरिकाले असफल हुन्छ।

स्क्रिप्टले प्रयोग गर्ने तीन मान लेख्नुहोस्: प्रोफाइलको नाम Tunnelblick ले देखाएजस्तै, साझेदारीको URL र माउन्टपछि Finder ले देखाउने भोल्युम नाम। भोल्युम नाम महत्त्वपूर्ण छ किनकि विद्यमान माउन्टको जाँचले त्यही प्रयोग गर्छ, र नाममा मात्र आधारित जाँच सुविधाको सुरक्षा हो, सर्भरको पहिचानको प्रमाण होइन। मेसिनमा अद्वितीय नाम प्रयोग गर्नुहोस्। त्यसपछि सर्भरले जवाफ दिन्छ कि दिँदैन भनेर पुष्टि गर्नुहोस्।

smbutil view //files.corp.example
osascript -e 'tell application "Tunnelblick" to get state of first configuration whose name is "Office"'
mount | grep -i smbfs

पहिलो आदेशले सर्भरले जवाफ दिन्छ भन्ने प्रमाणित गर्छ, दोस्रोले प्रोफाइल नाम समाधान हुन्छ भन्ने, र तेस्रोले सफल माउन्ट कस्तो देखिन्छ भनेर देखाउँछ। केही पनि स्वचालित गर्नुअघि तीनवटै लेख्नुहोस्।

Tunnelblick बाट प्रोफाइल स्थिति पढ्नुहोस्

Tunnelblick ले आफ्ना कन्फिगरेसनहरू र तिनका स्थितिहरू AppleScript मार्फत खोल्छ, र यो डिजाइनलाई चाहिने एउटै हुक यही हो। महत्त्वपूर्ण स्थिति त्यही एउटा प्रोफाइलका लागि रिपोर्ट गरिएको स्ट्रिङ हो, एपको उपस्थिति होइन।

सोधपुछका केही मूल्यहरू छन् जो बताउन लायक छन्। अन्तरालभन्दा छोटो पुनःजडान बेवास्ता हुन सक्छ, र एप्लेटले त्यो परिवर्तन देख्दै देख्दैन। माउन्टको पहरेदारका लागि यो स्वीकार्य छ र हरेक घटनामा प्रतिक्रिया दिनुपर्ने कुनै पनि कुराका लागि अस्वीकार्य। घटना-स्तरीय शुद्धता चाहिन्छ भने यो गलत संयन्त्र हो, टाइमर छोटो बनाउनुपर्ने संयन्त्र होइन। अन्तराल छान्दा यही सम्झौता मनमा राख्नुहोस्।

property attempted : false

on idle
    set profileName to "Office"
    set shareURL to "smb://files.corp.example/OfficeTeam"
    set volName to "OfficeTeam"
    tell application "Tunnelblick" to set vpnState to state of first configuration whose name is profileName
    if vpnState is not "CONNECTED" then
        set attempted to false
        return 20
    end if
    tell application "Finder" to set mounted to (exists disk volName)
    if (not mounted) and (not attempted) then
        set attempted to true
        try
            mount volume shareURL
        end try
    end if
    return 20
end idle

खुला रहने विकल्पसहित यसलाई एप्लिकेसनका रूपमा निर्यात गर्नुहोस्, त्यसपछि sudo होइन, साइन-इन भएको सत्रमा सुरु गर्नुहोस्।

एकचोटि माउन्ट गर्नुहोस्, त्यसपछि प्रयास रोक्नुहोस्

प्रयास गरियो भन्ने फ्ल्यागले नै यसलाई प्रमाण अनुमान गर्ने लूप बन्नबाट रोक्छ। एप्लेटले प्रयास गरेपछि फेरि प्रयास गर्नुअघि जडान स्थिति बदलिने पर्खाइ गर्छ।

यो व्यवहार जानाजानको हो। माउन्ट अस्वीकार गर्ने साझेदारी सामान्यतया फेरि प्रयास गर्दा सुधार्न नसकिने कारणले अस्वीकार गर्छ, र बारम्बार प्रयासले एउटा अनुरोधलाई तिनको लहर बनाइदिन्छ। प्रोफाइल जोडिएको स्थितिबाट बाहिर निस्कँदा फ्ल्याग रिसेट हुन्छ, त्यसैले साँचो पुनःजडानले ठ्याक्कै एउटा नयाँ प्रयास दिन्छ। एप्लेट बन्द गरेर फेरि सुरु गर्दा पनि रिसेट हुन्छ, र यही हातले गरिने हस्तक्षेप हो। कुनै पनि बाटोले असफलता लुकाउँदैन; दुवैले त्यसलाई Finder मा देखिने छोड्छन्।

स्क्रिप्टले कुनै पासवर्ड राख्दैन, र त्यसै गरी रहनुपर्छ। माउन्ट क्रियालाई सोध्न दिनुहोस्, र किचेनलाई संस्थाले समर्थन गरेको कुरा गर्न दिनुहोस्। URL मा प्रमाण राख्नुले सुविधाको स्क्रिप्टलाई फेर्नुपर्ने गोप्य कुरा बनाउँछ।

सहायकले के गर्न सक्दैन

तीन सीमा एप्लेटको छेउमा लेख्न लायक छन्। यसले नेटवर्क विफलतापछि व्यस्त भोल्युम बाहिर निकाल्न सक्दैन, स्थितिले जोडिएको भनेको बेला DNS र सर्भर तयार छन् भन्ने ग्यारेन्टी दिन सक्दैन, र हरेक पुनःजडानमा प्रतिक्रिया दिँदैन।

पहिलो सीमा व्यवहारमा सबैभन्दा महत्त्वपूर्ण छ। जसको सर्भर हराउँछ त्यो साझेदारी माउन्ट देखिने र पहुँचमा अड्किने भोल्युम छाड्छ, र शिष्ट उपाय भनेको नियोजित डिस्कनेक्टअघि फाइल क्रिया पूरा गरेर त्यो बाहिर निकाल्नु हो। दोस्रो सीमाले पहिलो प्रयासका धेरैजसो असफलता व्याख्या गर्छ: टनेल माथि छ तर रिजोल्भर अझै पुगेको छैन, त्यसैले पर्खनुहोस् र त्यसपछि पुष्टिका लागि एकचोटि हातैले माउन्ट गर्नुहोस्। तेस्रो सीमा अघि भनिएको सोधपुछको सम्झौता हो, सुधार्नुपर्ने बग होइन।

निगरानी नभएको मेसिन वा व्यवस्थापित फ्लीटका लागि यो डिजाइन गलत आकारको छ। डेस्कटप एप्लेटलाई विशेषाधिकारप्राप्त सेवा बनाउनुको सट्टा प्रशासकको स्वामित्वको माउन्ट नीति प्रयोग गर्नुहोस्।