Samba ان VPN کلائنٹس کو کیوں مسترد کرتا ہے جو سرور تک پہنچتے ہیں

ایک VPN کلائنٹ فائل سرور کو پنگ کرتا ہے، اس کا نام حل کرتا ہے اور پھر بھی شیئر نہیں کھول سکتا۔ Samba کی ہوسٹ پالیسی ان چار تہوں میں سے ایک ہے جو اس کنکشن کو مسترد کر سکتی ہیں، اور لوگ سب سے آخر میں اسی کو تبدیل کرتے ہیں۔ اجازت کی فہرست اس ماخذ پتے کے خلاف جانچی جاتی ہے جو smbd واقعی وصول کرتا ہے، اور یہ وہ پتہ نہیں ہو سکتا جو کلائنٹ سمجھتا ہے کہ اس کے پاس ہے۔ اس ماخذ کو درست طور پر معلوم کرنا ایک غیر واضح اجازت کے مسئلے کو ایک سطر کی ترتیب کی تبدیلی میں بدل دیتا ہے۔

ایک ہی پیغام کے ساتھ ناکام ہونے والی چار تہیں

مسترد ہونا راستے، ہوسٹ فائر وال، Samba کی ہوسٹ پالیسی یا SMB شناخت سے آ سکتا ہے۔ ہر تہہ کلائنٹ کو تقریباً وہی بات کہنے والا پیغام دیتی ہے، اسی لیے اندازہ لگانے میں آدھا دن لگتا ہے۔ جانچ کو نیٹ ورک سے اندر کی طرف ترتیب دینے سے زیادہ تر اندازے ختم ہو جاتے ہیں۔

ٹرانسپورٹ سے شروع کریں۔ اگر پورٹ 445 کبھی سرور تک نہیں پہنچتا، تو کوئی بھی Samba ترتیب اہم نہیں، اور سرور کے انٹرفیس پر کیپچر اسے سیکنڈوں میں طے کر دیتا ہے۔ اگلی سرور پر ہی ہوسٹ فائر وال آتی ہے، جو اجازت یافتہ ماخذ کو smbd کے دیکھنے سے پہلے ہی گرا سکتی ہے۔ ان دونوں کے گزرنے کے بعد ہی اجازت کی فہرست امیدوار بنتی ہے۔ توثیق سب سے آخر میں آتی ہے، کیونکہ لاگ ان کی ناکامی اور ہوسٹ کا انکار سرور لاگ میں مختلف نظر آتے ہیں، چاہے کلائنٹ دونوں کو رسائی سے انکار بتائے۔ ترتیب اوزاروں سے زیادہ اہم ہے، کیونکہ ہر تہہ کے پاس اس کا جواب دینے والا ایک حکم ہے۔

وہ ماخذ پتہ تلاش کریں جو smbd واقعی دیکھتا ہے

روٹڈ رسائی میں سرور عام طور پر کلائنٹ کا پتہ VPN پول سے دیکھتا ہے۔ گیٹ وے پر ماخذ کی ترجمہ ہو تو یہ اس کے بجائے گیٹ وے کا LAN پتہ دیکھتا ہے، اور اس گیٹ وے کے پیچھے ہر کلائنٹ الگ نہیں پہچانا جا سکتا۔

یہی فرق طے کرتا ہے کہ اجازت کی فہرست کا اندراج پالیسی ہے یا سوراخ۔ ترجمہ شدہ گیٹ وے پتے کی اجازت دینا اس کے پیچھے سب کو اندر لے لیتی ہے، جو فی کلائنٹ قاعدہ شاذ و نادر ہی بیان کرنا چاہتا تھا۔ ماخذ سرور پر پڑھیں، کلائنٹ کے اپنے پتے کے بارے میں تصور سے نہیں۔ سرور کے انٹرفیس پر کیپچر اسے دیکھنے کا سب سے سستا طریقہ ہے، اور وہی کیپچر یہ بھی ثابت کرتا ہے کہ پیکٹ آیا یا نہیں۔ کیپچر کو پیکٹ کی تعداد سے محدود کریں اور جب معلوم ہو کہ کس کلائنٹ کا پیچھا کر رہے ہیں تو ہوسٹ فلٹر شامل کریں۔ Samba کا سیشن جدول جواب کا دوسرا نصف ہے: smbstatus -b میں ہر سیشن سطر کا کلائنٹ کالم وہ ساتھی ہے جو smbd نے ریکارڈ کیا، اور یہ اس پتے کی تیز ترین تصدیق ہے جو واقعی سروس تک پہنچا۔

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

اجازت کی فہرست ویسے پڑھیں جیسے Samba پڑھتا ہے

