Samba শেয়ারকে একজন ব্যবহারকারী ও একটি VPN ঠিকানায় সীমাবদ্ধ করুন
Samba-র valid users ও hosts allow একজন ব্যক্তিকে একটি ঠিকানার সঙ্গে জোড়া দেয় না: দুটি শেয়ার নাম এই জোড়া প্রকাশ করতে পারে, এবং ক্রসড-জোড়া পরীক্ষা তা প্রমাণ করে।
এই নকশায় দুটি আলাদা অনুমতি গুলিয়ে যায়: কে একটি ডিরেক্টরি ব্যবহার করতে পারে, আর কোন ঠিকানাগুলো আদৌ সংযোগ করতে পারে। একটি সোর্স তালিকার পাশে অ্যাকাউন্ট তালিকা লেখা জোড়ার মতো মনে হয়, কিন্তু Samba দুটি তালিকাকে বরং স্বাধীন শর্ত হিসেবে মূল্যায়ন করে। যে কেউ দুটোই পূরণ করে তাকে গ্রহণ করা হয়, যা বেশিরভাগ প্রশাসক যে নিয়ম চান তার চেয়ে প্রশস্ত। সমাধান হয় ভিন্ন শেয়ার বিন্যাস, নয় এমন একটি নীতি স্তর যা জোড়া প্রকাশ করতে পারে।
ভ্রান্ত ধারণা: দুটি তালিকা একটি নিয়ম তৈরি করে
smb.conf রেফারেন্স valid users ও hosts allow-কে দুটি অবিচ্ছিন্ন প্যারামিটার হিসেবে সংজ্ঞায়িত করে, এবং একটি শেয়ারে দুটোই সেট করলেই বিভ্রান্তি শুরু হয়। valid users = mira, tomas ও hosts allow = 10.77.0.21, 10.77.0.22 সেট করুন এবং চারটি সমন্বয় গৃহীত হয়: মীরা যেকোনো ঠিকানা থেকে, টমাস যেকোনো ঠিকানা থেকে। কনফিগারেশনে কিছুই প্রথম নামকে প্রথম ঠিকানার সঙ্গে বাঁধে না, আর নামগুলোর যে ক্রমে আসে তার কোনো অর্থ নেই। সেগুলো পুনর্বিন্যস্ত করা, দ্বিতীয় একটি hosts allow লাইন যোগ করা বা প্রতি লাইনে একটি নাম রাখা কিছুই বদলায় না। ফলাফল দুটি তালিকার গুণফল, তাদের মধ্যে কোনো ম্যাপিং নয়।
বেশিরভাগ মানুষ আসলে যা চান তা সংকীর্ণ: মীরা কেবল একটি ঠিকানা থেকে, টমাস কেবল আরেকটি থেকে। একটি একক শেয়ার সংজ্ঞায় সেই বাঁধনের কোনো সিনট্যাক্স নেই, এবং কোনো চতুর ক্রম তা তৈরি করে না। এটি এমন এক নীতির আকার যা Samba একটি শেয়ারের ভিতরে প্রকাশ করে না, আর এখানেই ভ্রান্ত ধারণাটি টিকে থাকে।
Samba কী মূল্যায়ন করে, কোন ক্রমে
ধাপগুলো নির্দিষ্ট ক্রমে চলে, আর ক্রম ভুল হলে ভুল রোগনির্ণয় আসে। ক্লায়েন্ট একটি সংযোগ খোলে; কোনো গ্লোবাল হোস্ট পরীক্ষা কনফিগার থাকলে সেটি চলে; সেশন সেটআপ অ্যাকাউন্টটি প্রমাণ করে; তারপর ক্লায়েন্ট একটি শেয়ারে সংযোগ করে, যেখানে সেই শেয়ারের নিজস্ব হোস্ট তালিকা, valid users ও শুধু-পঠন সেটিং প্রয়োগ হয়; এবং কেবল একটি ফাইল খোলার সময়ই প্রমাণিত পরিচয়ের ফাইলসিস্টেম অনুমতি সিদ্ধান্ত নেয়। প্রতিটি ধাপ নিজেই অনুরোধ প্রত্যাখ্যান করতে পারে, আর একটি পার হওয়া পরেরটি সম্পর্কে কিছু বলে না। গুরুত্বপূর্ণ পরিণতি হলো, শেয়ারের হোস্ট তালিকা মূল্যায়নের সময়ের মধ্যেই অ্যাকাউন্টটি জানা থাকে, আর হোস্ট তালিকার সেই অ্যাকাউন্টের নাম বলার কোনো উপায় তখনো নেই।
এই কারণেই একটি শেয়ার একজন ব্যবহারকারীকে একটি ঠিকানার সঙ্গে বাঁধতে পারে না: hosts allow ও valid users একই ট্রি-সংযোগ ধাপে প্রয়োগ হওয়া আলাদা শর্ত, প্রতিটি নিজের প্রশ্নের উত্তর দেয়। হোস্ট শর্তটি কখনো অ্যাকাউন্টের নাম ইনপুট হিসেবে নেয় না, তাই এটি প্রতি ব্যবহারকারীর জন্য লেখা যায় না। জোড়াটি কেবল দ্বিতীয় একটি শেয়ার বা Samba-র বাইরের একটি নীতি স্তর প্রকাশ করতে পারে।
গ্লোবাল মান গুরুত্বপূর্ণ কারণ সেগুলো কীভাবে উত্তরাধিকার হয়। যে শেয়ার hosts allow বাদ দেয় সে গ্লোবাল মান উত্তরাধিকার করে, আর যে শেয়ার নিজের মান সেট করে সে গ্লোবাল মানের জায়গায় সেই মান ব্যবহার করে, তার সঙ্গে যোগ হিসেবে নয়। তাই একটি প্রশস্ত গ্লোবাল তালিকা সেই শেয়ারগুলোকে প্রসারিত করে যেগুলো কখনো প্যারামিটার সেট করে না, আর নিজের মান নির্ধারণ করা শেয়ারের জন্য কিছুই করে না। testparm -s চালান এবং এটি যে প্রতি-শেয়ার মান ছাপে তা পড়ুন, কারণ সেই আউটপুটই কার্যকর নীতি, ডিস্কের ফাইল নয়।
একটি শেয়ার সংকীর্ণ করাও সার্ভারের বাকি অংশের জন্য কিছুই করে না। অন্য শেয়ার, প্রিন্টার সারি ও IPC সংযোগ নিজেদের নিয়ম রাখে, তাই একটি শেয়ারের ঠিকানা তালিকার উপর নির্ভর করা নকশা হোস্ট নয়, একটি পথ রক্ষা করে।
এক ডিরেক্টরির উপর দুটি শেয়ার নাম
যখন একই ডিরেক্টরি দুজন মানুষের কাছে দুটি ঠিকানা থেকে পৌঁছানোযোগ্য হতে হবে, তখন এটিকে ভিন্ন নামে দুবার প্রকাশ করুন। প্রতিটি ব্লক একটি অ্যাকাউন্ট ও একটি সোর্স বহন করে, যা জোড়াটিকে কনফিগারেশনের প্রয়োগযোগ্য কিছুতে পরিণত করে। মূল্য হলো প্রতিটি ব্যক্তি একই ফাইলে পৌঁছাতে ভিন্ন শেয়ার নাম ব্যবহার করে, আর এটি ক্লায়েন্টের দিকে সচেতন পরিবর্তন হতে হবে।
[shared-mira]
path = /srv/shared
guest ok = no
read only = yes
valid users = mira
hosts allow = 10.77.0.21
hosts deny = ALL
[shared-tomas]
path = /srv/shared
guest ok = no
read only = yes
valid users = tomas
hosts allow = 10.77.0.22
hosts deny = ALL
শেয়ার গেট কোনো ফাইলসিস্টেম অনুমতি নয়। উভয় পরিচয়েরই অন্তর্নিহিত ACL-এর মাধ্যমে ডিরেক্টরিতে প্রবেশাধিকার দরকার, আর শেয়ারের শুধু-পঠন সেটিং একমাত্র নয়, দ্বিতীয় স্তর। কর্মপ্রবাহের প্রয়োজন হলেই কেবল লেখার অনুমতি দিন, তারপর যাচাই করুন যে এক পরিচয়ের তৈরি ফাইল অন্য পরিচয়ের কাছে ব্যবহারযোগ্য থাকে।
দুটি ব্লকই একটি পথের দিকে ইশারা করে, তাই ডিরেক্টরির পরিবর্তন দুটি শেয়ারকেই প্রভাবিত করে। সাধারণত এটাই উদ্দেশ্য, তবে এর অর্থ এটাও যে অনুমতির ভুল একসঙ্গে দুজন ব্যবহারকারীর কাছেই দৃশ্যমান।
সোর্স ঠিকানা কী প্রমাণ করতে পারে
Samba যে ঠিকানা দেখে তা সার্ভারে পৌঁছানো ঠিকানা, ক্লায়েন্ট যে ঠিকানা আছে বলে মনে করে তা নয়। যে VPN গেটওয়ে প্রতিটি ক্লায়েন্টকে একটি সোর্স ঠিকানায় অনুবাদ করে তা পার্থক্যটি মুছে দেয়: সব ক্লায়েন্ট একই হোস্ট হিসেবে আসে এবং সোর্স তালিকা আর তাদের আলাদা করতে পারে না। প্রতিটি ক্লায়েন্টের জন্য স্থিতিশীল বরাদ্দ এবং সোর্স সংরক্ষণকারী গেটওয়ে ঠিকানাকে নীতি হিসেবে ব্যবহারের পূর্বশর্ত। দুটোই ছাড়া সীমাবদ্ধতা ব্যবহারকারীকে নয়, গেটওয়েকে মাপে।
তবুও, একটি ঠিকানা কোনো ডিভাইস নয়। একটি টানেল ঠিকানার পিছনে দুটি ল্যাপটপ, পুনর্বণ্টিত লিজ এবং একটি ভাগ করা ওয়ার্কস্টেশন সবই এই ধারণাকে ভেঙে দেয় যে সোর্স একজন ব্যক্তিকে চিহ্নিত করে। সীমাবদ্ধতাকে নেটওয়ার্ক পরিধি হিসেবে দেখুন এবং প্রমাণিত SMB অ্যাকাউন্টগুলিকে পরিচয় স্তর হিসেবে রাখুন, ডিভাইস অনুমোদন দরকার হলে সার্টিফিকেটের মতো ডিভাইস ক্রেডেনশিয়ালসহ।
এই কারণেই নকশাটি সার্ভার নয়, শেয়ারগুলোতে গেট বসায়। প্রত্যাখ্যাত জোড়া তবুও একটি সেশন খুলতে, অন্য শেয়ারে পৌঁছাতে বা সার্ভার তালিকাভুক্ত করতে পারে, যা সংযোগের সময় প্রমাণ ব্যর্থতার চেয়ে ভিন্ন ফলাফল। যদি প্রয়োজন হয় প্রমাণের আগেই প্রত্যাখ্যান, তাহলে Samba-র শেয়ার প্যারামিটারগুলো ভুল হাতিয়ার।
ক্রসড জোড়া দিয়ে প্রমাণ করুন
কনফিগারেশন যাচাই করুন, তারপর চারটি সমন্বয় পুনর্ব্যবহৃত সেশনের বদলে নতুন সংযোগে পরীক্ষা করুন। উদ্দিষ্ট জোড়ার ডিরেক্টরিতে পৌঁছানো উচিত, আর দুটি ক্রসড জোড়াই ব্যর্থ হওয়া উচিত। আগের পরীক্ষার ক্যাশে করা সেশন আনন্দের সঙ্গে ভুল সমন্বয়ের উত্তর দেবে এবং ভাঙা নিয়মকে সঠিক দেখাবে।
testparm -s
smbclient //fileserver/shared-mira -U mira -c 'ls'
smbclient //fileserver/shared-tomas -U tomas -c 'ls'
smbstatus --shares
সিনট্যাক্স পরীক্ষা কেবল প্রমাণ করে যে ফাইলটি পার্স হয়। ক্রেডেনশিয়াল, ACL ও হোস্ট সিদ্ধান্ত বাস্তব সংযোগে প্রয়োগ হয়, তাই যে ঠিকানা পরীক্ষা করতে চান সেখান থেকেই ক্লায়েন্ট কমান্ড চালান এবং দেখুন কোন ধাপ এটি প্রত্যাখ্যান করে। কোনো ক্রসড জোড়া সফল হলে কার্যকর হোস্ট তালিকা ব্লকের চেয়ে প্রশস্ত, আর testparm -s-ই প্রথম জিনিস যা পড়তে হবে। ক্রসড জোড়া ভুল কারণে ব্যর্থ হলে সন্দেহভাজন হলো অ্যাকাউন্ট বা ACL।
smbstatus দিয়ে সেশন পর্যবেক্ষণ ও সেগুলো বন্ধ করা প্রবেশ শুরুর পর নেওয়া প্রতিক্রিয়া, প্রবেশ নিয়ন্ত্রণ নয়। একটি সম্পূর্ণ পর্যবেক্ষিত ঠিকানা ব্লক করা একই NAT-এর পিছনে অসম্পর্কিত ব্যবহারকারীদেরও বিচ্ছিন্ন করতে পারে, তাই সিদ্ধান্তটি শেয়ার সংজ্ঞায় আর পর্যবেক্ষণ প্রতিক্রিয়া প্রক্রিয়ায় থাকা উচিত। দুটিকে আলাদা রাখুন, নকশাটি যা প্রয়োগ করে তা নিয়ে সৎ থাকবে।