Я отвечаю за группу виртуальных машин, которые используются членами группы, к которой я принадлежу, для доступа к веб-приложениям, веб-службам, серверам сборки и тому подобному. ИТ-служба отвечает за DNS-серверы, и у меня нет к ним доступа.
Все виртуальные машины являются частью одного и того же локального домена, и все они настроены на использование одного шлюза по умолчанию, маски подсети и серверов dns1 и dns2, каждый из которых имеет свой уникальный статический IP-адрес.
Как я снова и снова проверял на разных клиентских компьютерах, DNS-серверам никогда не удается разрешить имя хоста некоторых виртуальных машин (виртуальные машины Windows-сервера), но половину времени им не удается разрешить имя хоста определенного набора виртуальных машин. (окна 7 виртуальных машин).
Например, если я запускаю следующие команды на клиентском ПК сразу после того, как попытка получить доступ к компьютеру приводит к сообщению об ошибке "сервер не найден", я получаю следующий вывод:
ipconfig /displaydns
vm1host.mycompany.local
----------------------------------------
Name does not exist.
nslookup vm1host
Server: dnsserver1.mycompany.local
Address: <dnsserver1-ip-address>
*** dnsserver1.mycompany.local can't find vm1host: Non-existent domain
nslookup vm1host.mycompany.local
Server: dnsserver1.mycompany.local
Address: <dnsserver1-ip-address>
*** dnsserver1.mycompany.local can't find vm1host.mycompany.local: Non-existent domain
Nslookup
Server: dnsserver1.mycompany.local
Address: <dnsserver1-ip-address>
Name: vm1host.mycompany.local
Address: <vm1-ip-address>
ping vm1host
Ping request could not find host vm1host. Please check the name and try again.
ping vm1host.mycompany.local
Ping request could not find host vm1host.mycompany.local Please check the name and try again.
пинг
Pinging <vm1-ip-address> with 32 bytes of data:
Reply from <vm1-ip-address>: bytes=32 time=1ms TTL=127
Reply from <vm1-ip-address>: bytes=32 time<1ms TTL=127
Reply from <vm1-ip-address>: bytes=32 time=2ms TTL=127
Reply from <vm1-ip-address>: bytes=32 time<1ms TTL=127
Ping statistics for <vm1-ip-address>:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 2ms, Average = 0ms
Я обсудил проблему с ИТ-отделом, и после того, как мне удалось доказать им, что проблема не в клиентских ПК, мне дали возможность жить с проблемой, изменить файл hosts для каждого клиента или подать заявку на получение кого-либо от ИТ вручную добавьте запись на DNS-сервер (ы), отображающий имя хоста / IP-адрес каждого проблемного компьютера.
Последнее действие, скорее всего, решит текущую проблему, но не приблизит меня к пониманию причины проблемы и не сделает меня менее зависимым от ИТ в следующий раз, когда новая виртуальная машина столкнется с этой проблемой.
Попытки решить эту проблему с моей стороны включают в себя выполнение следующих действий на каждой проблемной машине:
работает ipconfig /registerdns
запуск пакетных скриптов, которые периодически вызывают ipconfig /registerdns
изменив имя машины, включив его в рабочую группу, перезапустив машину, изменив имя машины обратно на его первоначальное имя, вернувшись к локальному домену, перезапустив машину.
Добавление записи
DWORDименем «DisabledComponents» со значением0x20в следующий раздел реестра:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\(в случае, если машины неправильно регистрируют свой адрес IPv6 вместо своего адреса IPv4)
Что касается шага 3, когда у меня были машины, присоединяющиеся к локальному домену, я получил сообщение «Изменение DNS-имени основного домена этого компьютера на" "не удалось».
Согласно этой статье http://support.microsoft.com/kb/2018583 причина сообщения может быть одной из следующих:
- Флажок «Отключить NetBIOS через TCP/IP» был отключен в свойствах IPv4 присоединяемого компьютера
- Соединение через UDP-порт 137 заблокировано между клиентом и вспомогательным DC, обслуживающим операцию соединения в целевом домене *
- Протокол TCP/IPv4 был отключен, поэтому клиент, к которому присоединяется, или DC в домене назначения, на который нацелено LDAP BIND, используют только TCP/IPv6.
Я подтвердил, что ни один из них не имеет место. Я также подтвердил, что брандмауэр компьютеров использует профиль домена и имеет следующие правила, касающиеся порта 137 UPD:
Входящий домен включен:
- - Общий доступ к файлам и принтерам (NB-Name-In), локальный порт UPD 137
- -NetBIOS Name Service, локальный порт UPD 137 + определенный удаленный набор адресов, который я предполагаю политикой брандмауэра домена
Входящий домен отключен:
- -Network-Discovery (NB-Name-In), локальный порт UPD 137
Исходящий домен включен:
- - Общий доступ к файлам и принтерам (NB-Name-Out), удаленный порт UPD 137
Исходящий домен отключен:
- -Network-Discovery (NB-Name-Out), удаленный порт UPD 137
И опять же, настройки брандмауэра для компьютеров с Windows Server, имя хоста которых DNS-серверы не удается разрешить, устанавливаются аналогично.
В статье базы знаний, на которую я ссылался, в конечном итоге признавалось, что пока NetpCompleteOfflineDomainJoin SUCCESS: Requested a reboot :0x0 появляется в C:\Windows\debug\NetSetup.LOG , сообщение об ошибке немного больше, чем раздражение.
Чтобы сделать историю еще длиннее, пытаясь определить, была ли проблема в том, как настроены виртуальные машины Windows 7 или DNS-сервер, я настроил свой собственный DNS-сервер, и мой клиентский компьютер указывал на этот DNS-сервер и Удивительно, но мой DNS-сервер никогда не мог разрешить имена хостов ни одной из моих виртуальных машин. Увы, как только я поделился хорошими новостями с ИТ-специалистами, мне сказали, чтобы они были сняты, потому что это может испортить DNS-серверы компании.
Кроме того, никогда больше не полагаться на DNS-сервер для разрешения имени хоста машины под управлением Windows 7 (и здесь я в затруднении и предполагаю, что проблема как-то связана с тем фактом, что все уязвимые машины работают под управлением Windows 7). Что еще я могу сделать, чтобы решить текущую проблему и предотвратить подобные проблемы в будущем?