VMware کا برج والا مہمان OpenVPN کے بعد اپنا نیٹ ورک کھو بیٹھا

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

مہمان نہیں بدلا، برج بدلا

Windows پر OpenVPN کلائنٹ انسٹال کرنے سے ایک ورچوئل نیٹ ورک اڈاپٹر شامل ہوتا ہے جس سے سروس اس وقت بندھتی ہے جب ٹنل اوپر آتا ہے۔ آپریٹنگ سسٹم کے لیے یہ لنک اسٹیٹ والا ایک عام انٹرفیس اور اکثر اپنے پتوں والا دکھائی دیتا ہے۔ یہی VMware کے لیے اسے برج امیدوار سمجھنے کو کافی ہے۔

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

برج پن کریں یا مہمان کو روٹ کریں

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

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

پہلی شاخ کے لیے میزبان پر ورچوئل نیٹ ورک ایڈیٹر کھولیں، VMnet0 منتخب کریں اور خودکار کو فزیکل اڈاپٹر سے بدلیں۔ اگر کئی اڈاپٹر ہیں تو خودکار سیٹنگز کی فہرست استعمال کریں اور ہر اس چیز کا نشان ہٹائیں جسے کبھی مہمان ٹریفک نہیں ڈھونا چاہیے: OpenVPN TAP یا Wintun ڈیوائس، نیز Hyper-V، WSL، Docker اور loopback اڈاپٹر۔ لیپ ٹاپ پر وائرڈ اور وائرلیس دونوں فزیکل اڈاپٹر نشان زد رکھیں، ورنہ اگلی بار جب صارف اسے ڈاک میں لگائے گا مہمان اپنا برج کھو دے گا۔

تین شرطیں جو انتخاب طے کرتی ہیں

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

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

VMware Player کے انٹرفیس میں نیٹ ورک ایڈیٹر نہیں ہے، اس لیے جو میزبان صرف Player چلاتا ہے اسے ان سیٹنگز تک پہنچنے کے لیے الگ ایڈیٹر یا Workstation انسٹال چاہیے۔ یہ رکاوٹ کبھی کبھی نقطۂ نظر خود ہی طے کر دیتی ہے۔

نتیجہ مہمان کے اندر سے پڑھیں

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

ipconfig /all
ip addr
ip route

اس آؤٹ پٹ میں دو فیلڈز پڑھیں اور باقی کو ابھی نظر انداز کریں۔ گیٹ وے LAN روٹر ہونا چاہیے، اور اڈاپٹر کی تفصیل ٹنل کے بجائے VMware Ethernet ڈیوائس بتانی چاہیے۔ 169.254.0.0/16 میں خود مختص کیا گیا پتہ اس کا مطلب ہے کہ کوئی DHCP سرور جواب نہیں دے سکا، اور مہمان کی طرف سے ٹنل اڈاپٹر پر برج بالکل ایسا ہی دکھتا ہے۔

کچھ اور بدلنے سے پہلے ایک اور فرق کرنا مناسب ہے۔ جو مہمان روٹر تک پہنچتا ہے مگر انٹرنیٹ تک نہیں، اس کا برج کام کر رہا ہے اور مسئلہ اوپر کی طرف ہے۔ جو مہمان ٹنل کی حد میں پتہ پاتا ہے وہ اب بھی غلط ڈیوائس سے جڑا ہے۔ TAP اڈاپٹر بند کرنا دونوں میں سے کسی صورت کا حل نہیں، کیونکہ OpenVPN سروس کو اس کی ضرورت ہے۔