کیا Hyper-V VM میزبان کا VPN استعمال کرتی ہے؟ یہ سوئچ پر منحصر ہے

Hyper-V میزبان پر VPN کلائنٹ نصب کریں، وہاں براؤزر کھولیں اور خارجی پتہ بدل جاتا ہے؛ وہی صفحہ VM کے اندر کھولیں تو یہ پرانا پتہ یا کچھ بھی نہیں دکھا سکتا۔ معمول کا نتیجہ یہ ہوتا ہے کہ VM خراب ہے، یا split tunneling چالو کرنا ضروری ہے۔ دونوں میں سے کوئی بات لازم نہیں۔ VPN کلائنٹ مشین کی خوصیت نہیں؛ یہ راستوں کا مجموعہ، ایک مجازی اڈاپٹر اور اکثر مختلف انٹرفیس سے جڑا فلٹر ہے۔ مہمان کی ٹریفک اس نظام تک پہنچتی ہے یا نہیں، یہ مہمان کے استعمال کردہ مجازی سوئچ پر منحصر ہے۔

افسانہ، صاف لفظوں میں

یہ عقیدہ ہے کہ میزبان پر نصب VPN پوری مشین کو، VM سمیت، محفوظ رکھتا ہے، کیوں کہ VM محض اسی مشین پر چلنے والا عمل ہے۔ یہ آرام دہ عقیدہ ہے، کیوں کہ اینٹی وائرس اور میزبان فائر وال عموماً ایسا ہی برتاؤ کرتے ہیں۔ نیٹ ورک راستے ایسا نہیں کرتے۔

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

سوئچ کی تین اقسام، تین راستے

بیرونی سوئچ مجازی اڈاپٹر کو جسمانی نیٹ ورک کارڈ سے باندھتا ہے، اور مہمان اپنے MAC پتے کے ساتھ اس بندھن سے فریم بھیجتا ہے۔ مہمان جسمانی نیٹ ورک میں اپنے DHCP لیز، گیٹ وے اور DNS سرورز کے ساتھ ہم رتبہ رکنے والا بن جاتا ہے۔ میزبان کا VPN طے شدہ راستہ میزبان اسٹیک میں رہتا ہے اور ان فریموں کو نہیں ہلاتا، کیوں کہ وہ میزبان کے ذریعے روٹ ہونے کے بجائے بریج ہوتے ہیں۔ Wi-Fi اڈاپٹر پر بیرونی سوئچ کا برا خیال ہونے کی وجہ بھی یہی ہے: زیادہ تر وائرلیس ڈرائیور دوسرے MAC پتے کے لیے فریم نہیں اٹھاتے۔

اندرونی سوئچ مہمانوں کو میزبان کے مجازی اڈاپٹر سے جوڑتا ہے۔ اکیلا یہ انٹرنیٹ کا راستہ فراہم نہیں کرتا؛ میزبان پر NAT آبجیکٹ ترجمانی فراہم کرتا ہے، جس کی تفصیل Hyper-V NAT گائیڈ میں ہے۔ اب مہمان کے پیکٹ میزبان کی روٹنگ اور NAT راہ میں داخل ہوتے ہیں، لہذا VPN کلائنٹ کے راستے اور فلٹر پھر اہم ہو جاتے ہیں۔ یہی وہ ترتیب ہے جس میں VM واقعی میزبان کے VPN کی پیروی کرتی ہے، اور جہاں kill switch مہمان کو مکمل طور پر کاٹ سکتا ہے۔

نجی سوئچ میں میزبان اڈاپٹر اور اوپر کا لنک نہیں ہوتا۔ مہمان صرف ایک دوسرے سے بات کرتے ہیں، لہذا اگر نجی سوئچ پر VM کے پاس انٹرنیٹ نہیں ہے تو وجہ غائب راؤٹر ہے اور VPN کا اس سے کوئی تعلق نہیں۔

طے شدہ سوئچ اپنی الگ ترتیب ہے

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

اگر VM طے شدہ سوئچ پر ہے تو مہمان کو ملنے والا پتہ پڑھیں اور VPN کلائنٹ کو چھونے سے پہلے اسے میزبان کی NAT جدول سے موازنہ کریں۔ مہمان کے گیٹ وے اور NAT سابقے کے درمیان فرق کسی بھی کلائنٹ ترتیب سے زیادہ ناکامیاں واضح کرتا ہے۔

چار حقائق جو سوال طے کرتے ہیں

کچھ بھی بدلنے سے پہلے یہ جمع کریں: سوئچ کی قسم اور اس کا اوپر کا لنک، VM سے جڑا اڈاپٹر، مہمان کا اپنا پتہ، گیٹ وے اور DNS، اور میزبان کی NAT اور طے شدہ راستے کی حالت۔ صرف پڑھنے والی کمانڈز Get-VMSwitch، Get-VMNetworkAdapter -VMName "TestVM"، Get-NetNat اور Get-NetRoute -DestinationPrefix 0.0.0.0/0 ہیں؛ مہمان کے اندر ipconfig /all باقی بتاتی ہے۔

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

مہمان کے اندر کا امتحان ہی واحد ثبوت ہے جو شمار ہوتا ہے۔ مہمان سے خارجی پتہ دیکھیں، اندرونی نام حل کریں، VPN دوبارہ جوڑیں اور دہرائیں۔ میزبان کے براؤزر کا نتیجہ ان میں سے کسی کا متبادل نہیں ہے۔

افسانے کی قیمت

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

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

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