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

روی میزبان Windows نام داخلی برنامه به‌محض اتصال VPN حل می‌شود، اما داخل مهمان Ubuntu این‌طور نیست. مهمان تنظیمات resolver خودش را نگه می‌دارد، و آداپتور NAT جلوی آن می‌تواند به پرس‌وجوهای DNS به دو روش متفاوت پاسخ دهد. هدایت مهمان به یک resolver عمومی باعث می‌شود سایت‌ها دوباره بارگذاری شوند، در حالی که نام‌های خصوصی خراب می‌مانند. به همین دلیل مسیر resolver پیش از هر تغییری ردیابی می‌شود.

یک جست‌وجو را از طریق آداپتور NAT ردیابی کنید

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

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

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

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

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

حالت proxy و حالت resolver میزبان دو مکانیزم متفاوت‌اند

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

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

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

آداپتور را عوض کنید، سپس بررسی کنید مهمان چه دریافت می‌کند

ابتدا تنظیمات شبکه و DNS ماشین مجازی را ثبت کنید، سپس ماشین را خاموش کنید تا پیکربندی پایدار همان چیزی باشد که ویرایش می‌کنید. برای ماشینی با نام work-ubuntu که آداپتور اولش NAT دارد، گزینه هر آداپتور از میزبان و در حالی که ماشین خاموش است تنظیم می‌شود. بعداً دوباره روشنش کنید و نتیجه را بررسی کنید، نه وضعیت خروج را.

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

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

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

در سراسر چرخه عمر VPN آزمایش کنید، نه فقط یک‌بار

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

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

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