اشتراک‌گذاری نشست VPN میزبان با یک مهمان VMware

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

دو دلیل که پل نمی‌تواند کار کند

آداپتور کلاینت معمولاً یک نشانی حمل می‌کند، اغلب یک /32، و کلاینت مسیرهای میزبان را بازنویسی می‌کند تا ترافیک خروجی معمولی تونل را ترجیح دهد. برنامه‌های روی میزبان از آن جدول فرمان می‌برند و به سامانه خصوصی می‌رسند. مهمان پل‌شده اصلاً جدول را نمی‌خواند، چون قاب‌هایش از سوئیچی زیر لایه IP خارج می‌شوند.

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

بخشی بسازید که میزبان مالک آن است

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

پیش از ساختن چیزی روی آن تأیید کنید که Windows رابط را می‌بیند، چون تمام طرح به معمولی بودن آن آداپتور بستگی دارد:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

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

پیشوند مهمان را ترجمه کنید

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

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

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

نخستین گام را بررسی کنید، سپس هزینه را

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

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

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

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