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

افسانه: دو نشانی دو دامنه را تقسیم می‌کنند

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

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

ویندوز واقعاً از چه چیزی برای انتخاب استفاده می‌کند

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

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

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

یک قاعده به ازای هر فضای نام، شیء را نگه دارید

پس از درک وضعیت مؤثر، به ازای هر فضای نام یک قاعده بسازید و شیئی را که هر فرمان برمی‌گرداند نگه دارید. نام‌های نمایشی برچسب‌هایی برای انسان‌اند و شناسه یکتا در شیء برگشتی، هدف حذف قابل‌اعتماد در ادامه است. هر دو شناسه را در همان یادداشت تغییری بنویسید که فضاهای نام و حل‌کننده‌ها را ثبت می‌کند، چون نشستی که آن‌ها را ساخته نشستی نخواهد بود که پاک‌سازی می‌کند.

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

نقطه آغازین نشانه تطبیق پسوند است، پس قاعده app.svc.internal.example و هر چیز دیگری در زیر آن را می‌پوشاند. دو نشانی اینجا به طرح مسیریابی خود این آزمایشگاه تعلق دارند؛ قاعده نه ناحیه‌ای می‌سازد، نه مسیری نصب می‌کند و نه به برنامه‌ای که در نهایت متصل می‌شود اجازه می‌دهد، و مرجع Add-DnsClientNrptRule دقیقاً مستند می‌کند که کدام پارامتر چه کاری می‌کند.

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

ثابت کنید کارخواه سرور را انتخاب کرده است

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

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

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

دقیقاً همان چیزی را بردارید که ساخته‌اید

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

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

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

مقالات مرتبط