نام‌های داخلی کوتاه در VPN شکست می‌خورند: پسوندی که هرگز نمی‌بینید
نام کوتاه تنها به این دلیل کار می‌کند که یک پسوند جستجو آن را کامل می‌کند. نام کامل و کوتاه را مقایسه کنید تا کمبود پسوند را از خرابی resolver جدا کنید.
نام کوتاه در دفتر کار می‌کرد و در VPN شکست می‌خورد، در حالی که نام کامل بدون مشکل حل می‌شود. هیچ چیز خراب نیست. یک نام خالی مثل intranet نام کامل نیست؛ کلاینت پسوندی از فهرست جستجوی خود اضافه می‌کند و نتیجه را می‌پرسد. اگر پروفایل VPN آن پسوند را فراهم نکند، شکل کوتاه آشنا دیگر وجود ندارد.
این تمام افسانه است. DNS خراب نشد، سیاست جستجو تغییر کرد.
نام خالی نام نیست
وقتی یک برچسب واحد تایپ می‌کنید، resolver باید تصمیم بگیرد چه چیزی را بپرسد. نام را همان‌طور که هست امتحان می‌کند، سپس ورودی‌های فهرست جستجو را یکی‌یکی اضافه می‌کند تا چیزی پاسخ دهد. در Linux، فایل resolv.conf این ترتیب را با تنظیمات search و ndots کنترل می‌کند. در Windows، فهرست پسوندها و سیاست حل نام همین کار را می‌کنند. پسوند را بردارید و resolver چیزی برای اضافه کردن ندارد.
بنابراین یک نام کوتاه کارآمد شاهد یک سیاست است، نه شاهد یک سرور DNS سالم.
فهرست پسوندها و آدرس resolver هر کدام چه می‌کنند
این دو مدام با هم اشتباه گرفته می‌شوند. آدرس resolver می‌گوید از چه کسی بپرسیم؛ فهرست پسوندها می‌گوید درباره کدام نام بپرسیم. VPN می‌تواند resolver خصوصی بدون پسوند به شما بدهد، یا پسوندی با resolver اشتباه. تنها یکی از این شکست‌ها شبیه قطعی DNS است.
آن‌ها را جداگانه بررسی کنید، چون درست کردن مورد اشتباه یک پنجره پشتیبانی را می‌سوزاند.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
سه نشانه، سه مسئول متفاوت.
ابتدا نام کامل را آزمایش کنید
نام کاملاً واجد شرایط مستندشده توسط مدیر را بخواهید، نه یک حدس. یک FQDN کارآمد ثابت می‌کند که resolver در دسترس است و رکورد وجود دارد، که با یک پرس‌وجو نیمی از علل ممکن را حذف می‌کند. از ابزاری استفاده کنید که نشان دهد کدام سرور پاسخ داده است، تا نتیجه ذخیره‌شده در حافظه نهان را نخوانید.
آزمایش را خصوصی نگه دارید. فرستادن گونه‌های داخلی به یک resolver عمومی نام‌ها را افشا می‌کند و سیاستی را می‌آزماید که هیچ‌کس قصدش را نداشت.
اصلاح کجا تعلق دارد
پروفایل مالک یا سیستم مدیریتی که آن را تولید می‌کند اصلاح کنید. ویرایش دستی پیکربندی resolver محلی معمولاً هنگام اتصال مجدد ناپدید می‌شود، یا برای هر شبکه‌ای که دستگاه به آن می‌پیوندد اعمال می‌شود، که بدتر است.
در Windows، سیاست مؤثر را بررسی کنید نه چک‌باکسی که به یاد دارید. Get-DnsClientNrptPolicy قواعد حل نام را که واقعاً در نیرو هستند نشان می‌دهد.
در macOS، scutil --dns پیکربندی resolver را برای هر رابط دامنه‌دار چاپ می‌کند، از جمله دامنه‌های جستجویی که VPN هل داده است.
در Linux، خط search را در /etc/resolv.conf بخوانید، اما بررسی کنید که آیا کلاینت VPN آن را بازنویسی کرده است. اگر فایل مدیریت می‌شود، منبع حقیقت را ویرایش کنید نه فایل رندرشده. یک خط search کهنه باقی‌مانده از شبکه قبلی علت شایعی است.
چه چیزی را همراه پروفایل نگه دارید
نام کامل اصلاح‌شده، فهرست پسوندها و آدرس resolver را کنار پروفایل کلاینت نگه دارید. نفر بعدی که گزارش می‌دهد سایت intranet پایین است می‌تواند سه مقدار معلوم را مقایسه کند به جای شروع از صفحه خالی.
و اگر فقط شکل کوتاه شکست می‌خورد، آن را در تیکت بنویسید. آن جمله یک بعدازظهر را برای تیم resolver ذخیره می‌کند.