Короткі внутрішні імена не працюють через VPN: суфікс, якого ви не бачите
Коротке ім'я працює лише тому, що пошуковий суфікс його доповнює. Порівняйте повне й коротке ім'я, щоб відрізнити відсутність суфікса від збою резолвера.
Коротке ім'я працювало в офісі й не працює через VPN, а повне ім'я розв'язується без проблем. Нічого не зламалося. Голе ім'я на кшталт intranet не є повним іменем; клієнт додає суфікс зі свого списку пошуку й запитує результат. Якщо профіль VPN не надає цей суфікс, звична коротка форма перестає існувати.
Ось і весь міф. DNS не зламався, змінилася політика пошуку.
Голе ім'я — не ім'я
Коли ви вводите одну мітку, резолвер має вирішити, що запитувати. Він пробує ім'я як є, а потім по одному додає записи зі списку пошуку, доки щось не відповість. У Linux порядок задає resolv.conf з параметрами search і ndots. У Windows те саме роблять список суфіксів і політика розв'язання імен. Приберіть суфікс — і резолверу не буде чого додати.
Тому робоче коротке ім'я — це доказ політики, а не справного DNS-сервера.
Що роблять список суфіксів і адреса резолвера
Ці дві речі постійно плутають. Адреса резолвера каже, кого питати; список суфіксів каже, про яке ім'я питати. VPN може дати приватний резолвер без суфікса або суфікс із неправильним резолвером. Лише один із цих збоїв виглядає як збій 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 доводить, що резолвер доступний і запис існує, а це одним запитом знімає половину можливих причин. Використовуйте інструмент, який показує, який сервер відповів, щоб не читати кешований результат.
Тримайте перевірку приватною. Надсилання внутрішніх варіантів публічному резолверу розкриває імена й перевіряє політику, якої ніхто не задумував.
Де місце виправленню
Виправте профіль-власник або систему керування, що його створює. Ручна правка локальної конфігурації резолвера зазвичай зникає під час перепідключення або застосовується до кожної мережі, до якої приєднується машина, що гірше.
У Windows перевіряйте чинну політику, а не прапорець, який ви пам'ятаєте. Get-DnsClientNrptPolicy показує правила розв'язання імен, які справді діють.
У macOS scutil --dns друкує конфігурацію резолвера для кожного інтерфейсу з областю, включно з доменами пошуку, які передав VPN.
У Linux прочитайте рядок search у /etc/resolv.conf, але перевірте, чи не переписав його клієнт VPN. Якщо файлом керують, редагуйте джерело істини, а не відрендерений файл. Застарілий рядок search, що залишився від попередньої мережі, — часта причина.
Що зберігати разом із профілем
Зберігайте виправлене повне ім'я, список суфіксів і адресу резолвера поруч із профілем клієнта. Наступна людина, яка повідомить, що сайт intranet не працює, зможе порівняти три відомі значення замість починати з порожньої сторінки.
А якщо не працює лише коротка форма, напишіть це в заявці. Це речення заощаджує команді резолверів цілу половину дня.