☰

Путаница с DNS на сервере Windows и Sonicwall

tag-icon • tag-icon windows-server-2008 domain-name-system sonicwall
Путаница с DNS на сервере Windows и Sonicwall

Я немного почитал сегодня вечером о том, как лучше настроить нашу школьную сеть для подключения к Интернету. Она работает так, как есть, но время от времени возникают сбои в клиент-серверном доступе к Интернету. (Примечание: Sonicwall всегда видит Интернет)

Мой набор такой:

Интернет---Sonicwall---Управляемый коммутатор---Сервер Win 2k8 r2 | Клиенты и принтеры

Звуковая стена

  • Зона LAN с IP-адресом из нашего диапазона IP-адресов
  • Зона WAN со статическим IP-адресом, назначенным провайдером, и DNS, настроенным на DNS Google и DNS провайдера в качестве резервного

Windows Server (просто внутренний файловый сервер)

  • Активный каталог
  • DNS (установлен на 127.0.0.1)
  • DHCP динамически для небольшого гостевого диапазона (телефоны),
  • Статический DHCP для устройств и клиентов студентов и преподавателей (в целях фильтрации)

Клиенты

  • Шлюз настроен на IP Sonicwall
  • DNS настроен на IP-адрес сервера (на некоторых системах Win8 мне приходилось устанавливать альтернативный DNS на 8.8.8.8 для подключения к Интернету).

Итак, вопросы:

Из того, что я прочитал сегодня вечером, мне кажется, что мне следовало бы:

  • Sonicwall WAN смотрит внутрь на IP-адрес сервера для DNS
  • Сервер настроен на переадресацию для просмотра наружу на DNS Google/ISP
  • DNS-сервер клиента настроен на IP-адрес сервера, а шлюз — на IP-адрес Sonicwall.

Может ли кто-нибудь это проверить? Я в замешательстве. Если Sonicwall обращается к серверу за DNS в Интернете, не будут ли мои клиенты A) тормозить сервер и B) не иметь интернета, когда сервер выключен?

Если это не лучшая практика, то что? Я уже делаю это правильно? Должен ли клиентский DNS смотреть на сервер и интернет-провайдера?

Спасибо! Крис

решение1

Поскольку на сервере работает Active Directory/DNS, клиентыДОЛЖЕНнастраивают DNS на сервер для правильного разрешения домена/подключения к внутренним ресурсам.

Главное — настроить службу DNS сервера на пересылку всех нелокальных запросов внешнему резолверу (например, Google [8.8.8.8; 8.8.4.4]). Трафик DNS настолько мал, что не должен оказывать заметного влияния на ваш сервер, если только вы не установили слишком низкий размер кэша.

Сетевой стек сервера должен быть настроен на обращение к 127.0.0.1 (или его локальному адресу) для разрешения DNS, а служба должна быть настроена с использованием пересылок.

Что касается Sonicwall, вы можете установить его любым способом. Если вы хотите, чтобы Sonicwall мог разрешать как внутренние, так и внешние FQDN, то ему нужно будет использовать ваш локальный сервер для разрешения. Если вам нужны только внешние, то установите его на резольверы вашего провайдера или Google.

решение2

Как уже заявил JuxVP, любые клиенты Windows, подключенные к доменудолженнастройте свои DNS на сервер AD, иначе многие службы не будут работать, особенно аутентификация. Все остальные внутренние клиенты должны настроить свои DNS на сервер AD, если вы хотите, чтобы они разрешали внутренние имена.

Кроме того, клиенты Windows, подключенные к домену,не долженесть ли в списке другие DNS-серверы, которые не могут разрешать запросы AD, т.к. Windows не гарантирует порядок поиска. Пример: если у вас следующая конфигурация на клиенте:

DNS1: 192.168.10.10 (AD server)
DNS2: 8.8.8.8 (Google DNS)

то у вас, скорее всего, будут проблемы с аутентификацией, необычное зависание или другие проблемы со связью. Это связано с тем, что клиент может запросить DNS Google, adserver.domain.localа сервер Google ответит does not existвместо тайм-аута. Клиент попробует другой сервер только в том случае, если первый не ответит. Если клиент получит ответ does not exist, он сдастся, и поиск завершится неудачей.

решение3

  • DNS-сервер Sonicwall должен быть настроен на IP-адрес DNS вашего интернет-провайдера.
  • Ваш сервер (т. е. DNS-сервер домена) может быть настроен с переадресацией на DNS Google.
  • DNS конечной точки должен быть настроен на DNS-сервер домена.

решение4

Поскольку вы работаете в сфере образования, я рекомендую настроить ваш внутренний DNS-сервер для пересылки всех запросов в OpenDNS. Они предлагают специальные планы только для K-12, чтобы соответствовать требованиям CIPA [0]. Они также предлагают защиту от вредоносных программ, при которой запросы на вредоносные ресурсы будут блокироваться.

С помощью вышеуказанной конфигурации настройте каждый хост/устройство/и т. д. в вашей сети на использование вашего внутреннего DNS-сервера. Это обеспечит вашим клиентам успешное внутреннее подключение друг к другу и особенно важно при работе с Microsoft Active Directory.

Затем настройте все списки контроля доступа маршрутизатора и правила брандмауэра так, чтобы разрешить исходящие DNS-запросы только с вашего внутреннего DNS-сервера на серверы OpenDNS. Преимущество этого в том, что некоторые вредоносные программы попытаются выполнить DNS-запросы напрямую на публичные серверы имен. Такая конфигурация гарантирует, что запрос пройдет через ваши серверы и в конечном итоге OpenDNS, где он, как мы надеемся, будет пойман. Любой обнаруженный хост, не использующий внутренний DNS-сервер (журналы брандмауэра), должен быть проверен на предмет неправильной конфигурации или вредоносного ПО, поскольку это может быть признаком компрометации.

Наконец, внедрите списки контроля доступа маршрутизатора и/или правила брандмауэра, чтобы заблокировать доступ к вашему DNS-серверу из общедоступного Интернета.

[0]https://www.opendns.com/enterprise-security/solutions/k-12/

Связанный контент