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 और सर्वर तैयार हों, और हर पुनः कनेक्शन पर प्रतिक्रिया नहीं देता।

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

बिना निगरानी वाली मशीन या प्रबंधित फ़्लीट के लिए यह डिज़ाइन गलत आकार का है। डेस्कटॉप ऐपलेट को विशेषाधिकार वाली सेवा बनाने के बजाय व्यवस्थापक के स्वामित्व वाली माउंट नीति का उपयोग करें।