روٹ شدہ OpenVPN ٹنل پر ناموں کی تلاش کیوں ناکام ہوتی ہے

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

افسانہ: نام ناکام ہونے کی وجہ سے ٹنل خراب ہے

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

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

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

TUN کیا لے جاتی ہے اور کیا نہیں

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

دریافت کی ٹریفک اس ماڈل میں بالکل فٹ نہیں ہوتی۔ Windows کے پرانے نام کے استفسارات، SSDP اعلانات اور mDNS درخواستیں ایک منزل کی بجائے حصے میں سب کو بھیجی جاتی ہیں۔ روٹ شدہ رابطے کے پاس بھیجنے کے لیے کوئی «سب» نہیں ہوتا۔ ان میں سے ہر طریقہ کار مشترک وسیلہ فرض کرتا ہے۔

اس لیے ٹنل صحت مند ہو سکتی ہے جبکہ دریافت مکمل طور پر ناکام ہو۔ جب کوئی بتائے کہ VPN ڈاؤن ہے تو یہی جملہ تھامنا ہے۔

پل بنانا حد ہٹا کر کام کرتا ہے

TAP آلہ فریم لے جاتا ہے، اور پل اسے حقیقی LAN حصے سے جوڑتا ہے۔ پھر کلائنٹ کے پاس اس حصے پر پتہ ہوتا ہے اور وہ اس کی براڈکاسٹ ٹریفک سنتا ہے۔ اسی لیے پل بنانا نام کے مسئلے کا علاج لگتا ہے۔ یہ کلائنٹ کو پتوں کے لیے اس حصے پر منحصر بھی کر دیتا ہے۔

علاج روٹنگ حد کو ہٹانا ہے، ٹنل کے اندر نام رکھنے کی کوئی نئی صلاحیت نہیں۔ حصہ جو براڈکاسٹ کرتا ہے اب وہ رابطہ بھی عبور کرتا ہے۔

چھوٹی لیب کے لیے یہ منصفانہ تبادلہ ہے۔ بکھری ہوئی افرادی قوت کے لیے ایسا کم ہی ہوتا ہے۔

DNS اور WINS کو دھکیلنا مختصر ترمیم ہے

کلائنٹ کو پوچھنے کے لیے مخصوص جگہ دیں۔ dhcp-option DNS اور dhcp-option DOMAIN اندرونی ناموں کو زون جاننے والے سرور کی طرف موڑتے ہیں، اور NetBIOS پر اب بھی انحصار کرنے والا Windows کلائنٹ اسی طرح WINS سرور حاصل کر سکتا ہے۔ ٹنل روٹ شدہ رہتی ہے اور حصہ اپنی جگہ پر رہتا ہے۔

دو شرطیں طے کرتی ہیں کہ یہ کام کرے گا یا نہیں۔ مذکورہ سرور کو زون کے لیے جواب دینا ہوگا، اور استفسار کو ٹنل سے اجازت ہونی چاہیے۔

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

معلوم کریں کہ کون سی تہہ ناکام ہوئی

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

ملٹی کاسٹ اسی دیوار کے پیچھے ہے۔ 224.0.0.251 جیسا گروپ بطور طے شدہ روٹ شدہ ٹنل سے آگے نہیں بھیجا جاتا، اور گروپ کے لیے راستہ ملٹی کاسٹ سمجھنے والے راستے یا LAN پر منعکس کنندہ کے بغیر کافی نہیں۔