Мы - небольшая организация на 300 мест со смешанной средой BYOD и Active Directory (Windows Server 2012 Standard, Windows 7 Enterprise), и у нас возникла очень странная проблема, связанная с очень специфическими ошибками при разрешении доменного имени нашей организации в нашем домене. объединенные, контролируемые компанией машины. Для целей этого обсуждения я буду использовать company.com вместо нашего доменного имени.
Фон:
- Контроллер домена Active Directory находится по адресу 172.16.1.3
- Машина AD / DC также работает с DHCP, DNS и HTTP (IIS)
- Веб-сайты наших организаций по адресу company.com и subdomain.company.com размещаются IIS на компьютере AD / DC.
- У нас есть сценарий разделения DNS, в котором сервер AD / DC используется для внутреннего разрешения DNS, но другой внешний сервер обеспечивает разрешение DNS для открытых запросов.
- IP-адрес, соответствующий company.com и subdomain.company.com, является общедоступным IP-адресом, используемым брандмауэром на границе нашей сети (как на DNS-сервере AD / DC, так и на стороннем DNS-сервере).
- Брандмауэр правильно настроен для NAT для передачи запросов HTTP и HTTPS, которые он получает на своем общедоступном IP-адресе, на внутренний IP-адрес сервера AD / DC и отражает
Сценарий 1:
- Пользователь на присоединенной к домену машине Windows 7 Enterprise напрямую подключен к нашей локальной сети с локальным адресом 172.16.6.100 / 16, выданным сервером DHCP.
- Запись DNS-сервера предоставляется DHCP (172.16.1.3)
- Этот пользователь может получить доступ к веб-сайтам, размещенным на сайтах company.com и subdomain.company.com.
- Изменить: nslookup был запущен в этом сценарии и правильно возвращает соответствующую запись DNS с внутреннего сервера DNS (172.16.1.3)
Сценарий 2:
- Один и тот же пользователь на том же компьютере Windows 7 Enterprise, подключенном к домену, идет домой и подключается к Интернету, используя своего постоянного интернет-провайдера.
- Записи IP и DNS-сервера для клиентского компьютера предоставляются DHCP
- Этот пользователь может получить доступ к любым интернет-ресурсам, таким как google.com.
- Этот пользователь не может получить доступ к веб-сайту по адресу company.com или subdomain.company.com (возвращается ошибка «узел не решен»)
- Когда этот пользователь запускает NSlookup на company.com они DO получить правильный публичный IP - адрес , предоставленный DNS
- HTTP / HTTPS-запросы к IP-адресу успешно выполняются, и веб-страница правильно возвращается сервером
- Эта проблема преобладает во всех веб-браузерах
- Использование tracert company.com возвращает «невозможно определить имя целевой системы»
- При использовании ping company.com возвращает «не удалось найти хост company.com»
- При запуске Wireshark на клиенте до / во время неудачного запроса клиентская машина не отправляет пакеты (ни для разрешения DNS, ни для первоначального запроса HTTP / ping / tracert)
- Перезапуск службы DNS-клиента не решает проблему
- Остановка службы DNS-клиента не решает проблему
- Использование ipconfig / flushdns не решает эту проблему
- Использование маршрута / f не решает эту проблему
- Сброс сетевых подключений с помощью netsh int ip reset не решает эту проблему
- Изменить: nslookup был запущен в этом сценарии и правильно возвращает правильную запись DNS с DNS-сервера, указанного в настройках DHCP сети, используемой пользователем
Сценарий 3:
- Этот же пользователь на персональном (не присоединенном к домену) компьютере Windows 7 Professional может получить доступ к веб-сайтам компании company.com и subdomain.company.com при подключении к нашей локальной сети.
- Изменить: nslookup был запущен в этом сценарии и правильно возвращает соответствующую запись DNS с внутреннего сервера DNS (172.16.1.3)
Сценарий 4:
- Этот же пользователь на персональном (не присоединенном к домену) компьютере под управлением Windows 7 Professional имеет доступ к веб-сайтам компании company.com и subdomain.company.com при подключении к своей домашней сети.
- Изменить: nslookup был запущен в этом сценарии и правильно возвращает правильную запись DNS с DNS-сервера, указанного в настройках DHCP сети, используемой пользователем
Заключительные замечания:
Эта проблема, по-видимому, распространяется на все принадлежащие компании компьютеры. Мы используем общий образ системы для всех компьютеров, принадлежащих компании, который был только что загружен в августе. Я искал в интернете в поисках возможных решений и дошел до сих пор с пустыми руками - я действительно ценю любые предложения или советы, которые вы можете иметь.
www.company.comно не только,company.comили оба терпят неудачу?Ответы:
Присоединенные к домену компьютеры будут искать свой DC, а не просто искать на основе DNS. Поскольку домен совпадает с общедоступным веб-сайтом, они будут искать запись SRV, чтобы сообщить им, как добраться до DC и получить информацию о домене. Поскольку в удаленной сети нет DC, они не могут разрешить это имя, используя обычные части Windows с поддержкой AD.
Когда вы используете ping или (почти) любое приложение Windows, оно использует полный стек Windows IP, включая части, которые общаются с AD. В то время как NSLookup на самом деле просто делает DNS-запрос. Вы проверили это с помощью своих трассировок Wireshark. Windows не выполняет поиск при попытке перейти на company.com, но nslookup показывает правильный поиск DNS. Вот почему вы не можете разрешить домен с помощью ping или веб-браузера, но с nslookup все в порядке.
Решением для первой части этого является использование www.company.com для доступа к сайту как внутри, так и снаружи, чтобы клиенты полностью игнорировали поиск DC.
Решение для второй части сложнее в зависимости от того, на что subdomain.company.com ссылается как внутри, так и снаружи. Есть ли на контроллере домена запись DNS для субдомена, или эти запросы просто отправляются на внешний DNS-сервер? Если у него есть запись DNS, куда эта точка указывает?
источник
Я хотел бы проверить, что файл HOSTS ( http://en.wikipedia.org/wiki/Hosts_%28file%29#Location_in_the_file_system ) на компьютере не содержит записей для хостов, к которым вы пытаетесь добраться. Я думаю, что инструмент NSLOOKUP обходит файл hosts, но веб-браузер не будет.
Я также хотел бы убедиться, что у вас не настроен прокси-сервер в веб-браузере, поскольку некоторые типы прокси также разрешают DNS.
Я также попытался бы запустить браузер в «безопасном режиме» (т. Е. Со всеми отключенными надстройками и плагинами) с IE («iexplore -extoff») или Firefox (удерживая нажатой клавишу Shift при запуске или «firefox -safe-mode»).
В идеале, если возможно, попытайтесь с помощью другого веб-браузера определить, является ли он веб-браузером или операционной системой.
Тогда, если бы я до сих пор никуда не попал, я бы проверил, какие сервисы связаны с сетевым адаптером (сумасшедший брандмауэр с конкретными правилами, мешающими?)
Наконец, и это становится все менее вероятным, но NSLOOKUP автоматически добавит имя домена компьютера или подключения к запросам автоматически. Например, мой маршрутизатор устанавливает доменное имя как «router», поэтому любой nslookup для чего-то вроде «matthew» на самом деле ищет в DNS «matthew.router», возможно, веб-браузер этого не делает… как вы сказали, что сделали пакет захватить это не звучит так, как будто это ваша проблема ... но на тот случай, если вы пропустили это при захвате пакета или ваша среда захвата была не совсем правильной :-).
Это то, что я бы попробовал, и, надеюсь, это вам тоже поможет :-).
источник