UniFi с CloudKey на Windows Server 2016 в домене

UniFi с CloudKey на Windows Server 2016 в домене, UniFi Network

HenryTheTech

Guest

23.03.2018 14:18:00

USG-PRO-4 (шлюз), US 48 500W (коммутатор), UAP-AC-PRO-E (точки доступа) и CloudKey — всё это будет установлено. Просто интересно, могут ли возникнуть какие-то конфликты с контроллером домена Windows Server 2016, если UniFi будет работать как DHCP/DNS. Стоит ли включать DHCP/DNS на Windows Server, если мы используем UniFi в экосистеме?

greggmh123

Guest

21.07.2018 01:27:00

Я работаю с SBS с тех времён, когда он был на базе NT4, и ни разу не слышал такую рекомендацию после того, как в Windows 2000 появились домены с AD. Интересно.

Что касается использования AD DNS в качестве основного, а внешнего DNS — вторичным, это действительно можно сделать без проблем, если добавить запись в реестр, которая заставит все DNS-запросы сначала обращаться к основному серверу. Даже если основной AD сервер упадёт, а в качестве внешнего стоит 8.8.8.8, первый запрос всё равно пойдёт на основной (AD) DNS-сервер. Это работает, но в таком случае DNS-запросы будут обрабатываться дольше, потому что при каждом запросе сначала будет происходить тайм-аут на основном сервере, а уже потом попытка на вторичном. По крайней мере, пользователи всё равно смогут просматривать интернет и пользоваться почтой, которая работает через интернет, а, по моему опыту, именно ради этого большинство и устанавливают такую схему на роутере — чтобы сохранить интернет при отключении контроллера домена/DNS. Это совпадает с твоим аргументом: «Так интернет продолжает работать, а это обычно важнее всего (особенно почта), даже если DC не доступен».

Я получаю все преимущества настройки Windows DNS/DHCP и при этом пользователи сохраняют доступ к интернету, если внутренний DNS перестаёт работать.

Gregg

bjeung

Guest

20.07.2018 17:59:00

Чтобы не повторяться, но есть много случаев, когда у вас в качестве DNS-серверов домена настроены не всегда именно DNS-серверы Active Directory, но при этом функционал AD DNS сохраняется:
- Рекомендованная Microsoft конфигурация для SBS/Essentials предполагала, что роутер выдаёт через DHCP DNS-серверы провайдера. Когда компьютер присоединялся к домену, на нём ставился небольшой агент, который, если обнаруживал, что контроллер домена работает, переключал DNS на контроллер, а если контроллер был офлайн — интернет при этом продолжал работать. Так интернет обычно остаётся доступным (особенно почта), даже если контроллер недоступен.
- Многие продукты по безопасности DNS, например Cisco Umbrella, имеют локальный агент, который «перехватывает» локальные DNS-запросы и перенаправляет определённые зоны (обычно AD) на назначенные интерфейсу DNS-серверы, либо используют виртуальные устройства, настроенные как предпочтительные DNS-серверы с условной переадресацией (похоже на то, что я писал ранее).
- Часто на небольших удалённых офисах, подключённых через VPN site-to-site, где нет смысла держать локальный контроллер домена, я настраиваю условную переадресацию так, чтобы DNS-запросы к AD шли через туннель, а остальное разрешалось локально.

Мой смысл в том, что использовать только AD DNS-серверы не обязательно. Главное — чтобы запросы к AD DNS попадали на соответствующие серверы, например, через условную переадресацию. И вы правы — если задать AD DNS как первичный, а остальные как вторичные, это не всегда надёжно и может вызывать проблемы.

greggmh123

Guest

20.07.2018 17:39:00

Это не так. Нужно просто уметь разрешать доменные запросы, связанные с AD. Конечно, самый простой способ — использовать DNS-серверы AD в качестве основных или единственных DNS-серверов, но можно настроить условную переадресацию на любом DNS-сервере, который используют участники домена, чтобы переадресовывать запросы по AD-домену на DNS-серверы AD.

@bjeung

Мой ответ был к сообщению прямо над моим, где он писал: «Разве нельзя иметь одновременно оба DNS включенными и просто настроить как первичный и вторичный DNS?» Нет, не стоит использовать одновременно и AD, и другие DNS-серверы как первичный и вторичный DNS. Да, можно сделать сложнее — например, настроить DNS на роутере с условной переадресацией на DNS-серверы AD, но это добавляет сложности без видимой пользы. Один парень на Spiceworks как раз поддержал твою точку зрения, но ему объяснили множество причин, почему этого не стоит делать. Во-первых, он сказал, что если контроллер домена упадёт, пользователи всё равно будут иметь доступ в интернет, а я указал, что если сломается его роутер, у пользователей вообще не будет доступа — ни в интернет, ни к AD DNS, потому что нечего будет переадресовывать условно. Мне нравится, когда DNS и DHCP работают на контроллерах домена, по причинам, уже озвученным @PublicName и ещё по многим другим. Например, я до сих пор не встречал роутера, чей DHCP-сервер мог бы создавать обратные записи DNS на контроллере Windows AD.

Gregg

bjeung

Guest

20.07.2018 05:14:00

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

greggmh123 Guest	#6 20.07.2018 04:55:00 В любой доменной сети Windows Active Directory единственным DNS-сервером, указанным в настройках сетевого адаптера рабочей станции или сервера, должен быть LAN DNS-сервер, например, ваш контроллер домена на Windows 2016. Cloud Key может использовать любой DNS, который вы захотите для собственных запросов... он не является участником домена и не обязан знать про Active Directory. Вы можете направить его на локальный Windows DNS-сервер, потому что если ему потребуется внешний DNS-запрос, сервер воспользуется своими переадресациями или корневыми серверами. Gregg

Читают тему (гостей: 1)