آیا ماشین مجازی Hyper-V از VPN میزبان استفاده می‌کند؟ بستگی به سوئیچ دارد
VPN میزبان یک تنظیم برای کل ماشین نیست. نوع سوئیچ تعیین می‌کند که ترافیک مهمان پل شود، از مسیر میزبان عبور کند یا جدا شود، و همین پاسخ را تغییر می‌دهد.
یک کلاینت VPN روی میزبان Hyper-V نصب کنید، آنجا مرورگر باز کنید و نشانی خروج تغییر می‌کند؛ همان صفحه را داخل ماشین مجازی باز کنید و ممکن است نشانی قدیمی را نشان دهد یا هیچ چیز. نتیجه معمول این است که ماشین مجازی خراب است یا باید تونل‌زنی تفکیک‌شده را فعال کرد. هیچ‌کدام از این دو لازم نمی‌شود. کلاینت VPN ویژگی ماشین نیست؛ مجموعه‌ای از مسیرها، یک آداپتور مجازی و اغلب فیلتری متصل به رابط‌های مشخص است. اینکه ترافیک مهمان هرگز با این سازوکار روبه‌رو شود به سوئیچ مجازی‌ای بستگی دارد که مهمان استفاده می‌کند.
افسانه، ساده گفته شود
باور این است که VPN نصب‌شده روی میزبان کل ماشین را محافظت می‌کند، از جمله ماشین‌های مجازی را، چون ماشین مجازی فقط فرایندی است که روی همان ماشین اجرا می‌شود. باور راحت‌بخشی است، چون آنتی‌ویروس و دیوار آتش میزبان معمولاً همین‌طور عمل می‌کنند. مسیرهای شبکه این‌طور نیستند.
فریم مهمان تنها وقتی به پشته VPN میزبان می‌رسد که میزبان آن را مسیریابی یا فیلتر کند. این جمله را روی یک برچسب بنویسید، چون هر مورد زیر تغییری از آن است.
سه نوع سوئیچ، سه مسیر
یک سوئیچ خارجی آداپتور مجازی را به کارت شبکه فیزیکی متصل می‌کند و مهمان فریم‌ها را از طریق همان اتصال با نشانی MAC خود می‌فرستد. مهمان به همتایی در شبکه فیزیکی تبدیل می‌شود، با اجاره DHCP، دروازه و سرورهای DNS خودش. مسیر پیش‌فرض VPN میزبان در پشته میزبان می‌ماند و آن فریم‌ها را جابه‌جا نمی‌کند، چون پل می‌شوند و از مسیر میزبان عبور نمی‌کنند. به همین دلیل هم سوئیچ خارجی روی آداپتور Wi-Fi ایده بدی است: بیشتر درایورهای بی‌سیم فریم‌ها را برای نشانی MAC دوم حمل نمی‌کنند.
سوئیچ داخلی مهمان‌ها را به یک آداپتور مجازی میزبان وصل می‌کند. به‌تنهایی هیچ خروجی اینترنتی ندارد؛ یک شیء NAT روی میزبان ترجمه را فراهم می‌کند، همان‌طور که در راهنمای NAT در Hyper-V توضیح داده شده است. اکنون بسته‌های مهمان واقعاً وارد مسیریابی و مسیر NAT میزبان می‌شوند، پس مسیرها و فیلترهای کلاینت VPN دوباره اهمیت دارند. این همان چیدمانی است که ماشین مجازی واقعاً از VPN میزبان پیروی می‌کند و کلید قطع می‌تواند مهمان را کاملاً قطع کند.
سوئیچ خصوصی آداپتور میزبان و هیچ پیوند بالاسری ندارد. مهمان‌ها فقط با یکدیگر صحبت می‌کنند و با هیچ چیز دیگری، پس اگر ماشین مجازی روی سوئیچ خصوصی اینترنت نداشته باشد، روتر غایب علت است و VPN بی‌ربط است.
سوئیچ پیش‌فرض چیدمان جداگانه خودش را دارد
Windows یک سوئیچ پیش‌فرض ارائه می‌دهد که سوئیچ داخلی را با NAT و پروکسی DNS ترکیب می‌کند. زیرشبکه آن را میزبان انتخاب می‌کند، ممکن است پس از راه‌اندازی مجدد تغییر کند و همان شیء شبکه NAT که خودتان می‌سازید نیست. بازسازی آن به‌عنوان یک شبکه آزمایشگاهی همان روشی است که مردم را با دو NAT و مهمانی بدون مسیر روبه‌رو می‌کند.
اگر ماشین مجازی روی سوئیچ پیش‌فرض است، نشانی‌ای را که مهمان گرفته بخوانید و پیش از دست زدن به کلاینت VPN آن را با جدول NAT میزبان مقایسه کنید. ناسازگاری میان دروازه مهمان و پیشوند NAT بیشتر از هر تنظیم کلاینت خرابی را توضیح می‌دهد.
چهار واقعیت که پرسش را حل می‌کند
پیش از تغییر هر چیز این‌ها را جمع کنید: نوع سوئیچ و پیوند بالاسری‌اش، آداپتور متصل به ماشین مجازی، نشانی، دروازه و DNS خود مهمان، و وضعیت NAT و مسیر پیش‌فرض میزبان. فرمان‌های فقط‌خواندنی عبارت‌اند از Get-VMSwitch، Get-VMNetworkAdapter -VMName "TestVM"، Get-NetNat، و Get-NetRoute -DestinationPrefix 0.0.0.0/0؛ و داخل مهمان ipconfig /all بقیه را می‌دهد.
سپس تصمیم بگیرید مهمان چه کاری باید انجام دهد. اگر باید بیرون از VPN بماند، استثنای پشتیبانی‌شده ارائه‌دهنده را برای همان مسیر دقیق بگیرید، چون مستثنا کردن یک فایل اجرایی میزبان ترافیک ارسال‌شده ماشین مجازی را مستثنا نمی‌کند. اگر باید از VPN استفاده کند، رفتار مستند کلاینت با ترافیک ماشین‌های مجازی را تأیید کنید، نه اینکه فرض کنید آزمون در مرورگر میزبان آن را پوشش می‌دهد.
آزمون داخل مهمان تنها شواهدی است که به حساب می‌آید. نشانی خروج را از مهمان بررسی کنید، یک نام داخلی را حل کنید، VPN را دوباره وصل کنید و تکرار کنید. نتیجه مرورگر میزبان جای هیچ‌یک از این‌ها را نمی‌گیرد.
افسانه چه هزینه‌ای دارد
مردم کلید قطع را خاموش می‌کنند، مسیرهای ایستا اضافه می‌کنند یا سوئیچ‌ها را پاک و دوباره می‌سازند فقط برای اینکه یک آزمون قبول شود. هر میان‌بر حالت خرابی را تغییر می‌دهد: ممکن است مهمان از مسیری به اینترنت برسد که هیچ‌کس قصدش را نداشت، یا میزبان وقتی سوئیچ خارجی کارت فیزیکی‌اش را دوباره متصل می‌کند اتصال را از دست بدهد.
اتصال دوباره یک سوئیچ خارجی دسترسی خود میزبان را قطع می‌کند، پس یک مسیر خارج از باند باز نگه دارید و از پاک کردن سوئیچ‌ها در حالی که هنوز عیب‌یابی می‌کنید بپرهیزید. نتیجه درست مسیر موردنظر مهمان است، از جمله اینکه چگونه دوباره وصل می‌شود و چگونه شکست می‌خورد، نه یک تیک سبز از یک بار بارگذاری صفحه.
پاسخ پایدار یک خط برای هر ماشین مجازی در فهرست است: از کدام سوئیچ استفاده می‌کند و کدام جزء دروازه‌اش را تأمین می‌کند. وقتی این نوشته شد، تغییر بعدی VPN یک جست‌وجو است نه یک بعدازظهر حدس زدن.