Samba شیئر کو ایک صارف اور ایک VPN پتے تک محدود کریں

اس ڈیزائن میں دو مختلف اجازتیں گڈمڈ ہو جاتی ہیں: کون ڈائریکٹری استعمال کر سکتا ہے، اور کون سے پتے جڑ ہی سکتے ہیں۔ ماخذ کی فہرست کے ساتھ اکاؤنٹ کی فہرست لکھنا جوڑے جیسا لگتا ہے، لیکن 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 کے پیچھے غیر متعلق صارفین کو بھی منقطع کر سکتا ہے، اس لیے فیصلہ شیئر کی تعریف میں اور نگرانی ردعمل کے عمل میں رہنی چاہیے۔ دونوں کو الگ رکھیں اور ڈیزائن اس بارے میں دیانت دار رہتا ہے کہ وہ کیا نافذ کرتا ہے۔