تونل تفکیک‌شده مرورگر را کنار می‌گذارد، نه پرسش‌های DNS آن

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

مسیر داده و مسیر resolver از هم جدا می‌شوند

کنار گذاشتن بسته‌های یک برنامه را از تونل بیرون می‌آورد، که تصمیمی دربارهٔ مسیریابی و دیوار آتش روی مسیر داده است. تجزیهٔ نام جست‌وجوی دیگری است: یک فرایند از resolver سیستم می‌پرسد، و آن resolver تصمیم می‌گیرد کدام سرور پرسش را دریافت می‌کند.

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

بیابید کدام فرایند پرسش را مطرح می‌کند

مرورگر می‌تواند از resolver سیستم، سرویس DNS رمزنگاری‌شدهٔ خودش، یا resolverی استفاده کند که سیستم‌عامل برای هر شبکه تعیین می‌کند. اولی از سیاست پلتفرم پیروی می‌کند، دومی آن سیاست را کاملاً دور می‌زند، و سومی به این بستگی دارد که پرسش به کدام پیوند مسیریابی شود.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

پیش از آزمودن، پیکربندی مؤثر را بخوانید: کدام پیوندها سرورهای DNS را حمل می‌کنند، کدام فضاهای نام را ادعا می‌کنند، و آیا سیاستی برای هر نام پیش‌فرض را بازنویسی می‌کند. در لینوکس DNS تفکیک‌شده از دامنه‌های مسیریابی استفاده می‌کند؛ در ویندوز جدول سیاست تجزیهٔ نام همین کار را برای فضاهای نام انجام می‌دهد. هیچ‌کدام از صفحهٔ آزمون نشتی دیده نمی‌شود.

تصمیم بگیرید کدام resolver کدام نام را ببیند

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

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

هر فیلد DNS را بازنویسی نکنید تا یک برچسب آزمون سبز شود. برچسب یک پرسش از یک فرایند در یک لحظه را توصیف می‌کند.

پرسش و اتصال را جداگانه بررسی کنید

دو مسیر را مستقل بیازمایید. آزمون اتصال مسیر داده را نشان می‌دهد، و آزمون resolver نشان می‌دهد چه کسی نام را دریافت کرده.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

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

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