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 ও সার্ভার প্রস্তুত আছে বলে গ্যারান্টি দিতে পারে না, এবং প্রতিটি পুনঃসংযোগে সাড়া দেয় না।

প্রথম সীমাটি বাস্তবে সবচেয়ে গুরুত্বপূর্ণ। যার সার্ভার হারিয়ে যায় সেই শেয়ার এমন একটি ভলিউম রেখে যায় যা মাউন্ট দেখায় এবং অ্যাক্সেসে আটকে যায়, আর ভদ্র সমাধান হল পরিকল্পিত ডিসকানেক্টের আগে ফাইল ক্রিয়া শেষ করে সেটি বের করে দেওয়া। দ্বিতীয়টি প্রথম চেষ্টার বেশিরভাগ ব্যর্থতার ব্যাখ্যা দেয়: টানেল উঠে গেছে কিন্তু রিজলভার এখনও পৌঁছায়নি, তাই অপেক্ষা করুন এবং তারপর নিশ্চিত করতে একবার হাতে মাউন্ট করুন। তৃতীয়টি আগে বলা জিজ্ঞাসার সমঝোতা, ঠিক করার মতো কোনো বাগ নয়।

নজরদারিহীন মেশিন বা পরিচালিত ফ্লিটের জন্য এই নকশা ভুল আকারের। ডেস্কটপ অ্যাপলেটকে বিশেষাধিকারী সেবায় বাড়ানোর বদলে প্রশাসকের মালিকানাধীন মাউন্ট নীতি ব্যবহার করুন।