VPN پتے پر Samba: سننے والا کیوں غائب ہو جاتا ہے

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

شیئرنگ ٹنل دوبارہ شروع ہونے تک کام کرتی ہے

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

اگر نیا پتہ ICMP کا جواب دے تو ping اب بھی کامیاب ہو سکتا ہے، اسی لیے شیئرنگ کے مرنے کے باوجود رسائی ٹھیک دکھتی ہے۔ یہی ایک گمراہ کن کامیابی لوگوں کو فائر وال کی طرف بھیجتی ہے۔

رسائی باندھنے کا پتہ نہیں ہے

یہاں تین فیصلے مل جاتے ہیں۔ راستہ طے کرتا ہے کہ کلائنٹ کا پیکٹ پہنچتا ہے یا نہیں۔ سننے والا ساکٹ طے کرتا ہے کہ مقامی پتے پر کوئی اسے قبول کرتا ہے یا نہیں۔ شیئرنگ کی ترتیب اور فائل سسٹم کی اجازتیں طے کرتی ہیں کہ اس کے بعد کیا ہوتا ہے۔ انٹرفیس دوبارہ بننے پر صرف دوسرا ٹوٹتا ہے۔

VPN پول کا پتہ بھی خود بخود مقامی باندھنے کا پتہ نہیں ہوتا۔ وہ ایک کلائنٹ کا ہے، فائل سرور کا نہیں۔ فائل خدمت کے لیے ping کمزور جانچ ہے۔

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

اس کے بجائے مستحکم پتے سے باندھیں

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

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

ss -ltnp | grep ':445'

دوبارہ جڑنے کی جانچ کریں، ہری بتی کی نہیں

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

smbclient -L //files.corp.example -U alice

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