Сервер пересылки Windows Server не работает на одном из контроллеров домена
В двух словах проблема состоит в том, что некоторые доменные имена не разрешаются рабочими станциями в нашей сети, в то время как выполнение этого из сеанса удаленного рабочего стола на сервере успешно.
Теперь подробности.
У нас есть доменная сеть Windows за маршрутизатором. Внутренние адреса из диапазона 192.168.1.x. Существует туннель, построенный для сайта клиента, где адреса находятся в диапазоне от 10.xxx. Это работает правильно в течение длительного времени.
Есть некоторые доменные имена, определенные заказчиком, указывающие на серверы в их внутренней сети. Они не являются общедоступными, поэтому для доступа к ним я добавил условные серверы пересылки на нашем контроллере домена (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 выглядит нормально, потому что нет проблем с другими доменными именами (доступ в интернет работает в течение нескольких недель). Конфигурация сети клиентов выглядит следующим образом:
- IP-адрес: 192.168.1.x
- Маска: 255.255.255.0
- GW: 192.168.1.10 (IP-адрес маршрутизатора)
- Основной DNS: 192.168.1.1 или 192.168.1.7 (основной и дополнительный DC)
- Вторичный DNS: пусто
DNS на обоих контроллерах домена настроен одинаково (по крайней мере я не смог найти каких-либо существенных различий):
- Слушайте на всех IP-адресах
- Пересылки такие же, в том же порядке, что и ниже - общедоступный DNS Google (8.8.8.8), IP-адрес основного маршрутизатора (192.168.1.10), маршрутизатор резервной линии (192.168.1.11)
- Одинаковые корневые ссылки на обоих серверах (по умолчанию)
- Те же параметры по умолчанию в диалоге свойств 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 или 192.168.1.7). Я использовал DNSQuerySniffer Nir Sofer на рабочей станции при пинге домена клиента. Когда это DNS 192.168.1.1, я вижу 5 запросов - 4 без ответа, а 5-й возвращает "Отказ сервера", все с IP-адреса рабочей станции и с 192.168.1.1 в качестве адреса назначения. Когда DNS рабочей станции установлен в 192.168.1.7, я вижу только один запрос, который успешно выполняется. Однако при запуске его на серверах в 192.168.1.1 я вижу запрос DNS к моему маршрутизатору, в то время как он должен быть к серверу имен клиента, то есть условные серверы пересылки не работают, и этот домен был разрешен общедоступным DNS (который может или может не решить, но, следуя инструкциям клиента, я должен запросить их сервер имен напрямую). На 192.168.1.7 я вижу один запрос к их IP серверу имен (10.xxx), т.е. работает условная переадресация.
Я чувствую себя чрезвычайно глупо! Очевидно, я что-то упустил. Как вы думаете, я должен проверить? Что может быть причиной условной переадресации, чтобы не работать на этом DC? Буду очень признателен за любую помощь!
Заранее спасибо!
1 ответ
Оказывается, один виртуальный сетевой адаптер Hyper-V остался с включенным DHCP, и он получил шлюз по умолчанию, который является нашим резервным интернет-провайдером. У него нет туннеля, установленного для сайта клиента, поэтому вы не можете получить доступ к его серверам имен с помощью этого интернет-соединения, таким образом, запрашивает резервные копии на общедоступных серверах имен, которые иногда разрешают запросы, а иногда нет (однако это проблема клиента). Я правильно настроил этот сетевой адаптер со статическим IP-адресом и удалил резервный шлюз. Теперь все DNS-запросы направляются через основной Интернет, который имеет туннель к сайту клиента (и серверам имен), и все доменные имена разрешаются успешно.