مهمان Hyper-V وقتی VPN میزبان وصل می‌شود DNS را از دست می‌دهد

مهمان امروز صبح خوب بود. سپس میزبان Cisco AnyConnect را بالا آورد و ماشین مجازی DNS، اعتماد دامنه و پوشه اشتراکی را از دست داد، بدون اینکه چیزی داخل آن تغییر کرده باشد. تونل میزبان و شبکه مهمان دو مسیر جداگانه‌اند و وصل کردن یکی دیگری را جابه‌جا نمی‌کند. از داخل مهمان به بیرون کار کنید و پیش از تغییر هر چیزی آنچه می‌بینید را بنویسید.

آنچه مهمان هنوز می‌تواند ببیند

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

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

مهمان از کدام خروجی استفاده می‌کند

Hyper-V با دو فرمان به این پاسخ می‌دهد: Get-VMSwitch سوئیچ‌ها را فهرست می‌کند، و Get-VMNetworkAdapter -VMName TestVM سوئیچی را نشان می‌دهد که مهمان به آن متصل است. Default Switch شبکه NAT است که Windows آن را مدیریت می‌کند؛ سوئیچ خارجی ترافیک را به آداپتور فیزیکی می‌سپارد؛ سوئیچ داخلی تا زمانی که کسی NAT یا مسیریاب اضافه نکند چیزی حمل نمی‌کند. VirtualBox همان سه ایده را به صورت NAT، NAT Network و bridged ارائه می‌دهد.

حالت تعیین می‌کند که آیا تونل میزبان اصلاً می‌تواند مهم باشد. مهمان NAT توسط WinNAT ترجمه و سپس توسط پشته میزبان هدایت می‌شود، بنابراین از جدول مسیر میزبان پیروی می‌کند؛ با کلاینت تونل کامل، ترافیک آن همان ترافیکی است که وارد آداپتور VPN می‌شود و وقتی کلاینت زیرشبکه محلی را مسدود کند حذف می‌شود. مهمان پل‌شده روی سوئیچ خارجی هرگز به مسیریابی میزبان نمی‌رسد: فریم‌هایش مستقیماً از NIC فیزیکی خارج می‌شوند، پس هم تونل و هم سیاست شبکه محلی کلاینت را دور می‌زند.

اشتراک‌گذاری تونل میزبان با Hyper-V

اگر مهمان به تونل نیاز دارد و نمی‌تواند کلاینت خودش را اجرا کند، Windows می‌تواند اتصال VPN را به اشتراک بگذارد. ویژگی‌های آداپتور VPN را باز کنید، به بخش اشتراک‌گذاری بروید و به دیگر کاربران شبکه اجازه دهید از طریق آن متصل شوند. اتصال شبکه خانگی را به آداپتور Hyper-V اشاره دهید، vEthernet (Default Switch)، سپس یک درخواست تازه از داخل مهمان آزمایش کنید.

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

نصب دوباره قابلیت Hyper-V چند مهمان سرسخت را نجات داده است. آن را برای آخر بگذارید و ابتدا وضعیت مهمان را یادداشت کنید.

هدایت پورت وقتی زیرشبکه فیلتر می‌شود

VPN میزبانی که زیرشبکه NAT مهمان را فیلتر می‌کند دسترسی مستقیم را می‌شکند، نه حل نام را. ماشین مجازی در حال اجراست، اما ssh [email protected] معلق می‌ماند، در حالی که ترجمه هایپروایزر هنوز کار می‌کند. پورت‌هایی را که کار نیاز دارد هدایت کنید و به جای آن به نشانی میزبان وصل شوید. خطوط Vagrantfile زیر SSH و یک سرویس HTTPS را پوشش می‌دهند؛ هر دو پیش از بارگذاری دوباره وارد می‌شوند.

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

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

بررسی‌ای که می‌گوید کار کرد

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

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

هر تغییر سوئیچ یا درایور را همراه با گام بازگردانی آن ثبت کنید. راهنمای Microsoft درباره Hyper-V NAT توضیح می‌دهد Default Switch واقعاً چیست و ارزش خواندن دارد پیش از آنکه شبکه NAT دومی بسازید که با آن تعارض داشته باشد.