Чому ім’я сервера після додзвону розв’язується в його адресу VPN

Офісний файловий сервер усю ранок відповідає на своїй адресі LAN, потім віддалений користувач дзвонить, і ім’я починає розв’язуватися в адресу тунелю. У DNS нічого не правили вручну, і це підказка: запис опублікувала сама машина. Три умови визначають, чи виправите ви реєстратор, запис чи уявлення клієнта, і неправильний порядок означає, що запис повернеться після наступного з’єднання.

Дві адреси, одне ім’я, три умови

Сервер Windows з кількома інтерфейсами може мати адресу LAN, одну або кілька адрес додзвону і іноді другу мережеву карту. Кожен інтерфейс може реєструвати свої адреси в DNS, якщо для нього дозволена динамічна реєстрація. Коли адаптер PPP реєструється, те саме ім’я хоста отримує адресу, доступну лише партнеру тунелю, і клієнти LAN отримують її як дійсну відповідь.

Три умови визначають виправлення. По-перше, чи доступна додаткова адреса клієнтам, які її отримують? По-друге, чи залежить ще якийсь споживач від цієї реєстрації? По-третє, запис динамічний і тому може повернутися, чи статичний і тому навмисний?

Дайте відповідь на це, перш ніж щось чіпати. Якщо адреса недоступна з мережі, яка запитує, жодне очищення кешу клієнта не виправить це надовго. Якщо щось від неї залежить, наприклад шлях керування, який використовують самі партнери тунелю, видалення натомість зламає цей шлях. А динамічний запис, видалений без опрацювання його видавця, з’явиться знову під час наступної події реєстрації.

Прочитайте запис, перш ніж змінювати реєстратора

Запитайте точне повне доменне ім’я з мережі, яка повідомляє про проблему, і порівняйте відповіді з фактичними інтерфейсами та слухачами сервера. Одне ім’я, що повертає кілька адрес, — це нормально; питання в тому, чи кожна з них придатна для клієнта, який її отримує.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

Перший запит використовує локальний розв’язувач, другий запитує безпосередньо конкретний сервер DNS, а третій робить те саме з PowerShell у Windows. Їхнє порівняння відокремлює застарілий кеш клієнта від авторитетної відповіді. Якщо прямий запит уже повертає адресу тунелю, проблема в опублікованих даних, а не в локальному кешуванні.

Запишіть мітку часу запису і те, чи показує консоль DNS його як динамічний. Цей єдиний атрибут підказує, яка з трьох умов вище застосовується, і це різниця між п’ятихвилинним прибиранням і виправленням, що тримається.

Виправте видавця або запис, але знайте, що саме

Якщо запис динамічний і небажаний, тривале виправлення — заборонити цьому інтерфейсу реєструватися. Windows надає параметри реєстрації для кожного інтерфейсу, а клієнтська служба DNS публікує знову під час наступного з’єднання або зміни адреси. Вимкнення реєстрації для адаптера додзвону залишає реєстрацію адаптера LAN недоторканою, що зазвичай і потрібно.

Будьте обережні з перемикачами, що діють на всю машину. Глобальний параметр, який вимикає динамічне оновлення, впливає на кожен інтерфейс цього хоста, включно з тим, на чию реєстрацію покладаються інші клієнти. На контролері домену та сама обережність діє сильніше, бо хост може також володіти записами розташування служб, від яких клієнти залежать під час входу.

Якщо запис статичний, його розмістили там навмисно, і розмова йде з тим, хто його розмістив. Видалення статичного запису через те, що сьогодні він незручний, знищує єдиний доказ того, чому він існує. В обох випадках видаляйте застарілу відповідь лише після того, як видавця опрацьовано, і записуйте, що ви змінили, щоб наступна людина могла відрізнити навмисний запис від випадковості.

Перевірте з клієнтської мережі, яка не спрацювала

Перевірка належить мережі, яка повідомила про симптом, а не серверу. Очистіть кеш розв’язувача клієнта підтримуваним механізмом, потім повторіть початковий запит і початкове підключення до служби за ім’ям.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

Перша команда очищає кеш розв’язувача Windows, а друга показує, чи ім’я знову кешоване і яку адресу збережено. Успішне підключення сервера до самого себе нічого не доводить про клієнта LAN, а видалення маршруту до небажаної адреси не виправляє те, що публікує DNS.

Нарешті, повторіть подію, яка раніше вносила адресу: перепідключіть клієнт VPN або оновіть сеанс додзвону. Перевірте опубліковане ім’я ще раз після цієї зміни життєвого циклу. Виправлення, що тримається лише до наступного з’єднання, було прибиранням, а не виправленням, і знання того, яке з двох ви виконали, — це різниця між закриттям заявки та її повторним відкриттям наступного тижня.