کار کردن DNS عمومی به معنای پیدا شدن Active Directory نیست

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

افسانه: نام‌ها حل می‌شوند، پس DNS تمام است

حل شدن یک سایت عمومی فقط می‌گوید که یک حل‌کننده به یک پرسش A یا AAAA برای نامی در ناحیه عمومی پاسخ داده است. Active Directory همان پروتکل را برای پرسشی دیگر به کار می‌برد: سرویس‌های دامنه کجا هستند و این کلاینت باید از کدام کنترلر استفاده کند. پرسش به صورت رکوردهای SRV زیر ناحیه‌ای به نام دامنه بیان می‌شود و یک حل‌کننده بازگشتی عمومی دلیلی برای نگه داشتن آن‌ها ندارد.

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

کلاینت دامنه واقعاً چه می‌پرسد، به ترتیب

برای دامنه‌ای مانند corp.example، پرسش عمومی مکان‌یاب _ldap._tcp.dc._msdcs.corp.example است. پاسخ‌های SRV کنترلرهای نامزد و درگاه‌هایشان را نام می‌برند و سپس کلاینت پیش از باز کردن اتصال به رکوردهای نشانی برای آن نام‌های میزبان نیاز دارد. کشف آگاه به سایت پرسش‌هایی زیر زیردامنه سایت می‌افزاید و پاسخ‌ها تعیین می‌کنند کدام کنترلرها ترجیح داده می‌شوند، نه کدام یک اجباری است.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

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

چرا یک حل‌کننده عمومی پاسخ می‌دهد و ورود همچنان می‌شکند

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

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

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

DNS تونل و مسیرهای آن را هم‌سو نگه دارید

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

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

با یک فراخوان کشف و یک عملیات زنده بپذیرید

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

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

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