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

بررسی‌های زیر این مسیرها را از سیستم به بیرون دنبال می‌کنند. تا زمانی که ندانید کدام مسیر پاسخ داده و کدام شکست خورده، پروفایل VPN را ویرایش نکنید.

سه سیاست پاسخ را تعیین می‌کنند

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

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

چرا مرورگر پرسش دیگری می‌پرسد

nslookup پرسش خودش را به سروری که برمی‌گزیند می‌فرستد و نه از سیاست فضای نام و نه از تنظیم DNS رمزنگاری‌شدهٔ مرورگر پیروی نمی‌کند. به همین دلیل پرسش دستی به یک حل‌کنندهٔ عمومی پاسخ می‌گیرد در حالی که مرورگر گزارش می‌دهد سایت وجود ندارد. شما دو برنامه را مقایسه می‌کنید، نه دو حالت یک برنامه.

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

فهرست حل‌کننده‌ها و قواعد را بخوانید

در Windows پیش از نظریه‌پردازی آنچه سیستم نگه می‌دارد را چاپ کنید. Get-DnsClientServerAddress سرورهای هر رابط را نشان می‌دهد، Get-DnsClientNrptRule قواعد فضای نام را فهرست می‌کند، و Resolve-DnsName نام دقیق را از مسیر سیستم پاسخ می‌دهد. آن پاسخ را با پرسش مستقیم به سرور VPN بر اساس نشانی مقایسه کنید. وقتی Resolve-DnsName شکست می‌خورد و پرسش مستقیم موفق می‌شود، فهرست حل‌کننده‌ها یا یک قاعدهٔ فضای نام مشکوک است.

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

حل‌کنندهٔ هل‌داده‌شدهٔ دسترس‌ناپذیر

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

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

DNS رمزنگاری‌شده کل مسیر را دور می‌زند

مرورگرهای دارای DNS-over-HTTPS خودشان نام‌ها را از طریق اتصال HTTPS به فراهم‌کنندهٔ برگزیده حل می‌کنند. با روشن بودن آن، حل‌کنندهٔ سیستم و قواعد split DNS برای آن جستجوها کاملاً دور زده می‌شوند، بنابراین نام‌های داخلی در مرورگر شکست می‌خورند در حالی که سیستم عامل آن‌ها را درست حل می‌کند. عکس آن هم رخ می‌دهد: نام‌های داخلی در مرورگر از طریق فراهم‌کننده‌ای موفق می‌شوند که هرگز نباید آن‌ها را می‌دید، و این مشکل سیاست است نه اتصال.

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

تعمیرهایی که با شکست هم‌خوانی دارند

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

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

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

مقالات مرتبط