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

چه چیزی را تغییر دادید و در واقع چه چیزی تصمیم می‌گیرد

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

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

جدول چگونه نامی را مطابقت می‌دهد

قاعده‌ها بر پایه فضای نام کلید می‌خورند و دقیق‌ترین تطابق برنده است. قاعده‌ای برای corp.example بر vpn.corp.example اعمال می‌شود و بر example.net اعمال نمی‌شود. قاعده‌ای با فضای نام . هر چیزی را که دیگر قاعده‌ها پوشش نمی‌دهند پوشش می‌دهد، و همین آن را خطرناک‌ترین ورودی فهرست می‌کند و ورودی‌ای که ارزش بررسی دارد وقتی سایتی بی‌ربط از طریق تونل حل می‌شود.

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

جدول مؤثر را بخوانید، نه فهرست آرزوها

قاعده‌های تنظیم‌شده و قاعده‌های مؤثر دو پرسش جداگانه‌اند. Get-DnsClientNrptRule چیزهایی را که روی دستگاه وجود دارد فهرست می‌کند. Get-DnsClientNrptPolicy -Effective نشان می‌دهد سرویس‌گیرنده واقعاً چه چیزی را اعمال می‌کند، با مقادیری که از سیاست و تنظیمات محلی ادغام شده‌اند.

پسوند در آن خروجی را با نامی که آزمایش می‌کنید حرف به حرف مقایسه کنید. قاعده‌ای برای corp.example نامی را که به corp.example.com ختم می‌شود نمی‌گیرد، و وجود نقطه در پایان در یک جا و نبودنش در جای دیگر برای تغییر تطابق کافی است.

بدون قاعده، ویندوز از بیش از یک آداپتور می‌پرسد

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

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

مسیرهایی که حل‌کننده را کاملاً دور می‌زنند

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

همچنین بررسی کنید که برنامه به آدرسی از حافظه نهان نشست قبلی وصل می‌شود یا نه. Clear-DnsClientCache و سپس همان جست‌وجو پاسخ پاکیزه‌تری می‌دهد تا نتیجه‌گیری از یک نتیجه کهنه.

با همان نامی آزمایش کنید که شکست خورد

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

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

مقالات مرتبط