VPN مهمان در ESXi: مسیریابی یا پل‌زدن — پیش از گروه پورت تصمیم بگیرید
یک TUN مسیریابی‌شده به مسیرهای بازگشت نیاز دارد؛ یک TAP پل‌شده به دسترسی لایه 2 و سیاست گسترده‌تر گروه پورت. پیش از گسترش حالت promiscuous نقش را مشخص کنید.
بسته‌ها را مسیریابی کنید یا دامنه Ethernet را گسترش دهید: تغییر گروه پورت پس از این انتخاب می‌آید. از دید برنامه‌ای که نشانی خصوصی دارد نتیجه‌ها می‌توانند یکسان به نظر برسند، در حالی که نیازهای هایپروایزر هیچ شباهتی ندارند. به همین دلیل نخست گروه پورت گسترش می‌یابد و پرسش طراحی دوم پاسخ می‌گیرد، معمولاً پس از یک طوفان broadcast. این بررسی‌ها را به ترتیب انجام دهید و تا زمانی که نیاز مبهم است توقف کنید، زیرا هیچ تنظیمی در گروه پورت طراحی‌ای را که هرگز انتخاب نشده اصلاح نمی‌کند.
تصمیم از آن مالک سرویس است؛ پیکربندی هایپروایزر باید آن را اجرا کند، نه اینکه ناخواسته آن را تعیین کند.
بررسی کنید طرف دور واقعاً چه نیاز دارد
سرویس‌هایی را که کلاینت‌های دور باید به آن‌ها برسند و پروتکل‌هایی را که به کار می‌برند فهرست کنید. اگر فهرست چند سرویس TCP روی پیشوندهای شناخته‌شده باشد، مسیریابی کافی است. اگر چیزی واقعاً به همسایگی لایه 2 نیاز داشته باشد — کشف وابسته به broadcast، پروتکل‌های غیر IP، دستگاهی که دروازه را نمی‌پذیرد — مسیریابی نمی‌تواند آن را تقلید کند و باید زود گفته شود. دربارهٔ ورودی‌های غیر IP آن فهرست صادق باشید، زیرا همان‌جاست که طراحی مسیریابی‌شده یک هفته بعد بی‌صدا شکست می‌خورد.
سپس مخزن کلاینت را بررسی کنید. طراحی مسیریابی‌شده به یک محدوده نشانی و مسیر بازگشت صریح در طرف دور نیاز دارد؛ طراحی پل‌شده به دامنه Ethernet گسترش‌یافته نیاز دارد که تخصیص نشانی و جداسازی را در اختیار داشته باشد. هر کدام را انتخاب کنید، کسی بیرون از این VM باید آن را بپذیرد.
هر طراحی چه چیزی از شبکه مجازی می‌خواهد
دو طراحی در آنچه شبکه مجازی باید تحمل کند تفاوت دارند و جدول کوتاه‌ترین راه دیدن آن است:
| طراحی | نقش سمت مهمان | آنچه شبکه مجازی باید بپذیرد | حالت شکست در صورت انتخاب نادرست |
|---|---|---|---|
| TUN مسیریابی‌شده | مسیریاب میان پیشوندهای جدا | مخزن کلاینت مسیریابی‌شده به‌همراه مسیرهای بازگشت در طرف دور | کلاینت‌ها به دروازه می‌رسند و هرگز به سرویس پشت آن نمی‌رسند |
| TAP پل‌شده | پل لایه 2 برای کلاینت‌هایی که می‌پیوندند | هویت‌های اضافی Ethernet، ترافیک broadcast و قواعد VLAN | vSwitch قاب‌ها را دور می‌ریزد، یا طراحی به حالت promiscuous نیاز دارد که کسی تأییدش نکرده است |
مسیریابی دامنه broadcast را همان‌جا نگه می‌دارد و جای طبیعی برای محدودکردن سرویس‌هایی می‌دهد که از دروازه می‌گذرند. پل‌زدن مرز را جابه‌جا می‌کند: کلاینت‌ها به شرکت‌کنندگان دامنه Ethernet گسترش‌یافته تبدیل می‌شوند و تخصیص نشانی، جداسازی و هر سیاست لایه 2 اکنون بر آن‌ها اعمال می‌شود. ردیف انتخاب‌شده را در سابقه تغییر بنویسید. جمله‌ای مانند «TUN مسیریابی‌شده، مخزن کلاینت 10.90.0.0/24، مسیر بازگشت روی هسته» مانع می‌شود مهندس بعدی طراحی را از تنظیمات گروه پورت دوباره به بحث بکشد.
چه کسی باید قاب‌های چه کسی را ببیند
پیش از دست‌زدن به گروه پورت یک پرسش از مالک پلتفرم بپرسید: آیا طراحی می‌خواهد این VM قاب‌هایی را دریافت کند که به شرکت‌کنندگان دیگر نشانه رفته‌اند؟ اگر پاسخ نه است، هیچ‌چیز در این بخش اعمال نمی‌شود، زیرا TUN مسیریابی‌شده هرگز به آن دید نیاز ندارد. اگر پاسخ بله است، راهنمای Broadcom دربارهٔ حالت promiscuous همان خواندنی است که اهمیت دارد: روشن می‌کند VM چه مقدار بیشتر از vSwitch را می‌بیند و توصیه می‌کند آن سیاست به یک گروه پورت محدود شود.
با آن مانند یک بررسی نیاز رفتار کنید، نه مجوز. وقتی نیاز به پل‌زدن نوشته شده است، تنظیم را برای یک اتصال اختصاصی روشن کنید و در همه‌جای دیگر خاموش بگذارید. یک trunk پهن VLAN که از نمونه پل دیگری کپی شده همان بخشی است که کسی به یاد نمی‌آورد حذف کند، و طراحی تک-VLAN باید تک-VLAN بماند.
ثبت کنید کدام گروه پورت تغییر کرد و چرا، در همان جایی که ردیف طراحی را نوشتید. همین جفت است که بازرسی بعدی را ممکن می‌کند.
اشیای مهمان را صریح نگه دارید
درون Linux، عضویت در پل و مالکیت نشانی دو شیء جدا هستند و درهم‌آمیختن آن‌ها آن وضعیت نیمه‌کارهٔ گیج‌کننده را می‌سازد. نشانی‌ها را به واسط پل یا به تونل مسیریابی‌شده بدهید، نه به دو سوی یک مسیر، و پورت‌های عضو را از پیکربندی IP خالی نگه دارید.
از گذاشتن یک زیرشبکه به‌طور مستقل روی یک TUN مسیریابی‌شده و روی یک واسط Ethernet نامرتبط بپرهیزید. آن پیکربندی دو مسیر به یک پیشوند پدید می‌آورد، پاسخ‌های نامتقارن و رشته‌ای در پشتیبانی دربارهٔ flapping که هیچ‌یک از دو مسیر را نام نمی‌برد. اگر مهمان میزبان کانتینرها یا هایپروایزر محلی هم باشد، بررسی کنید که از قبل به همان uplink پل نزده باشند. دو پل روی یک NIC یک طراحی است، نه حادثه‌ای که بخواهید در پنجره تغییر کشف کنید.
با مسیر بسته تأیید کنید، نه با ping
مسیر واقعی را بررسی کنید، نه فقط دسترسی را. از یک کلاینت تأیید کنید کدام نشانی مبدأ به سرویس دور می‌رسد و سپس پاسخ از همان راه بازمی‌گردد. روی مهمان شمارنده‌های ارسال برای جریان مشخص را بررسی کنید و روی گروه پورت تأیید کنید که دید بیشتری از آنچه طراحی انتخاب‌شده نیاز دارد فعال نشده است.
سرانجام جهت شکست را بیازمایید. تونل را متوقف کنید یا کلاینت را جدا کنید و بررسی کنید ترافیک بی‌صدا به مسیر مسیریابی‌شده‌ای که فکر می‌کردید بلااستفاده است برنگردد، زیرا همان بازگشت است که طراحی پل‌شده را بی‌صدا به مسیریاب ناخواسته تبدیل می‌کند.