مهمان پل‌شده VMware پس از OpenVPN شبکه‌اش را از دست داد

مهمانی که یک ساعت پیش پل‌شده و در دسترس بود اکنون در همه چیز به پایان زمان می‌خورد، و هیچ‌کس تنظیماتش را ویرایش نکرده است. روی میزبان، اینترنت هنوز از طریق تونل کار می‌کند. این دو واقعیت با هم از VPN دور و به سوی هایپروایزر اشاره می‌کنند، چون میزبان و مهمان دیگر از یک مسیر استفاده نمی‌کنند. یک آداپتور مجازی تازه کافی است تا این اتفاق بیفتد.

مهمان تغییر نکرد، پل تغییر کرد

نصب کلاینت OpenVPN در Windows یک آداپتور شبکه مجازی اضافه می‌کند که سرویس هنگام بالا آمدن تونل به آن متصل می‌شود. برای سیستم‌عامل مثل یک رابط معمولی با وضعیت پیوند و اغلب با نشانی‌های خودش به نظر می‌رسد. همین برای VMware کافی است تا آن را کاندید پل بداند.

VMnet0 به‌طور پیش‌فرض روی خودکار تنظیم شده است، یعنی هایپروایزر هر بار که پل می‌سازد یک آداپتور میزبان انتخاب می‌کند. آداپتور مجازی تازه‌نصب‌شده به این مجموعه می‌پیوندد، و اگر انتخاب شود، هر قابی که مهمان می‌فرستد به یک دستگاه تونل می‌رود نه به درگاه فیزیکی سوئیچ.

پل را تثبیت کنید یا مهمان را مسیریابی کنید

شاخه اول وقتی درست است که مهمان باید همتای برابر در LAN فیزیکی باشد: نگذارید پل انتخاب کند و آداپتور را صریح نام ببرید. شاخه دوم وقتی اعمال می‌شود که مهمان باید از تونل شرکتی استفاده کند، و در آن حالت پل هرگز طراحی درست نبود، چون مهمان پل‌شده مسیر VPN میزبان را به ارث نمی‌برد.

اول این را تصمیم بگیرید، چون دو پاسخ به کار متفاوتی می‌رسند. برعکس کردن ترتیب پلی به‌درستی تثبیت‌شده می‌سازد که به مهمانی وصل است که هرگز نباید پل می‌شد.

برای شاخه اول، ویرایشگر شبکه مجازی را روی میزبان باز کنید، VMnet0 را انتخاب کنید و خودکار را با آداپتور فیزیکی جایگزین کنید. اگر چند آداپتور هست، از فهرست تنظیمات خودکار استفاده کنید و تیک هر چیزی را که هرگز نباید ترافیک مهمان را حمل کند بردارید: دستگاه OpenVPN TAP یا Wintun، به‌علاوه آداپتورهای Hyper-V، WSL، Docker و loopback. روی لپ‌تاپ هم آداپتور فیزیکی سیمی و هم بی‌سیم را تیک‌خورده نگه دارید، وگرنه مهمان در دفعه بعد که کاربر آن را در داک قرار دهد پلش را از دست می‌دهد.

سه شرطی که انتخاب را قطعی می‌کند

اینکه پل اصلاً مناسب است به این بستگی دارد که مهمان برای چه کاری است. اگر مهمان باید به‌عنوان میزبان مستقل خود در LAN ظاهر شود، با نشانی خودش و دسترس‌پذیری ورودی خودش، پل مدل درست است و تثبیت تمام اصلاح است. اگر مهمان فقط به دسترسی خروجی نیاز دارد، شبکه فقط-میزبان یا NAT ساده‌تر و در برابر تغییر آداپتور مقاوم است.

اگر مهمان باید از همان تونل میزبان استفاده کند، نه حالت پل و نه آداپتور تثبیت‌شده کمکی نمی‌کند، چون ترافیک مهمان هرگز وارد تصمیم مسیریابی میزبان نمی‌شود. آن حالت به مسیری مسیریابی‌شده یا ترجمه‌شده روی میزبان نیاز دارد، و انتخاب آداپتور بی‌اهمیت می‌شود.

VMware Player هیچ ویرایشگر شبکه‌ای در رابط خود ندارد، پس میزبانی که فقط Player را اجرا می‌کند برای رسیدن به این تنظیمات به ویرایشگر مستقل یا نصب Workstation نیاز دارد. این محدودیت گاهی خودش رویکرد را تعیین می‌کند.

نتیجه را از داخل مهمان بخوانید

کارت شبکه مجازی را دوباره راه‌اندازی کنید، یا مهمان را دوباره راه‌اندازی کنید تا دوباره درخواست اجاره کند. سپس بخوانید که واقعاً چه گرفت، نه آنچه میزبان فکر می‌کند پیکربندی کرده است.

ipconfig /all
ip addr
ip route

دو فیلد را در آن خروجی بخوانید و بقیه را فعلاً نادیده بگیرید. دروازه باید روتر LAN باشد، و توضیح آداپتور باید دستگاه Ethernet شرکت VMware را نام ببرد نه تونل را. نشانی خودتخصیص‌یافته در 169.254.0.0/16 یعنی هیچ سرور DHCP پاسخ نداده است، و پل روی آداپتور تونل از سمت مهمان دقیقاً همین‌طور دیده می‌شود.

پیش از تغییر هر چیز دیگری، یک تمایز دیگر ارزش گفتن دارد. مهمانی که به روتر می‌رسد ولی به اینترنت نه، پل کارکننده و مشکلی در بالادست دارد. مهمانی که نشانی در محدوده تونل می‌گیرد هنوز به دستگاه اشتباه وصل است. غیرفعال کردن آداپتور TAP برای هیچ‌یک از این دو حالت راه‌حل نیست، چون سرویس OpenVPN به آن نیاز دارد.