Почему имя сервера после дозвона разрешается в его адрес 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 или обновите сеанс дозвона. Проверьте опубликованное имя ещё раз после этого изменения жизненного цикла. Исправление, которое держится только до следующего подключения, было уборкой, а не исправлением, и знание того, какое из двух вы выполнили, — это разница между закрытием заявки и её повторным открытием на следующей неделе.