hosts allow کی ترتیب پتوں، نیٹ ورکوں یا ناموں کی فہرست لیتی ہے، اور یہ عالمی سطح پر یا کسی شیئر کے اندر ہو سکتی ہے۔ آپ کو برابر لگنے والے دو اندراج تجزیہ کار کے لیے برابر نہ ہوں، اس لیے مؤثر ترتیب ہی وہ چیز ہے جسے جانچنا چاہیے۔ اس کا مطلب یکجا منظر ہے، وہ فائل نہیں جو آپ نے اتفاقاً تبدیل کی۔

مثال کے طور پر دو سابقے نیچے دی گئی سطر جیسے لگتے ہیں، اور یہ مثال ہے، پہلے سے موجود اندراجات کا متبادل نہیں۔ آج قانونی طور پر جڑنے والے انتظامی اور ایپلیکیشن کلائنٹ رکھیں، اور کوئی بھی پابندی کی فہرست اسی مرحلے میں پڑھیں۔ ہوسٹ قبول ہوگا یا نہیں یہ مجموعی پالیسی پر منحصر ہے، اس لیے ترجیح پر سوچنے کے بجائے ٹھیک اسی کلائنٹ کو آزمائیں۔ ہوسٹ کی اجازت شیئر کی اجازتوں یا فائل سسٹم کے طریقوں کے بارے میں بھی کچھ نہیں کہتی، جو الگ دروازے ہیں۔ جانچ کے اوزاروں کی کامیابی کا مطلب ہے کہ ہوسٹ پالیسی اس ماخذ کو قبول کرتی ہے، اور اس سے زیادہ کچھ نہیں۔

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

وہ فائل تبدیل کریں جو دوبارہ شروع ہونے کے بعد بھی رہے

عام Linux ہوسٹ پر ترتیب کا راستہ مقرر ہوتا ہے اور ری اسٹارٹ پر سروس اسے دوبارہ پڑھتی ہے۔ راؤٹر یا آلات پر چلتی smb.conf اکثر بوٹ پر بنتی ہے، اور ہاتھ سے کی گئی تبدیلی اگلے ریبوٹ پر غائب ہو جاتی ہے۔ آلات کی معاون تخصیص کا طریقہ استعمال کریں، جو عام طور پر اس کی اپنی ترتیب کی فائل ہوتی ہے۔

اس مرحلے پر لالچ یہ ہے کہ متبادل فرم ویئر فلیش کیا جائے کیونکہ ایک تھریڈ نے بتایا کہ یہ کام کرتا ہے۔ یہ چھوٹی پالیسی کے مسئلے کے لیے بڑی تبدیلی ہے، اور ڈیوائس کو اس کی معاون حالت سے باہر لے جاتی ہے۔ پہلے معاون کنٹرول کی نشاندہی کریں، کیونکہ زیادہ تر آلات اجازت کی فہرست اپنے انٹرفیس سے دکھاتے ہیں۔ اگر وہ واقعی ایسا نہیں کرتے، تو یہ حد مختلف ہارڈ ویئر کے حق میں دلیل ہے، غیر معاون بلڈ کے حق میں نہیں۔

لکھیں کہ آپ نے کون سی فائل تبدیل کی اور اسے کیا دوبارہ بناتا ہے، تاکہ اگلا شخص تشخیص دہرائے نہ۔

ایک اجازت یافتہ اور ایک خارج شدہ کلائنٹ کی جانچ کریں

دونوں نتائج کی جانچ کریں، صرف اس کی نہیں جو آپ چاہتے تھے۔ جڑنے والا اجازت یافتہ کلائنٹ ثابت کرتا ہے کہ تبدیلی کام کرتی ہے؛ اب بھی مسترد ہونے والا خارج شدہ کلائنٹ ثابت کرتا ہے کہ قاعدے نے صرف سب کچھ نہیں کھولا۔

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

جب کنکشن کبھی smbd تک نہ پہنچے، تو جواب راستہ بندی میں یا سرور کی فائر وال میں ہوتا ہے۔ اگر ہوسٹ کو اجازت ہو اور لاگ ان ناکام ہو، تو مسئلہ شناخت کا ہے اور اجازت کی فہرست دوبارہ وسیع کرنے سے مدد نہیں ملے گی۔ تشخیصی آؤٹ پٹ نجی رکھیں، کیونکہ تفصیلی Samba لاگ شیئر کے راستے اور اکاؤنٹ کے نام ظاہر کر سکتا ہے۔ ہر کوشش پر ایک تہہ تبدیل کریں، ورنہ اگلا نتیجہ آپ کو کچھ نہیں بتائے گا۔