میزبان کے VPN سے جڑنے کے بعد VirtualBox مہمان کا DNS بگڑ جاتا ہے

VPN جڑتے ہی Windows میزبان پر اندرونی ایپلیکیشن حل ہو جاتی ہے، لیکن VirtualBox NAT کے پیچھے موجود Ubuntu مہمان اسے ابھی تک نہیں ڈھونڈ پاتا۔ مہمان کا اپنا resolver ہے اور NAT ایڈاپٹر DNS کو ایک سے زیادہ طریقوں سے سنبھال سکتا ہے۔ مہمان کے resolver کو عوامی سرور سے بدلنے پر عام ویب سائٹیں چلتی ہیں اور نجی نام ناکام ہوتے ہیں، جو مسئلے کو حل کرنے کے بجائے کہیں اور منتقل کر دیتا ہے۔ چاروں جانچیں ترتیب سے کریں اور پہلی ناکام جانچ پر رکیں۔

تصدیق کریں کہ آپ کون سا ایڈاپٹر موڈ ڈیبگ کر رہے ہیں

اس مضمون کے مطابق صرف سادہ NAT موڈ کا ایڈاپٹر ہی اس طرح برتاؤ کرتا ہے۔ برج ایڈاپٹر اپنی شناخت کے ساتھ جسمانی نیٹ ورک پر بیٹھتا ہے، NAT نیٹ ورک اپنی DHCP اور DNS ترتیبات والا نامزد ورچوئل سوئچ ہے، اور مہمان کے اندر VPN کلائنٹ مکمل طور پر دوسرا resolver شامل کرتا ہے۔ پڑھنے سے پہلے موڈ کی تصدیق کریں، کیونکہ ان میں سے ہر صورت میں مرمت مختلف ہے۔

ایک VM مختلف موڈز میں دو ایڈاپٹر رکھ سکتا ہے، اور متاثرہ ایڈاپٹر ہمیشہ پہلا نہیں ہوتا۔

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

مہمان کے resolver کے ذریعے ایک نام کا پیچھا کریں

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

مہمان کے اندر دیکھیں کہ resolver واقعی کس چیز کے لیے تشکیل دیا گیا ہے۔ systemd-resolved چلانے والے Ubuntu مہمان میں ہر لنک کی حالت آنے والے سرور دکھاتی ہے، اور resolv.conf فائل میں صرف stub پتہ ہو سکتا ہے، جو درست ہے، مشکوک نہیں۔ ہاتھ سے ترمیم شدہ فائل یا الگ خفیہ کردہ DNS کلائنٹ تلاش کو مکمل طور پر کہیں اور بھیج سکتے ہیں۔ تبدیل کرنے سے پہلے جو ملا وہ لکھ لیں۔

resolvectl status
resolvectl query app.internal.example

یہاں حل کرنے کو رسائی سے الگ کریں۔ سروس ناقابل رسائی رہتے ہوئے آنے والا پتہ DNS نہیں بلکہ روٹنگ یا پالیسی کا سوال ہے۔

اسی ایڈاپٹر پر میزبان resolver موڈ آزمائیں

VirtualBox کے NAT DNS اختیارات مختلف طریقے بیان کرتے ہیں، اور یہ فرق اہم ہو جاتا ہے جب میزبان کا اپنا resolver ٹنل کے ساتھ بدلے۔ DNS پراکسی مہمان کی درخواستیں ان سرورز کو بھیجتی ہے جو اسے دیے گئے۔ میزبان resolver موڈ درخواستیں روک کر میزبان کی DNS API کال کرتا ہے، اور VPN کلائنٹ کے دوبارہ تشکیل کردہ Windows resolver کی پیروی کرنے والا موڈ یہی ہے۔

غلط طریقہ فعال کریں تو کمانڈ پھر بھی کامیاب ہو گی جبکہ برتاؤ تبدیل نہیں ہوگا، جو دوپہر ضائع کرنے کا ایک الجھا دینے والا طریقہ ہے۔

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

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

VPN دوبارہ جڑنے کے دوران وہی جانچیں دہرائیں

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

عوامی حل کا چلنا یہ ثابت نہیں کرتا کہ نجی استفسارات اسی راستے پر رہے جس کا آپ کی پالیسی تقاضا کرتی ہے۔

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