OpenVPN کی جانب سے DNS دھکیلنے کے بعد مقامی Samba شیئر غائب ہو گیا

Samba مقامی شیئرز اسی لمحے کھو دیتا ہے جب OpenVPN منسلک ہوتا ہے، اور ٹنل تقریباً کبھی وجہ نہیں ہوتا۔ ماؤنٹ ٹھیک ہے، NAS چل رہا ہے، اور ٹنل کا نصب کردہ حل کنندہ ایسے نام کے بارے میں سوالات کا جواب دے رہا ہے جو اس نے کبھی نہیں دیکھا۔ Samba اپنی تلاش کی ترتیب میں شروع ہی میں اس حل کنندہ سے پوچھتا ہے، جواب پر یقین کرتا ہے اور ایسے پتے سے جڑ جاتا ہے جہاں کوئی نہیں سن رہا۔ شیئر درست کرنے کا مطلب ماؤنٹ نہیں، جواب درست کرنا ہے۔

پانچ جانچیں، اس ترتیب سے جو ہر قدم پر سب سے زیادہ امکانات خارج کرتی ہے۔

مختصر نام کا جواب کون دیتا ہے

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

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

Samba غلط جواب کیوں مان لیتا ہے

Samba ناموں کو name resolve order کے طے کردہ مقررہ تسلسل سے حل کرتا ہے۔ زیادہ تر ڈسٹری بیوشنز میں ڈیفالٹ میں host شامل ہوتا ہے، یعنی DNS، اور یہ NetBIOS نشریات جیسے صرف-لین طریقہ کاروں سے پہلے چلتا ہے۔ اس لیے حل کنندہ دھکیلنے والی ٹنل کو ہر شیئر نام پر پہلے انکار کا حق ملتا ہے، جن میں یک-لیبل نام بھی شامل ہیں جنہیں کبھی عمارت سے باہر نہیں جانا تھا۔

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

نتیجہ ایسا شیئر ہے جو خرابی کے مکالمے کے بغیر غائب ہو جاتا ہے۔ اس تسلسل میں کچھ بھی VPN روٹنگ کی ناکامی نہیں ہے، اسی لیے NAS کو ping اب بھی کام کرتا ہے جبکہ اس پر براؤز کرنا کام نہیں کرتا۔

مختلف دائرے کی دو مرمت

تنگ مرمت دھکیلا گیا حل کنندہ رکھتی ہے اور بدلتی ہے کہ Samba اس سے کیا پوچھ سکتا ہے۔ ڈیمن کے اصل میں پڑھنے والی Samba کنفیگریشن میں دو سطریں شامل کریں، پھر سروس دوبارہ شروع کریں:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

اس فہرست میں host نہ ہونے پر DNS شیئر تلاش کے راستے سے نکل جاتا ہے، اور یک-لیبل نام مقامی حصے میں رہتے ہیں۔ دفتر کے نام ہر دوسرے پروگرام کے لیے اب بھی معمول کے مطابق حل ہوتے ہیں، کیونکہ یہ صرف Samba بدلتا ہے۔ قیمت یہ ہے کہ Samba اب DNS بالکل استعمال نہیں کر سکتا، اس لیے مکمل طور پر اہل دفتر نام سے پتہ شدہ شیئر مسئلہ بن جاتا ہے۔

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

ایک جان بوجھ کر چنیں۔ حل کنندہ کی تبدیلی ایک ہی وقت میں ہر ایپلیکیشن کے نام کی حل پذیری بدلتی ہے، جو تبدیلی ریکارڈ ہے، سپورٹ کال کے لیے تدوین نہیں۔

لاحقہ سب کچھ بیان کر سکتا ہے

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

یہاں حل یا تو مکمل طور پر اہل مقامی نام استعمال کرنا ہے یا تقسیم شدہ DNS قاعدہ شامل کرنا ہے جو مقامی لاحقے کا مالک ہو۔ دونوں میں سے کسی کو Samba چھونے کی ضرورت نہیں۔

دوبارہ منسلک ہونے کے بعد اسے ثابت کریں

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

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

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