Эта проблема:
Клиентские компьютеры в локальной сети отправляют эхо-запрос на remote.mydomain.com, и он преобразуется в наш статический IP-адрес в глобальной сети. Он должен разрешить локальный IP-адрес нашего сервера.
Детали: Всего у нас есть один сервер, на котором работает SBS 2008 на довольно быстром оборудовании (при необходимости могу описать). Я ввел некоторые записи локальной DNS-зоны A, чтобы пользователи могли беспрепятственно использовать Outlook Web Access независимо от того, находятся они в локальной сети или за ее пределами. Эти записи DNS включают remote.mydomain.com и outlook.mydomain.com. Два домена не нужны, но пользователям легче запомнить последний при доступе к OWA.
Я также настроил наш DHCP-сервер SBS 2008 так, чтобы клиентские компьютеры получали три IP-адреса DNS-сервера следующим образом:
192.168.1.10 (our SBS server)
208.67.222.222 (OpenDNS)
208.67.220.200 (OpenDNS)
Причина, по которой я настроил его таким образом, заключается в том, что клиенты все равно будут иметь доступ к Интернету в том редком случае, когда наш сервер не работает.
Я думаю, проблема в том, что SBS 2008 недостаточно быстро отвечает на запросы DNS, поэтому клиенты вместо этого отправляют запрос OpenDNS, который возвращает правильный адрес, только если они находятся вне локальной сети.
К вашему сведению, мы используем маршрутизатор SonicWall TZ-210.
Я ищу любые предложения о том, как я могу гарантировать, что клиентские компьютеры в локальной сети могут получить доступ к OWA в нашей локальной сети, не отключая «резервные» адреса DNS-серверов, которые я настроил через DHCP.
Адреса «резервных» DNS-серверов не являются хорошей идеей и являются корнем вашей проблемы. Вы можете играть в игры с брандмауэром с фильтрацией пакетов, чтобы попытаться «обойти», но вам лучше использовать только контроллер домена в качестве DNS-сервера для ваших клиентов.
В общем, вы никогда не должны указывать DNS-серверы на клиентах Active Directory, которые не могут разрешать DNS-записи домена AD. Вы получите недетерминированную производительность входов в систему, групповой политики и / или корней DFS домена в случаях с такой конфигурацией. Клиенты в значительной степени полагаются на DNS для принятия «правильных решений» при работе с Active Directory.
Укажите для своих клиентов только сервер AD DNS, и все будет хорошо. Если вас беспокоит, что DNS "не работает", откройте дополнительный контроллер домена и установите на нем роль DNS-сервера. (В любом случае наличие второго DC - это дешевый страховой полис, и его неплохо иметь. Однако, по моему опыту, отключение DNS-сервера SBS, вероятно, означает, что у вас гораздо больше проблем, чем у клиентов, которые могут для просмотра веб-сайтов.)
Поскольку вы используете внешние DNS-серверы в дополнение к внутренним, клиенты могут решить цикл DNS-запросов ко всем настроенным серверам. Когда вы пытаетесь разрешить mydomain.com, эти внешние DNS-серверы предоставляют вашу WAN-ссылку в качестве ответа. Затем эти локальные машины кэшируют ответ.
Я думаю, что неплохо иметь внешние DNS-серверы на случай, если сервер выйдет из строя, но на самом деле, если сервер не работает, у вас есть более серьезные проблемы, чем то, может ли каждый получить доступ к Интернету.
Из моего тестирования с моим ящиком Windows 7, если предпочтительный сервер имен не возвращает ответ в течение 1 секунды, он переходит к следующему в строке. Он не будет повторять попытку того, от которого не получил ответа, придерживаясь того, от которого он получил ответ. Таким образом, наличие такого разделенного DNS-сервера вызовет проблемы только потому, что если ваши системы LAN когда-либо переключатся на общедоступные DNS-серверы, вам будет сложно вернуть их обратно к LAN DNS. Если вы действительно беспокоитесь о единой точке отказа, возьмите еще один ящик для внутренней работы с DNS. Это можно легко сделать с помощью дешевого Linux-сервера, работающего с BIND в качестве ведомого устройства.