ESXi مہمان VPN: روٹنگ یا بریجنگ — پورٹ گروپ سے پہلے فیصلہ کریں
روٹڈ TUN کو واپسی روٹ درکار ہیں؛ برجڈ TAP کو لیئر 2 رسائی اور وسیع تر پورٹ گروپ پالیسی درکار ہے۔ promiscuous موڈ بڑھانے سے پہلے کردار طے کریں۔
پیکٹ روٹ کریں یا Ethernet ڈومین بڑھائیں: پورٹ گروپ کی تبدیلی اسی انتخاب کے بعد آتی ہے۔ نجی پتہ رکھنے والی ایپلیکیشن کی نظر میں نتائج ایک جیسے لگ سکتے ہیں، جبکہ ہائپر وائزر کی ضروریات بالکل مختلف ہوتی ہیں۔ اسی لیے پہلے پورٹ گروپ وسیع کیا جاتا ہے اور ڈیزائن کا سوال بعد میں حل ہوتا ہے، عام طور پر براڈکاسٹ طوفان کے بعد۔ یہ جانچیں ترتیب سے کریں اور جب ضرورت ابھی مبہم ہو تو رک جائیں، کیونکہ کوئی بھی پورٹ-گروپ سیٹنگ ایسا ڈیزائن درست نہیں کرتی جو کبھی منتخب ہی نہ ہوا ہو۔
فیصلہ سروس کے مالک کا ہے؛ ہائپر وائزر کنفیگریشن کو اسے نافذ کرنا چاہیے، اتفاق سے طے نہیں کرنا چاہیے۔
دیکھیں کہ دور والے سرے کو درحقیقت کیا چاہیے
ان سروسز کی فہرست بنائیں جن تک دور دراز کے کلائنٹ کو پہنچنا ہے اور وہ پروٹوکول جو وہ استعمال کرتے ہیں۔ اگر فہرست معلوم پری فکسز پر چند TCP سروسز ہے تو روٹنگ کافی ہے۔ اگر کسی چیز کو واقعی لیئر 2 قربت درکار ہو — براڈکاسٹ پر منحصر دریافت، غیر IP پروٹوکول، ایسا آلہ جو گیٹ وے قبول نہ کرے — تو روٹنگ اس کی نقل نہیں کر سکتی اور یہ جلد کہنا چاہیے۔ اس فہرست میں غیر IP اندراجات کے بارے میں ایماندار رہیں، کیونکہ وہیں روٹڈ ڈیزائن ایک ہفتے بعد خاموشی سے ناکام ہوتا ہے۔
پھر کلائنٹ پول دیکھیں۔ روٹڈ ڈیزائن کو پتوں کی حد اور دور والے کنارے پر واضح واپسی روٹ درکار ہے؛ برجڈ ڈیزائن کو توسیع شدہ Ethernet ڈومین کا پتہ تقسیم اور تنہائی کا مالک ہونا چاہیے۔ آپ جو بھی منتخب کریں، اس VM سے باہر کسی کو اس پر متفق ہونا ہوگا۔
ہر ڈیزائن ورچوئل نیٹ ورک سے کیا مانگتا ہے
دونوں ڈیزائن اس میں مختلف ہیں کہ ورچوئل نیٹ ورک کو کیا سہنا ہے، اور جدول اسے دیکھنے کا مختصر ترین طریقہ ہے:
| ڈیزائن | مہمان کی طرف کردار | ورچوئل نیٹ ورک کو کیا سمانا ہے | غلط انتخاب پر ناکامی کا انداز |
|---|---|---|---|
| روٹڈ TUN | الگ پری فکسز کے درمیان راؤٹر | روٹڈ کلائنٹ پول اور دور والے کنارے پر واپسی راستے | کلائنٹ گیٹ وے تک پہنچتے ہیں اور اس کے پیچھے کی سروس تک کبھی نہیں پہنچتے |
| برجڈ TAP | شامل ہونے والے کلائنٹ کے لیے لیئر 2 برج | اضافی Ethernet شناختیں، براڈکاسٹ ٹریفک اور VLAN قواعد | vSwitch فریم گرتا ہے، یا ڈیزائن کو ایسا promiscuous موڈ درکار ہے جسے کسی نے منظور نہیں کیا |
روٹنگ براڈکاسٹ ڈومین کو جہاں ہے وہیں رکھتی ہے اور گیٹ وے عبور کرنے والی سروسز کو محدود کرنے کی قدرتی جگہ دیتی ہے۔ بریجنگ حد کو ہلاتی ہے: کلائنٹ توسیع شدہ Ethernet ڈومین کے شریک ہو جاتے ہیں، اور پتہ تقسیم، تنہائی اور کوئی بھی لیئر 2 پالیسی اب ان پر لاگو ہوتی ہے۔ منتخب شدہ سطر تبدیلی ریکارڈ میں لکھیں۔ «روٹڈ TUN، کلائنٹ پول 10.90.0.0/24، کور پر واپسی روٹ» جیسا جملہ اگلے انجینئر کو پورٹ-گروپ سیٹنگز سے ڈیزائن دوبارہ بحث کرنے سے روکتا ہے۔
کون کس کے فریم دیکھ سکے
پورٹ گروپ کو چھونے سے پہلے پلیٹ فارم کے مالک سے ایک سوال پوچھیں: کیا ڈیزائن چاہتا ہے کہ یہ VM دوسرے شرکاء کو بھیجے گئے فریم وصول کرے؟ اگر جواب نہیں ہے تو اس حصے میں کچھ لاگو نہیں ہوتا، کیونکہ روٹڈ TUN کو وہ مرئیت کبھی درکار نہیں ہوتی۔ اگر جواب ہاں ہے تو، promiscuous موڈ کے بارے میں Broadcom کی رہنمائی وہ اہم مطالعہ ہے: یہ بتاتی ہے کہ VM vSwitch میں سے کتنا زیادہ دیکھ سکتا ہے اور اس پالیسی کو ایک پورٹ گروپ تک محدود رکھنے کی سفارش کرتی ہے۔
اسے اجازت نامہ نہیں، ضرورت کی جانچ سمجھیں۔ جب بریجنگ کی ضرورت لکھی جائے تو ایک مخصوص کنکشن کے لیے سیٹنگ آن کریں، اور باقی ہر جگہ بند رکھیں۔ دوسری برج مثال سے نقل کیا گیا چوڑا VLAN ٹرنک وہ حصہ ہے جسے ہٹانا کسی کو یاد نہیں رہتا، اور ایک-VLAN ڈیزائن ایک-VLAN ہی رہنا چاہیے۔
کون سا پورٹ گروپ بدلا اور کیوں، یہ اسی جگہ درج کریں جہاں ڈیزائن کی سطر لکھی تھی۔ یہی جوڑی اگلی آڈٹ کو ممکن بناتی ہے۔
مہمان کی اشیاء واضح رکھیں
Linux کے اندر، برج کی رکنیت اور پتے کی ملکیت الگ اشیاء ہیں، اور انہیں ملانا الجھن بھرا آدھا کام کرنے والا حالت بناتا ہے۔ پتے برج انٹرفیس یا روٹڈ ٹنل کو دیں، ایک ہی راستے کے دونوں کناروں کو نہیں، اور رکن پورٹس کو IP کنفیگریشن سے خالی رکھیں۔
ایک سب نیٹ کو خودمختار طور پر روٹڈ TUN پر اور غیر متعلقہ Ethernet انٹرفیس پر رکھنے سے بچیں۔ وہ کنفیگریشن ایک ہی پری فکس تک دو راستے پیدا کرتی ہے، غیر متناسب جوابات اور flapping کے بارے میں مدد کا دھاگہ جو دونوں میں سے کسی راستے کا ذکر نہیں کرتا۔ اگر مہمان کنٹینرز یا مقامی ہائپر وائزر بھی ہوسٹ کرتا ہے تو دیکھیں کہ وہ پہلے ہی اسی uplink میں برج نہیں کر رہے۔ ایک NIC پر دو برج ایک ڈیزائن ہے، تبدیلی ونڈو میں دریافت کرنے والا حادثہ نہیں۔
ping سے نہیں، پیکٹ راستے سے تصدیق کریں
صرف رسائی نہیں، اصل راستہ جانچیں۔ کلائنٹ سے تصدیق کریں کہ کون سا ماخذ پتہ دور کی سروس تک پہنچتا ہے، پھر تصدیق کریں کہ جواب اسی راستے واپس آتا ہے۔ مہمان پر مخصوص بہاؤ کے لیے فارورڈنگ کاؤنٹر دیکھیں، اور پورٹ گروپ پر تصدیق کریں کہ منتخب ڈیزائن کی ضرورت سے زیادہ کوئی مرئیت فعال نہیں کی گئی۔
آخر میں ناکامی کی سمت جانچیں۔ ٹنل روکیں یا کلائنٹ الگ کریں اور دیکھیں کہ ٹریفک خاموشی سے اس روٹڈ راستے پر نہیں گرتا جسے آپ نے غیر استعمال شدہ سمجھا تھا، کیونکہ وہی گرنا ہی برجڈ ڈیزائن کے خاموشی سے غیر ارادی راؤٹر بننے کا طریقہ ہے۔