ورچوئل مشین میں VPN کے ذریعے نجی سروس تک کیسے پہنچا جائے

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

کچھ بھی بدلنے سے پہلے دونوں راستے لکھیں

مہمان پر، ipconfig /all وہ اڈاپٹر دکھاتا ہے جو VPN ٹرانسپورٹ اٹھاتا ہے اور وہ پتہ جو اسے ورچوئل نیٹ ورک کے DHCP سے ملا۔ Mac پر، وہ ورچوئل انٹرفیس لکھیں جو ہائپر وائزر نے اس حصے کے لیے بنایا؛ VMware Fusion میں صرف میزبان کے لیے مخصوص ڈیوائس عام طور پر vmnet1 ہوتی ہے، اور Parallels اپنا نام دیتا ہے۔ دیکھیں کہ وہاں پتے کون تقسیم کرتا ہے، پھر سب کچھ لکھیں، کیونکہ ورچوئل نیٹ ورک دوبارہ بننے پر صرف میزبان کے لیے مخصوص سب نیٹ اکثر دوبارہ تفویض ہوتا ہے۔ ورچوئل مشین کا نیٹ ورک موڈ ہائپر وائزر میں دیکھیں، اپنی یادداشت میں نہیں۔ انٹرنیٹ کی طرف والے اڈاپٹر کے لیے مشترکہ یا NAT موڈ اور Mac کی طرف والے اڈاپٹر کے لیے صرف میزبان کا موڈ ہی وہ ترتیب ہے جو یہ مراحل فرض کرتے ہیں۔

دو اڈاپٹر، دو مقاصد۔ انہیں اس طرح ملانا کہ ایک ہی اڈاپٹر Mac اور انٹرنیٹ دونوں کی خدمت کرے، یہی تنگ دروازے کو روٹ شدہ راستہ بناتا ہے۔

پہلے مہمان کا اپنا VPN یقینی بنائیں

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

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

صرف میزبان والا بازو شامل کریں اور اسے تنہا جانچیں

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

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

ایک پورٹ آگے بھیجیں، سب نیٹ نہیں

عام IP فارورڈنگ کے بجائے ایک ہی آگے بھیجا گیا پورٹ ترجیح دیں۔ Windows netsh interface portproxy فراہم کرتا ہے، جو سننے والے پورٹ کو منزل کے میزبان اور پورٹ کی طرف بھیجتا ہے، اور اس کے لیے IP Helper سروس کا چلنا ضروری ہے۔

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

تصدیق کریں، پھر واپسی کا منصوبہ لکھیں

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

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