VPN شما سه سرور DNS را می‌فرستد: کدام یک پاسخ می‌دهد؟
ورودی‌های اضافی می‌توانند یک جایگزین، یک مسیر به ازای هر دامنه یا بازمانده‌ای از پیوند فیزیکی باشند. پیش از آنکه فهرست را نشتی بنامید، هر یک را به یک دامنهٔ اعمال نسبت دهید.
پس از اتصال صفحهٔ تنظیمات را باز کنید و سه نشانی DNS فهرست می‌شود؛ پرسش حسابرسی این است که کدام یک آخرین پرس‌وجوی شما را رسیدگی کرده است. شمارش تنها به هیچ چیز پاسخ نمی‌دهد، زیرا هُل دادن کارخواه، یک واسط فیزیکی و یک سیاست به ازای هر دامنه همه در یک نما می‌نویسند. این ورودی‌ها دامنه‌های اعمال متفاوتی دارند و دامنهٔ اعمال، نه جایگاه، تعیین می‌کند چه کسی پاسخ می‌دهد. با جدا کردن منابع آغاز کنید، سپس آن منبعی را بیازمایید که نام مورد نظر شما را در اختیار دارد.
چرا فهرست از نمایهٔ شما بلندتر است
کارخواه VPN نشانی‌های حل‌کننده را برای پیوند تونل هُل می‌دهد و سیستم‌عامل آن‌ها را در کنار آنچه واسط فیزیکی از پیش داشته نگاه می‌دارد. یک روتر، یک اجارهٔ DHCP شرکتی، یک VPN دوم و یک سیاست به ازای هر دامنه هر یک ورودی خود را می‌افزایند. بنابراین سه نشانی در صفحه می‌تواند به معنای سه دامنهٔ اعمال باشد، نه سه نامزد برای یک کار. خواندن شمارش به‌عنوان مدرک نشتی نخستین خطای این حسابرسی است.
درون یک واسط، کارخواه واقعاً سرورهای خود را به ترتیب می‌آزماید، پس فهرست مرتب بی‌معنا نیست. آنچه صف نیست نمای ادغام‌شده است، جایی که ورودی‌های نمایه، پیوند فیزیکی و قواعد هر دامنه بدون یک رتبه‌بندی کنار هم می‌نشینند. همین تمایز تعیین می‌کند چه چیزی را بیازمایید: ترتیب رفتار درون یک دامنهٔ اعمال را توضیح می‌دهد و دامنهٔ اعمال همه چیز دیگر را.
DNS رمزگذاری‌شده تصویر را از درون یک برنامه می‌شکند. مرورگر یا کارخواه گفتگویی که حل‌کنندهٔ DNS-over-HTTPS خود را دارد، پرس‌وجوها را کاملاً از کنار فهرست سیستم‌عامل می‌فرستد، پس نشانی‌های صفحهٔ تنظیمات ترافیکی را توصیف می‌کنند که برنامه هرگز تولید نکرده است. پیش از سرزنش نمایه برای نامی که اشتباه درآمده، تنظیم حل‌کنندهٔ خود برنامه را بررسی کنید.
هر یک از سه بررسی چه می‌گوید
هر منبع رد خود را در جای متفاوتی می‌گذارد و هیچ فرمان واحدی همه را نشان نمی‌دهد. این نگاشت ارزش نگه داشتن در کنار صفحهٔ تنظیمات را دارد:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
در سامانه‌ای که از systemd-resolved استفاده می‌کند، resolvectl status مرجع است، زیرا DNS را به ازای هر پیوند همراه با دامنه‌های مسیریابی گزارش می‌کند. macOS از طریق scutil --dns پاسخ می‌دهد که حل‌کننده‌های دامنه‌دار را به ترتیب آزمون فهرست می‌کند. ویندوز دو نیمه را جدا می‌کند: Get-DnsClientServerAddress برای سرورهای هر واسط و Get-DnsClientNrptPolicy برای قواعد پسوند. فرمانی را اجرا کنید که به حل‌کنندهٔ واقعاً در حال استفاده تعلق دارد، زیرا رایانه‌ای با زمان‌اجرای کانتینر و حل‌کنندهٔ رومیزی می‌تواند بیش از یکی نصب داشته باشد.
حل‌کنندهٔ جایگزینی که نمی‌تواند به ناحیهٔ شما پاسخ دهد
ورودی دوم معمولاً برای دسترس‌پذیری وجود دارد و دسترس‌پذیری تنها وقتی کار می‌کند که جایگزین نام‌ها را بداند. از یک حل‌کنندهٔ عمومی نام میزبان داخلی بپرسید؛ NXDOMAIN برمی‌گرداند، یا پاسخی عام از دامنهٔ جستجویی که هیچ ربطی به شما ندارد. آنگاه یک جایگزین که کسی بررسی نکرده است، درست در لحظه‌ای که به آن نیاز است قطعی ایجاد می‌کند.
Split DNS برای جلوگیری از همین وجود دارد: پسوندهای شرکت به حل‌کننده‌ای می‌روند که ناحیه را در اختیار دارد و نام‌های عمومی در مسیر پیش‌فرض می‌مانند. طراحی درست است و به کامل بودن فهرست پسوندها وابسته است. مایکروسافت سیاست حل‌کننده به ازای هر پسوند را مستند کرده که این را در ویندوز می‌گرداند، و همان ایده به شکل دامنه‌های مسیریابی در systemd-resolved و حل‌کننده‌های دامنه‌دار در macOS ظاهر می‌شود.
ناحیه‌هایی را که جایگزین مجاز است پاسخ دهد با پسوندهای موجود در سیاست مقایسه کنید. این مقایسه شکاف را پیش از آن می‌یابد که کاربری گزارش دهد یک سایت داخلی پس از تغییر تونل از حل شدن بازمانده است.
از طریق سیاست بپرسید، نه دور از آن
از طریق حل‌کنندهٔ سیستم‌عامل بپرسید، زیرا پرس‌وجوی مستقیم از یک سرور سیاست را دور می‌زند و تنها آنچه را آن سرور می‌گفت گزارش می‌کند. شکاف میان دو پاسخ تمام ماجراست:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53اگر پرس‌وجوی سامانه نشانی خصوصی برگرداند در حالی که پرس‌وجوی مستقیم NXDOMAIN می‌دهد، سیاست کار می‌کند و جایگزین نقطهٔ ضعف است. اگر هر دو همان پاسخ عمومی را برگردانند، نام بیرون از دامنهٔ اعمالی که در نظر داشتید حل می‌شود و فهرست پسوندها جای نگاه کردن است. هر دو خروجی را نگه دارید، زیرا بحث دربارهٔ حل‌کننده با دو خط سریع‌تر از یک تصویر صفحهٔ تنظیمات فیصله می‌یابد.
سپس مسیر شکست را تمرین کنید، زیرا جایگزینی که کسی نیازموده است یک فرض است. حل‌کنندهٔ ترجیحی را برای یک پرس‌وجو به سیاه‌چاله تبدیل کنید و ببینید کدام نشانی برمی‌گردد:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32همان مسیر را به‌محض پایان پرس‌وجو حذف کنید، وگرنه نفر بعدی معمایی را به ارث می‌برد. اگر نام‌های داخلی در آن بازه هنوز حل می‌شوند، چیزی بیرون از دامنهٔ اعمال در نظر گرفته‌شده به آن‌ها پاسخ داده است. اگر در عوض به پایان مهلت برسند، جایگزین وجود ندارد یا به‌درستی محدود شده است، و گزارش خود حل‌کننده می‌گوید کدام یک از این دو بود.
تصمیم بگیرید: نگه دارید، محدود کنید یا حذف کنید
حل‌کنندهٔ دومی را نگه دارید هنگامی که به فضای نام مورد نیاز شما پاسخ می‌دهد و زیر نمایه در دسترس می‌ماند. آن را محدود کنید هنگامی که باید تنها یک پسوند را ببیند و هیچ چیز دیگر، و حذفش کنید هنگامی که نه دامنهٔ اعمالی دارد و نه هدفی مستند. ورودی بدون کار یک نشتی آیندهٔ بی‌فایده است و پیش‌فرض فروشنده هدف نیست.
نتیجه را در چهار ستون ثبت کنید: پسوند، حل‌کننده، واسط و مالک. آن خط به پرسش حسابرسی بعدی سریع‌تر از هر تصویری پاسخ می‌دهد و از به‌روزرسانی کارخواهی که فهرست را بی‌صدا بازآرایی می‌کند جان سالم به در می‌برد.