Это довольно сложная проблема, но я постараюсь сделать ее понятной:
У меня три подсети. Мы назовем их 10.10.0.0/22, 10.20.0.0/22 и 10.30.0.0/16. У меня два домена AD, но я не думаю, что это важно.
10.30.0.x подсеть - это место, где живет большинство машин в моей сети. Подсети 10.10 и 10.20 предназначены для интенсивного трафика между серверами. (Перенос хранилища и виртуальной машины.)
Контроллеры домена (и DNS-серверы) имеют интерфейсы во всех трех подсетях, поэтому они могут аутентифицировать машины во всех трех подсетях. Поэтому мы включили приоритизацию подсети на DNS-серверах, что означает, что они будут пытаться упорядочить результаты DNS с предпочтением в сторону подсети клиента. Так, например, я делаю запрос из подсети 10.30 для server.company.com (который также имеет интерфейсы во всех трех подсетях), он вернет все три IP-адреса для этого компьютера, но вернет их в порядке 10.30. 0,5, 10.20.0.5, 10.10.0.5. (Последние два можно поменять местами)
Кажется, все в DNS работает должным образом. Моя рабочая станция только в подсети 10.30. Однако, когда я пингую server.company.com, он всегда разрешается либо 10.20.0.5, либо 10.10.0.5, и никогда до 10.30.0.5. Я запустил Wireshark захват трафика DNS, и DNS-серверы определенно возвращают результаты в правильном порядке. Однако мой клиент полностью игнорирует запись 10.30. Он всегда разрешается в 10.20 или 10.10, в зависимости от того, что будет следующим в ответе DNS. Запросы nslookup всегда кажутся правильными, но nslookup на самом деле не разрешает запрос, а только предоставляет ответ DNS-сервера, который, насколько я понимаю, правильный.
Я использую Windows 10 со всеми доступными обновлениями Windows. (Нет инсайдерских компонентов) Я подтвердил такое же поведение по крайней мере на четырех других машинах под управлением Windows 10, но некоторые другие машины под управлением Windows 10 работают правильно. Я тестировал Windows 8, 7, все последние версии Server и несколько Linux-машин, и все разрешается правильно. Это появляется только на некоторых машинах с Windows 10, хотя я не могу окончательно исключить возможность того, что это происходит где-то еще.
Вот где это становится странным: я могу редактировать файл HOSTS на своей машине, и если запись 10.30 является единственной записью для сервера, она разрешается правильно. Но если есть другие варианты, он выберет их. Не имеет значения, стоит ли запись 10.30 первой в списке.
А потом действительно странно: я могу RDP на server.company.com просто отлично, в 100% случаев. Я открываю окно cmd и пинг или Tracert server.company.com, и он разрешается до 10.10.0.5. Я печатаю mstsc -v:10.10.0.5 и время ожидания истекает, поэтому он недоступен по этому адресу. (А этого не должно быть) Однако, mstsc -v:10.30.0.5 и mstsc -v:server.company.com на самом деле работают, что означает, что ping, похоже, не использует тот же механизм разрешения, что и Microsoft RDP Client. Я тоже не очищаю свой кеш DNS. На самом деле записи перечислены в правильном порядке, когда я набираю ipconfig /displaydns. Диспетчер сервера (RSAT), казалось бы, может управлять сервером с моей рабочей станции, но диспетчер Hyper-V не может. Кажется, что RPC работает, но я получаю странные ошибки аутентификации с некоторыми функциями. По какой-то причине некоторые приложения просто полностью пропускают подсеть 10.30.
Может ли быть что-то в групповой политике, указывающее Windows на снижение приоритета определенных подсетей? Все подсети перечислены в Active Directory Sites and Services, и я не думаю, что я сделал что-то там особенное. (Есть только один сайт.) Есть ли что-нибудь еще, что могло бы заставить разрешение имен пропустить подсеть по какой-либо причине?
РЕДАКТИРОВАТЬ: Я очень ценю совет против использования контроллеров домена с несколькими адресами в Active Directory, однако это было сделано по необходимости, и я не верю, что это фактор проблемы. Трассировки Wireshark убедительно показывают, что список DNS возвращается в правильном порядке с локальной подсетью в качестве первой записи. Однако Windows, и это похоже на ICMP, предпочитает игнорировать эту запись и использовать вторую, которая возвращается. (Если Windows не использует другие средства разрешения адресов и, прежде чем вы спросите, NetBIOS отключен. :))
Если вам действительно нужно сделать ваш DC многодомным, выполните следующие действия. Я взял их из там. Документ ссылается на старую базу знаний, но это обновленный документ от известного блогера.
Ниже приведены инструкции по настройке Multihomed DC.
Убедитесь, что все сетевые адаптеры указывают только на ваш внутренний DNS-сервер и никакие другие, например IP-адреса DNS-серверов вашего интернет-провайдера.
В свойствах «Сеть и коммутируемое соединение», пункт «Расширенное меню», «Дополнительные настройки» переместите внутреннюю сетевую карту (сеть, в которой находится AD) в начало порядка привязки (вверху списка).
Отключите возможность регистрации внешнего сетевого адаптера. Как уже упоминалось, процедура включает идентификацию номера GUID внешнего сетевого адаптера. Следующая ссылка покажет вам, как:
246804 - Как включить-отключить динамическую регистрацию DNS в Windows 2000 (также для каждой сетевой карты): http://support.microsoft.com/?id=246804
Вы можете посмотреть шаг № 3 в следующей статье, чтобы показать вам, как отключить NetBIOS на интерфейсах RRAS, если это сервер RRAS.
Глава 11 - NetBIOS через TCP / IP http://technet.microsoft.com/en-us/library/bb727013.aspx
Или включите / отключите NetBIOS на интерфейсе в реестре:
Чтобы сделать это в реестре, вам нужно будет определить GUID этого интерфейса (это может не относиться к интерфейсам PPP) HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ NetBT \ Parameters \ Interfaces, найдите GUID с установленным NetbiosOptions в 0 и установите их в 2. Используя WMIC:
Сначала получите список интерфейсов: wmic nicconfig get caption, index, TcpipNetbiosOptions
Затем используйте «порядковый номер» в следующей команде: wmic nicconfig, где index = 1, вызовите SetTcpipNetbios 2
Параметры SetTcpopNetbios:
0 - Использовать настройку NetBIOS с DHCP-сервера 1 - Включить NetBIOS через TCP / IP 2 - Отключить NetBIOS через TCP / IP
Более подробную информацию о командах wmic и записях реестра можно найти в этой ссылке на ветку форума:
Thread - Настройка NetBIOS через TCP / IP http://social.technet.microsoft.com/Forums/en-US/winservercore/thread/d18bd172-e1a0-4a61-ba52-0952a1e3cabc/
Настройте TCP / IP для использования WINS http://technet.microsoft.com/en-us/library/cc757386(WS.10).aspx
Примечание. Стандартная служба Windows, называемая «службой браузера», предоставляет список машин, рабочих групп и доменных имен, которые вы видите в «Мое сетевое окружение» (или устаревший термин «Сетевое окружение»). Служба браузера полагается на службу NetBIOS. Одно из основных требований службы NetBIOS - машина может иметь только одно имя для одного IP-адреса. Это своего рода отпечаток пальца. У вас не может быть двух братьев по имени Даррелл. Многосетевой компьютер вызовет ошибки дублирования имени на себе, потому что Windows видит себя с тем же именем в списке просмотра («Мое сетевое окружение»), но с разными IP-адресами. У вас может быть только один, поэтому возникает ошибка.
Отключите «Службу файлов и печати» и отключите «Службу клиента MS» на внешнем сетевом адаптере. Это можно сделать в свойствах сетевой карты, сняв флажок с соответствующей службы на странице общих свойств. Если вам нужны эти службы на внешнем сетевом адаптере (что маловероятно), которые позволяют другим машинам подключаться к вашему компьютеру для доступа к ресурсам на вашем компьютере (общие папки, принтеры и т. Д.), То вам, вероятно, потребуется оставить их включенными.
Снимите флажок «Зарегистрировать это соединение» в разделе «Свойства IP», «Дополнительные настройки», на вкладке «DNS».
Удалите IP-адрес внешнего сетевого адаптера, отключите регистрацию в Netlogon и вручную создайте необходимые записи.
а. В DNS под именем зоны (ваше доменное имя DNS) удалите IP-ссылки внешнего сетевого адаптера для «LdapIpAddress».
б. Если это GC, вам также необходимо удалить IP-запись GC («GcIpAddress»). Для этого в консоли DNS под названием зоны вы увидите папку _msdcs. В папке _msdcs вы увидите папку _gc. Справа вы увидите IP-адрес, ссылающийся на адрес GC. Это называется GcIpAddress. Удалите IP-адреса, ссылающиеся на внешний сетевой адаптер.
1. To stop these two records from registering that information, use the steps provided in the links below:
Private Network Interfaces on a Domain Controller Are Registered in DNS
http://support.microsoft.com/?id=295328
2.. The one section of the article that disables these records is done with this registry entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
(Create this Multi-String Value under it):
Registry value: DnsAvoidRegisterRecords
Data type: REG_MULTI_SZ
Values: LdapIpAddress
GcIpAddress
The following link provides more information on the LdapIpAddress and GcIpAddress, as well as other Netlogon Service records:
Restrict the DNS SRV resource records updated by the Netlogon service[includingGC]:
http://technet.microsoft.com/en-us/library/cc778029(WS.10).aspx
3. Then you will need to manually create GcIpAddress and IpAddress records in DNS with the IP addresses that you need for the DC. To create the LdapIpAddress, manually create a new host under the domain, but leave the “hostname” field blank, and provide the internal IP of the DC, which results in a record that looks like:
(то же, что и родительский) 192.168.5.200 (в этом примере используется 192.168.5.200)
4. You need to also manually create the GcIpAddress as well, if this is a GC. That would be under the _msdcs._gc SRV record under the zone. It is created in the same fashion as the LdapIpAddress mentioned above.
В консоли DNS щелкните правой кнопкой мыши имя сервера, выберите свойства, затем на вкладке «Интерфейсы» заставьте его прослушивать только IP-адрес внутреннего сетевого адаптера, а не IP-адрес внешнего сетевого адаптера.
Поскольку это также DNS-сервер, IP-адреса всех сетевых адаптеров будут зарегистрированы, даже если вы укажете это не в свойствах NIC. Посмотрите это, чтобы показать вам, как остановить такое поведение (эта процедура предназначена для Windows 2000, но также будет работать для Windows 2003):
275554 - Запись A хоста регистрируется в DNS после того, как вы решили не регистрировать адрес подключения: http://support.microsoft.com/?id=275554
Отключите циклический перебор на DNS-сервере. Для этого: (Этот шаг добавлен 5/2010) 1. Щелкните Пуск, щелкните Параметры, щелкните Администрирование, а затем щелкните DNS. 2. Откройте свойства имени DNS-сервера.
Если вы еще не сделали этого, настройте сервер пересылки. Вы можете использовать 4.2.2.2 и 4.2.2.3, если не знаете, на какой DNS перенаправлять, пока не получите DNS-адрес своего интернет-провайдера. Как настроить экспедитора? Хороший вопрос. В зависимости от вашей операционной системы выберите одну из следующих статей, в зависимости от вашей операционной системы.
300202 - КАК: настроить DNS для доступа в Интернет в Windows 2000 http://support.microsoft.com/?id=300202
323380 - КАК: настроить DNS для доступа в Интернет в Windows Server 2003 (как настроить сервер пересылки): http://support.microsoft.com/d/id?=323380
Настройка DNS-сервера для использования серверов пересылки - Windows 2008 и 2008 R2 http://technet.microsoft.com/en-us/library/cc754941.aspx
Active Directory и NAT
Я подумал коснуться этого упущенного факта о связи AD через NAT.
Если запланированные ресурсы должны быть предоставлены в инфраструктуре AD, использующей аутентификацию AD (Kerberos), которая должна проходить через NAT, это в основном не сработает. Это связано с безопасным обменом данными RPC и невозможностью трансляции трафика через NAT из-за шифрования. Если вам действительно нужно заставить его работать, существуют решения, позволяющие обойти это, например, Direct VPN между службами на устройствах NAT или дополнительные сетевые адаптеры, напрямую соединяющие их. Подробнее об этом читайте по этой ссылке, а также о том, как Microsoft думает и предлагает решение по этому поводу:
Описание границ поддержки Active Directory через NAT http://support.microsoft.com/default.aspx?scid=kb;en-us;978772&sd=rss&spid=12925
Сбой связи Active Directory на контроллерах домена с несколькими сетями http://support.microsoft.com/kb/272294
Выбор исходного IP-адреса на многодомном компьютере под управлением Windows
Часто возникает путаница в том, как компьютер выбирает, какой адаптер использовать при отправке трафика. В этом блоге описывается процесс выбора сетевого адаптера для исходящего соединения на многосетевом компьютере и то, как для этого соединения выбирается локальный IP-адрес источника.
Выбор исходного IP-адреса на многодомном компьютере под управлением Windows http://blogs.technet.com/b/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx
Согласно этой статье Приоритезация DNS на стороне клиента в Windows 10
К сожалению, здесь есть загвоздка; на сегодняшний день реализация RFC в Windows 10 или, по крайней мере, реализация правила 9 в корне нарушена. Как указано, правило 9 сравнивает IP-адрес клиента с каждым адресом, полученным из запроса DNS, определяя значение с самым длинным совпадающим префиксом. Это сравнение основано на трансляции IPv6 адреса IPv4 (даже если IPv6 не включен), но, к сожалению, вместо того, чтобы основывать сравнение на длине адреса IPv6, сравнение неправильно использует длину адреса IPv4 (т.е. при сравнении фактически используется часть переведенного IPv6-адреса). Группа разработчиков продукта Microsoft подтвердила ошибку и разработала частное исправление, который должен стать общедоступным в ближайшие несколько недель.
Вот временное решение (до перезагрузки) из другой статьи:
netsh int ipv6 set locality state=disabled
Попробуйте: NETSH winsock сбросить каталог и обязательно перезапустить
Хорошо, множественная адресация не имеет к этому никакого отношения, так как у меня такая же проблема с некоторыми из моих клиентов Win 10. Я пробовал все решения, которые могу найти или придумать - DNS-сервер настроен без циклического перебора и приоритета подсети DNS, я настроил параметры реестра как на серверах, так и на хостах, чтобы протолкнуть DNS приоритет подсети включен (установлен на правильную длину маски, хотя мы находимся на / 24, так что в любом случае он должен быть по умолчанию правильно). На самом деле это довольно банально, как покажет быстрый поиск проблемы в Google, и не имеет отношения к необычным настройкам сети - вы можете получить то же самое в любой сети, достаточно сложной для определения приоритетов подсети, но это только некоторые клиенты.
Проблема определенно на 100% связана с клиентской стороной. Мы находим проблему только на коробках с Win 10 (на одном этапе у нас были похожие вещи с Win 8, но это было устранено с помощью рег-хаков - Win 10 просто смеется над ними). Запросы DNS возвращают правильные ответы (я также подтвердил это с помощью Wireshark), и клиенты будут указывать на правильный адрес в течение 4-5 секунд после получения IP-адреса, прежде чем перейти на неправильный ответ подсети.
В настоящее время я пытаюсь решить эту проблему, взламывая файл hosts на отдельных клиентах; после перезагрузки он всегда будет указывать правильно. Мне повезло, что у меня всего 250 машин, из которых пока только около 15 на Win 10, из которых только около половины затронуты, так что в настоящее время это управляемо. Но да, для крупных развертываний или для мобильных пользователей это не совсем подходящее решение.
Но да, просто хотел сообщить вам, что это не только вы, это не из-за вашей необычной настройки сети, и не стоит искать для этого DNS, поскольку DNS явно не вызывает этого.