جب میزبان کا VPN جڑتا ہے تو Hyper-V مہمان DNS کھو دیتا ہے

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

مہمان اب بھی کیا دیکھ سکتا ہے

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

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

مہمان کون سا اخراج استعمال کر رہا ہے

Hyper-V اس کا جواب دو کمانڈوں سے دیتا ہے: Get-VMSwitch سوئچز کی فہرست دیتا ہے، اور Get-VMNetworkAdapter -VMName TestVM وہ دکھاتا ہے جس سے مہمان جڑا ہوا ہے۔ Default Switch ایک NAT نیٹ ورک ہے جسے Windows سنبھالتا ہے؛ بیرونی سوئچ ٹریفک کو طبعی اڈاپٹر کے حوالے کرتا ہے؛ اندرونی سوئچ کچھ نہیں اٹھاتا جب تک کوئی NAT یا راؤٹر شامل نہ کرے۔ VirtualBox وہی تین تصورات NAT، NAT Network اور bridged کے طور پر پیش کرتا ہے۔

موڈ طے کرتا ہے کہ میزبان کی سرنگ کو کوئی اہمیت ہو سکتی ہے یا نہیں۔ NAT مہمان کا ترجمہ WinNAT کرتا ہے اور پھر میزبان کا اسٹیک آگے بھیجتا ہے، اس لیے یہ میزبان کی روٹنگ جدول کی پیروی کرتا ہے؛ مکمل سرنگ کلائنٹ کے ساتھ اس کی ٹریفک وہی ٹریفک ہے جو VPN اڈاپٹر میں داخل ہوتی ہے، اور جب کلائنٹ مقامی ذیلی نیٹ کو روکتا ہے تو یہ خارج ہو جاتی ہے۔ بیرونی سوئچ پر پل بندھا مہمان میزبان کی روٹنگ تک کبھی نہیں پہنچتا: اس کے فریم طبعی NIC سے سیدھے نکلتے ہیں، اس لیے یہ سرنگ اور کلائنٹ کی مقامی-LAN پالیسی دونوں سے بچتا ہے۔

میزبان کی سرنگ Hyper-V کے ساتھ شیئر کرنا

اگر مہمان کو سرنگ درکار ہے اور وہ اپنا کلائنٹ نہیں چلا سکتا، تو Windows VPN کنکشن شیئر کر سکتا ہے۔ VPN اڈاپٹر کی خصوصیات کھولیں، شیئرنگ پر جائیں، اور دوسرے نیٹ ورک صارفین کو اس کے ذریعے جڑنے کی اجازت دیں۔ گھریلو نیٹ ورکنگ کنکشن کو Hyper-V اڈاپٹر کی طرف اشارہ کریں، vEthernet (Default Switch)، پھر مہمان کے اندر سے نئی درخواست آزمائیں۔

اس ترتیب کو لیبارٹری حل سمجھیں، کیونکہ یہ ایسا ہی برتاؤ کرتا ہے۔ اسے منقطع ہونے، دوبارہ جڑنے یا میزبان کے ری بوٹ کے بعد دوبارہ لاگو کرنا ہوتا ہے۔ کچھ Windows 11 بلڈز میں اڈاپٹر ڈراپ ڈاؤن سے بالکل غائب ہوتا ہے، اور تب یہ راستہ بند ہے۔

Hyper-V فیچر دوبارہ انسٹال کرنے سے کچھ ضدی مہمان بچ گئے۔ اسے آخر کے لیے رکھیں، اور پہلے مہمان کی حالت لکھیں۔

ذیلی نیٹ فلٹر ہونے پر پورٹ آگے بھیجنا

جو میزبان VPN مہمان کے NAT ذیلی نیٹ کو فلٹر کرتا ہے وہ ناموں کے حل کی نہیں، براہ راست رسائی کی تباہی کرتا ہے۔ VM چل رہا ہے، پھر بھی ssh [email protected] لٹک جاتا ہے، جبکہ ہائپر وائزر کا ترجمہ اب بھی کام کر رہا ہے۔ کام کے لیے ضروری پورٹس آگے بھیجیں اور اس کے بجائے میزبان کے پتے پر جڑیں۔ نیچے دی گئی Vagrantfile لائنیں SSH اور ایک HTTPS سروس کا احاطہ کرتی ہیں؛ دونوں دوبارہ لوڈ سے پہلے شامل کی جاتی ہیں۔

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

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

وہ جانچ جو بتاتی ہے کہ یہ کام کر گیا

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

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

ہر سوئچ یا ڈرائیور تبدیلی کو اس کے واپسی قدم کے ساتھ درج کریں۔ Microsoft کی Hyper-V NAT گائیڈ وضاحت کرتی ہے کہ Default Switch اصل میں کیا ہے، اور اس سے متصادم دوسرا NAT نیٹ ورک بنانے سے پہلے اسے پڑھنا قابلِ قدر ہے۔