چرا VPN مهمان شما پشت NAT VirtualBox شکست می‌خورد؟

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

پیش از سرزنش شبکه، فرایند VPN را پیدا کنید

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

حالا حالت آداپتور مهمان را بنویسید، پیش از آنکه چیزی را تغییر دهید. همان یک مقدار بیشتر آنچه در ادامه می‌آید را توضیح می‌دهد، و اولین چیزی است که بعداً کسی از شما می‌پرسد.

تبادل بیرونی سازگاری را تعیین می‌کند

راهنمای شبکه VirtualBox محدودیت‌های NAT را فهرست می‌کند که اینجا مهم‌اند: پروتکل‌هایی غیر از TCP و UDP را عبور نمی‌دهد، GRE به‌عنوان پشتیبانی‌نشده نام برده شده، و PPTP به‌عنوان مثال آسیب‌دیده آمده است. PPTP از تبادل کنترل TCP و GRE برای داده استفاده می‌کند، پس اتصال کنترل می‌تواند موفق شود در حالی که مسیر داده نمی‌تواند از همان مرز عبور کند. این‌ها دو شاهد متفاوت هستند و فقط یکی از آن‌ها درباره حمل ترافیک است. اجازه دادن به پورت TCP 47 در یک قاعده فایروال همان اجازه دادن به پروتکل IP 47 نیست، و این دو مدام با هم اشتباه می‌شوند.

محدودیت را به این آرایش NAT بچسبانید، نه به هر دستگاهی که کلمه NAT را به کار می‌برد. یک روتر فیزیکی می‌تواند GRE را بی‌شکایت عبور دهد در حالی که NAT مجازی آن را می‌اندازد، و هایپروایزر دیگر درباره آنچه ارسال می‌کند انتخاب خودش را دارد. جایی که سازمان حمل‌ونقل تأییدشده‌ای در TCP یا UDP ارائه می‌دهد، از کلاینت و پروفایل پشتیبانی‌شده‌اش برای آن مسیر استفاده کنید. سازگاری یکی از چندین الزام است و نه اعتماد سرور را ثابت می‌کند و نه اجازه حساب و نه مسیرهای خصوصی کارآمد.

پل‌سازی در واقع چه چیزی را تغییر می‌دهد

یک پل آدرس MAC مهمان را به سگمنت فیزیکی می‌دهد به‌جای پنهان کردنش پشت ترجمه. سپس مهمان آدرسی از هر سرور DHCP که به آن سگمنت خدمت می‌کند می‌گیرد، برای آن آدرس به ARP پاسخ می‌دهد، و برای سوئیچ بالادست به‌عنوان یک پورت دیگر ظاهر می‌شود. این مسیر ترجمه مجازی را حذف می‌کند، که دقیقاً دلیل توصیه یک دستور قدیمی است، و همزمان سه چیز دیگر را تغییر می‌دهد. آدرس‌دهی اکنون از سگمنت محلی می‌آید نه از هایپروایزر، قرار گرفتن در معرض یعنی مهمان برای آن سگمنت قابل مشاهده است، و پذیرش به پورت سوئیچ و سیاستش بستگی دارد. هر یک از این‌ها می‌تواند دلیلی برای رد تغییر باشد، و هیچ‌کدام درباره پروتکل VPN نیست.

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

دو تونل، دو رد شواهد

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

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

کدام شرط واقعاً شما را مسدود می‌کند

اکنون تصمیم به سه پرسش با پاسخ‌های متفاوت محدود می‌شود. اگر پروتکل بیرونی خارج از TCP و UDP باشد، حالت NAT محدودیت است، و پل یا حمل تأییدشده TCP/UDP راه پیش است. اگر تبادل بیرونی کامل شود و مسیر داده نه، محدودیت همانی است که در شاهد دوم دیده شد. اگر تونل بالا بیاید و منابع پاسخ ندهند، مشکل از هایپروایزر گذشته و به مسیریابی یا سیاست رسیده است.

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