DNS مهمان VirtualBox پس از اتصال میزبان به VPN خراب می‌شود

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

تأیید کنید کدام حالت آداپتور را اشکال‌زدایی می‌کنید

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

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

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

یک نام را از محلل مهمان دنبال کنید

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

داخل مهمان ببینید محلل واقعاً برای چه چیزی پیکربندی شده است. در مهمان Ubuntu با systemd-resolved، وضعیت هر پیوند سرورهایی را نشان می‌دهد که رسیده‌اند، و فایل resolv.conf ممکن است چیزی جز یک نشانی stub نداشته باشد، که درست است نه مشکوک. فایل دست‌کاری‌شده یا کلاینت جداگانه DNS رمزنگاری‌شده می‌تواند پرس‌وجوها را کاملاً جای دیگری بفرستد. پیش از تغییر، آنچه یافتید را بنویسید.

resolvectl status
resolvectl query app.internal.example

اینجا حل نام را از دسترس‌پذیری جدا کنید. نشانی‌ای که می‌رسد در حالی که سرویس دسترس‌ناپذیر می‌ماند، مسئله مسیریابی یا سیاست است نه DNS.

حالت محلل میزبان را روی همان آداپتور امتحان کنید

گزینه‌های NAT DNS در VirtualBox مکانیزم‌های متفاوتی را توصیف می‌کنند و تفاوت وقتی مهم می‌شود که محلل خود میزبان با تونل تغییر کند. پروکسی DNS درخواست‌های مهمان را به سرورهایی که به آن داده شده می‌فرستد. حالت محلل میزبان درخواست‌ها را رهگیری می‌کند و API DNS میزبان را صدا می‌زند، و این همان حالتی است که از محلل Windows بازپیکربندی‌شده توسط کلاینت VPN پیروی می‌کند.

مکانیزم اشتباه را فعال کنید و فرمان باز هم موفق می‌شود در حالی که رفتار تغییر نمی‌کند، که راه گیج‌کننده‌ای برای از دست دادن یک بعدازظهر است.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

تنظیمات فعلی ماشین مجازی را ثبت کنید، آن را خاموش کنید و آداپتوری را هدف بگیرید که قبلاً تأیید کردید. رقم آخر در گزینه شماره آداپتور است نه یک ثابت، پس اعمال آن روی ماشینی که آداپتور متأثرش دومی است یک عملیات بی‌اثر خاموش است. مهمان را راه‌اندازی کنید و پیکربندی محللی را که واقعاً دریافت کرده بررسی کنید، چون تنظیم دستی در مهمان بر هر چیزی که لایه NAT ارائه می‌دهد غلبه می‌کند. به یاد داشته باشید که حالت محلل میزبان همچنین فرض می‌کند مسیر DNS خود میزبان همان چیزی است که می‌خواستید به اشتراک بگذارید.

همان آزمون‌ها را در یک اتصال دوباره VPN تکرار کنید

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

کار کردن حل عمومی ثابت نمی‌کند که پرس‌وجوهای خصوصی روی مسیری مانده‌اند که سیاست شما می‌خواهد.

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