Короче говоря, проблема в том, что некоторые доменные имена не разрешаются рабочими станциями в нашей сети, в то время как выполнение этого из сеанса удаленного рабочего стола на сервере завершается успешно.
Теперь подробности.
У нас есть доменная сеть Windows за маршрутизатором. Внутренние адреса находятся в диапазоне 192.168.1.x. Существует туннель к сайту клиента, где адреса находятся в диапазоне 10.x.x.x. Это исправно работает долгое время.
Клиент определяет несколько доменных имен, указывающих на серверы во внутренней сети. Они не являются общедоступными, поэтому для доступа к ним я добавил условные пересылки на нашем контроллере домена (192.168.1.1, Windows Server 2008 R2), но некоторые из них иногда разрешаются общедоступными серверами имен. Я не знаю конфигурации, но сетевой администратор клиента утверждает, что мы должны напрямую запрашивать их серверы имен, то есть условные серверы пересылки. Это работало без проблем долгое время.
Мне нужно было обновить контроллер домена до Windows Server 2016. Для этого я добавил дополнительный домен (192.168.1.7, Windows Server 2012 R2). AD, включая серверы условной пересылки, были реплицированы на этот новый сервер. На данный момент у нас не было проблем. Были рабочие станции с первичным DNS, установленным на первичный DC (192.168.1.1), и другие, где первичный DNS был установлен на вторичный DC (192.168.1.7). Домены клиента успешно разрешены на всех рабочих станциях.
Затем я установил Windows Server 2016 на главный сервер (192.168.1.1) и сделал его основным контроллером домена. AD реплицируется, и серверы условной пересылки установлены. Однако когда рабочая станция пытается разрешить домен клиента, она успешна, если DNS является вторичным DC (192.168.1.7), но терпит неудачу, если это первичный DC (192.168.1.1). Что интересно, запрос DNS разрешается на самом сервере (в сеансе удаленного рабочего стола к нему). В противном случае DNS выглядит нормально, потому что нет проблем с другими доменными именами (доступ в Интернет работает нормально в течение нескольких недель). Сетевая конфигурация клиентов следующая:
DNS на обоих контроллерах домена настроен одинаково (по крайней мере, я не нашел существенных отличий):
На данный момент я могу разрешить домен клиента на обоих серверах. Если я попытаюсь проверить связь с этим доменом на рабочей станции, это будет успешным, если это первичный DNS 192.168.1.7, но не удастся, если это 192.168.1.1.
Я могу пинговать интернет-домены на рабочей станции, независимо от ее основного DNS (192.168.1.1 и 192.168.1.7 работают правильно).
При использовании nslookup с сервером происходит сбой с «Тайм-аут DNS-запроса», если сервер 192.168.1.1, но успешный, если это 192.168.1.7 или сервер имен клиента (10.xxx), независимо от настройки DNS (192.168.1.1). 1.1 или 192.168.1.7). Я использовал DNSQuerySniffer Нира Софера на рабочей станции при проверке связи с клиентским доменом. Когда это DNS 192.168.1.1, я вижу 5 запросов - 4 без ответа, а 5-й возвращает «Server Failure», все с IP-адреса рабочей станции и с 192.168.1.1 в качестве адреса назначения. Когда DNS рабочей станции настроен на 192.168.1.7, я вижу только один успешный запрос. Однако при запуске на серверах на 192.168.1.1 я вижу DNS-запрос к моему маршрутизатору, тогда как он должен быть на сервере имен клиента, т.е. условные экспедиторы не работают и этот домен был разрешен публичным DNS (который может или не может разрешить его, но, чтобы следовать инструкциям клиента, я должен напрямую запросить их сервер имен). На 192.168.1.7 я вижу один запрос к IP-адресу их сервера имен (10.x.x.x), т.е. условно-экспедиторские работы.
Я чувствую себя очень глупо! Очевидно, я что-то упускаю. Как вы думаете, что мне следует проверить? В чем может быть причина, по которой условная переадресация не работает на этом контроллере домена? Буду очень признателен за любую помощь!
Заранее спасибо!
Оказывается, один виртуальный сетевой адаптер Hyper-V остался с включенным DHCP и получил шлюз по умолчанию, который является нашим резервным интернет-провайдером. У него нет туннеля, установленного на сайт клиента, поэтому вы не можете получить доступ к их серверам имен с помощью этого интернет-соединения, поэтому запрашивает резервные копии на общедоступных серверах имен, которые иногда разрешают запросы, а иногда нет (однако это проблема клиента). Я правильно настроил этот сетевой адаптер со статическим IP-адресом и удалил резервный шлюз. Теперь все DNS-запросы маршрутизируются через основной Интернет, в котором есть туннель к сайту клиента (и серверам имен), и все доменные имена успешно разрешаются.