چگونه از طریق VPN در یک ماشین مجازی به سرویس خصوصی برسیم

مهمان و Mac را دو شبکه جدا بدانید که یک درِ باریک آن‌ها را به هم می‌رساند۔ ماشین مجازی کلاینت VPN و مسیر اینترنت خودش را نگه می‌دارد؛ Mac دقیقاً به یک سرویس از طریق آداپتور مخصوص میزبان و یک پورت هدایت‌شده می‌رسد۔ هیچ چیز دیگری نباید عبور کند۔ گام‌ها را به ترتیب دنبال کنید و وقتی یکی شکست خورد متوقف شوید، چون هر گام بعدی فرض می‌کند گام‌های قبلی دوام آورده‌اند۔

پیش از هر تغییری دو مسیر را ثبت کنید

روی مهمان، ipconfig /all آداپتوری را نشان می‌دهد که ترافیک VPN را حمل می‌کند و نشانی‌ای که از DHCP شبکه مجازی گرفته است۔ روی Mac، رابط مجازی‌ای را ثبت کنید که هایپروایزر برای آن بخش ساخته است؛ در VMware Fusion دستگاه مخصوص میزبان معمولاً vmnet1 است و Parallels نام خودش را می‌گذارد۔ توجه کنید چه کسی آن‌جا نشانی توزیع می‌کند، سپس همه را بنویسید، چون زیرشبکه مخصوص میزبان اغلب هنگام بازسازی شبکه مجازی دوباره تخصیص می‌یابد۔ حالت شبکه ماشین مجازی را در هایپروایزر بررسی کنید، نه در حافظه‌تان از آن۔ حالت اشتراکی یا NAT برای آداپتورِ رو به اینترنت به‌همراه حالت مخصوص میزبان برای آداپتورِ رو به Mac، همان چیدمانی است که این گام‌ها فرض می‌کنند۔

دو آداپتور، دو هدف۔ آمیختن آن‌ها طوری که یک آداپتور هم به Mac و هم به اینترنت خدمت کند، همان چیزی است که درِ باریک را به مسیری مسیریابی‌شده تبدیل می‌کند۔

ابتدا VPN خودِ مهمان را تأیید کنید

کلاینت را داخل Windows اجرا کنید و تأیید کنید که پایان می‌یابد، با هر آزمونی که فروشنده مستند کرده است۔ تا وقتی مهمان به‌تنهایی به سرویس خصوصی نمی‌رسد جلو نروید، چون مشکل هدایت پورت که روی تونلی خراب سوار شده دو علت دارد و پیام خطای سودمندی نمی‌دهد۔ نشانی خصوصی‌ای را ثبت کنید که سرویس از داخل مهمان به آن حل می‌شود۔ همان نشانی تنها چیزی است که قاعده هدایت پورت باید نام ببرد۔

اگر کلاینت تونل کامل را تحمیل کند، آداپتور مخصوص میزبان باز هم ترافیک محلی را حمل می‌کند، اما بررسی کنید که مقصد خصوصی به شکلی که نشانی‌اش را عوض کند توسط تونل گرفته نشود۔ یک نمایه تونل تقسیم‌شده این را ساده‌تر می‌کند و ارزش دارد از صاحب VPN درخواست شود۔

شاخه مخصوص میزبان را اضافه کنید و آن را تنها بیازمایید

یک آداپتور مخصوص میزبان به مهمان وصل کنید، نشانی ثابت روی زیرشبکه‌ای بدهید که چیز دیگری از آن استفاده نمی‌کند، و تأیید کنید که Mac می‌تواند آن را ping کند۔ با VPN متصل و قطع‌شده بیازمایید، چون نشانی باید هر دو را دوام بیاورد۔ مهمانی که فقط تا وقتی تونلش برپاست پاسخ می‌دهد مشکلی در مسیریابی دارد که هنوز پیدا نکرده‌اید۔

Windows ممکن است آداپتور جدید را شبکه عمومی طبقه‌بندی کند، که به‌طور پیش‌فرض ترافیک ورودی را مسدود می‌کند۔ نمایه را پیش از عیب‌یابی هر چیز دیگری تنظیم کنید۔

یک پورت را هدایت کنید، نه زیرشبکه را

یک پورت هدایت‌شده را به هدایت عمومی IP ترجیح دهید۔ Windows فرمان netsh interface portproxy را ارائه می‌دهد که پورت شنود را به میزبان و پورت مقصد هدایت می‌کند و نیاز دارد سرویس IP Helper در حال اجرا باشد۔

listenaddress را همیشه روی نشانی مخصوص میزبان تنظیم کنید۔ اگر آن را حذف کنید، همه رابط‌ها مقید می‌شوند و سرویس در معرض هر شبکه‌ای قرار می‌گیرد که ماشین مجازی روی آن باشد۔ یک قاعده دیوار آتش محدود به رابط مخصوص میزبان و همان یک پورت اضافه کنید تا شنونده و اجازه با هم بخوانند۔ ممکن است برنامه‌ای که پروکسی را می‌شناسد به‌جای آن پروکسی کوچکی داخل مهمان بخواهد که اتصال را پایان می‌دهد و به مسیر بازگشت به Mac نیازی ندارد۔ وقتی پروتکل اجازه می‌دهد پروکسی را انتخاب کنید، چون بنا به ساختارش بسته شکست می‌خورد۔

بررسی کنید، سپس طرح بازگشت را بنویسید

از Mac نام خصوصی را حل کنید، عملیات موردنظر را اجرا کنید، سپس VPN مهمان را متوقف کنید و تأیید کنید که عملیات شکست می‌خورد و به‌طور خاموش عقب نمی‌نشیند۔ همان بررسی آخر ثابت می‌کند که مسیر همانی است که ساخته‌اید۔ ثبت کنید دروازه چه هویتی را می‌بیند و چه کسی اجازه استفاده از هدایت را دارد۔

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