Три источника могут опубликовать VPN-адрес контроллера домена в DNS

Три разных компонента на контроллере домена с несколькими интерфейсами могут поместить один и тот же VPN-адрес в DNS, и отказывают они независимо друг от друга. Сравнивайте, что публикует каждый из них, вместо того чтобы доверять флажку адаптера, который управляет только одним из них. Симптом одинаков в любом случае: клиент разрешает имя, получает адрес туннеля и не может связаться с контроллером домена. То, кто опубликовал адрес, определяет, как это остановить.

Одна настройка, одна служба и одна роль; три источника, три переключателя.

Начните с записи, а не с флажка

Запросите полное имя пострадавшего сервера через DNS-сервер, которым клиенты действительно пользуются, и запишите каждый возвращённый адрес. Сопоставьте каждый возвращённый адрес с реальными интерфейсами ЛВС и туннеля сервера и с сетями, в которых находятся клиенты. Адрес может быть совершенно допустимым локально и при этом недоступным для важных клиентов. Периодические сбои проверки подлинности — частый симптом, потому что клиенты при разных попытках получают или выбирают разные адреса.

То, что машина правильно разрешает собственное имя, доказывает очень мало. Решающая проверка выполняется из сетей клиентов.

Адаптер — только один источник

В свойствах TCP/IP адаптера есть флажок для регистрации адреса этого подключения, и его снятие отключает ровно один источник. Остальные оно не останавливает, поэтому запись может появиться снова после перезагрузки. Если контроллер домена также выполняет службу DNS, у этой службы есть собственная конфигурация прослушивания и собственные записи сервера имён. Руководство Microsoft для сред с несколькими интерфейсами рассматривает поведение интерфейса, службу DNS и Netlogon как отдельные значимые источники.

Три переключателя, три владельца, и только один из них живёт на странице свойств адаптера.

У службы DNS есть собственные адреса

DNS-сервер, которому предписано слушать на VPN-адресе, продолжает публиковать его в собственных записях, что бы ни утверждал флажок адаптера. Согласуйте адреса прослушивания службы с предполагаемыми интерфейсами и одновременно просмотрите записи сервера имён зоны. Изменение прослушиваемых адресов может прервать работу клиентов, которые прямо сейчас используют удаляемый адрес, поэтому сначала установите, кто от какого зависит. Удаление прослушивания только потому, что это VPN-адрес, может отрезать клиентов, которым вы хотели помочь.

Netlogon и обнаружение контроллеров домена в целом тоже регистрируют адреса в рамках своих обязанностей. Не подавляйте регистрации во всём домене и не копируйте старое решение для регистрации удалённого доступа, не убедившись, что оно применимо к вашей версии и роли.

Сначала владелец, потом очистка

Исправьте источник до удаления записи, иначе следующее событие регистрации вернёт её, и упражнение повторится. Удаляйте устаревшие записи через процедуру владельца DNS и учитывайте кэширование и устаревание. Проверяйте из сетей клиентов, включая обнаружение домена и приложение, которое изначально отказало, а затем вызовите то же событие VPN, которое впервые создало адрес.

В итоге вам нужен известный набор опубликованных адресов и прослушиваний, при этом повседневная регистрация домена продолжает выполнять свою работу. Машина, имя которой случайно разрешается правильно сразу после ручной очистки, — это не он.

Запишите, какой источник был ответственен, какие записи изменились и какие клиенты проверялись. У следующего сервера с несколькими интерфейсами будут те же три подозреваемых.