Глава 7. Управление сетевыми средами в вашей корпорации

Сердцевиной всякой организации выступает её сетевая среда - та инфраструктура, которая позволяет взаимодействовать вашим клиентам и серверным системам. Windows включила функциональные возможности сети начиная с самых ранних дней Windows for Workgroup 3.1 (и ранее при помощи Microsoft LAN Manager).

Не лишним будет отметить один момент: даже в эпоху облачных решений "сетевая среда" никуда не денется; её роль, состоящая в разрешении подключения некого клиента к серверу лишь изменяется при том, что некоторые из серверов (и клиентов) теперь пребывают в облачном решении. Такое облако по- существу всего лишь ресурсы в чьей- то сети и для взаимодействия вам всё ещё требуется сетевая среда.

Всякий сервер или рабочая станция в вашем окружении должны обладать правильной конфигурацией IP. В то время как IPv6 обретает свою популярность, большинство организаций полагаются на IPv4. В рецепте Настройка адресации IP мы взглянем на настройку конфигурации сетевого интерфейса IPv4, включая установки DNS.

Многие организации назначают большинству серверных систем некий статический IPv4. Все применяемые на протяжении этой книги серверы, к примеру, используют статическую адресацию IP. Для хостов клиентов и некоторых серверов альтернативой статическому IP адресу выступает применение DHCP (Dynamic Host Control Protocol, протокола динамической конфигурации хоста). DHCP это протокол сетевого управления, который делает возможным аренду некого IP адреса рабочей станции (и его высвобождении по истечению срока аренды). Вы настраиваете некий сервер DHCP на выпуск конфигураций IP адресов клиентам при помощи рецепта Установка DHCP.

После того как вы установили свой сервер DHCP, вы можете применять рецепт Настройка областей действия и параметров DHCP для установки тех деталей, при помощи которых ваш сервер DHCP должен обрабатывать своих клиентов. В рецепте Реализация отказоустойчивости DHCP и балансировки нагрузки мы развёртываем второй сервер DHCP и настраиваем его на работу в качестве службы DHCP отказоустойчивости/ балансировки нагрузки.

В заключительном рецепте этой главы, Управление зонами и записями ресурсов DNS вы настраиваете свой сервер DNS в DC1 зонами и дополнительными записями ресурсов. Прежде чем вы сможете выполнять администрирование своей инфраструктуры Windows Server 2022, вам потребуется создать некую среду для того чтобы PowerShell позаботился о таком администрировании.

По умолчанию Windows пользуется DHCP для настройки всех NIC, которые выявляет процесс установки Windows при установке Windows. После того как вы завершили установку своего Windows, вы можете воспользоваться его апплетом управляющей панели (ncpa.cpl), приложением консоли сетевой оболочки (netsh.exe) или, естественно, PowerShell для настройки конфигурации IP вручную. В данном рецепте вы установите подробности IP адресации для SRV2 и убедитесь что ваш хост зарегистрировал имена DNS в DNS домена Reskit.Org (в службе DNS, запущенной в DC1).

Настройка любого хоста требует установки IP адреса. маски подсети и шлюза по умолчанию, которые вы и выполняете в первой части данного рецепта. Затем вы настраиваете SRV2 (хост рабочей группы) на регистрацию в соответствующем сервере DNS в DC1.Reskit.Org. Такой подход таит некоторые проблемы. По умолчанию, когда вы создаёте DC1.Reskit.Org в качестве Контроллера домена, процесс активации этого домена устанавливает имеющуюся зону DNS этого домена как требующей обновления безопасности. Это подразумевает, что нет возможности регистрации хоста рабочей группы. Вы можете обойти это настроив соответствующую зону как допускающую любые обновления. Однако это может быть опасным, поскольку это делает возможным потенциально регистрировать свои адреса ВСЕМ хостам. Второй вызов состоит в том, что поскольку SRV2 не выступает участником домена, удалённое подключение к DC1 завершится отказом. Неким решением этой проблемы является настройка службы WinRM на доверие всем хостам. Настройка WinRM на игнорирование проверки подлинности сервера имеет последствия для безопасности, которые следует принимать во внимание, прежде чем применять такой подход в промышленной среде.

Данный рецепт пользуется SRV2, недавно добавленным хостом рабочей группы. Как и все прочие применяемые в этой книге хосты, вы устанавливаете SRV2 при помощи сценариев установки Reskit, которые вы можете найти на https://github.com/doctordns/ReskitBuildScripts. Вам также надлежит обладать загруженными PowerShell 7.1 и VSCode, как вы это выполнили в Главе 1, Установка и конфигурирование PowerShell 7. Для упрощения этой настройки вы можете исполнить два сценария установки из https://github.com/PacktPublishing/Windows-Server-Automation-with-PowerShell-7.1-Cookbook-Fourth-Edition/tree/main/goodies. Выполняйте первый сценарий в Windows PowerShell ISE, а второй в поднятом экземпляре VS Code.

Обратите внимание на то, что применение Azure для этих ВМ не поддерживается.

По умолчанию этот хост выступает клиентом DHCP.

На Шаге 1 вы пользуетесь Get-NetAdapter и Get-NetIPAddress для определения IP адреса данного сервера. Затем вы отображаете полученные в результате адреса, что выглядит примерно так:

На Шаге 2 вы применяете командлет New-NetIPAddress для установки статического IP адреса в SRV2. Вот как отображается вывод:

Чтобы дважды убедиться что вы настроили SRV2 с правильной конфигурацией IP адреса, вы можете воспользоваться командлетом Get-NetIPaddress cmdlet. Вот вывод на Шаге 3:

Помимо установки некого IP адреса, маски подсети и шлюза по умолчанию, вам также потребуется настроить SRV2 неким адресом сервера DNS. На Шаге 4 вы пользуетесь Set-DnsClientServerAddress, который не производит вывода.

Для проверки обновлённой конфигурации IP в SRV2, на Шаге 5 вы повторно пользуетесь командлетом Get-NetIPAddress со следующим выводом:

На Шаге 6 вы применяете Test-interconnection чтобы убедиться что SRV2 способен подключиться к DC1, Контроллеру домена в домене Reskit.Org с таким выводом:

Чтобы позволить SRV2, некому компьютеру рабочей группы, запускать команды в DC1, вам требуется исправить полномочия Windows. На Шаге 7, который не производит вывод, вы создаёте полномочия для пользователя Администратор в Reskit.Org.

На Шаге 8 вы настраиваете свою службу WinRM на доверие DC1 в явном виде.

На Шаге 9 вы выполняете повторную настройку своей службы DNS в DC1 чтобы допускать не безопасные обновления для своего домена Reskit.Org. На Шаге 10 вы настраиваете SRV2 на его регистрацию в зоне Reskit.Org в DC1. Затем, на Шаге 11, вы регистрируете IP адрес SRV2 внутри службы DNS в DC1. Эти два этапа не производят вывод.

На следующем Шаге 12 вы выполняете предварительную подготовку своего компьютера SRV2 в AD Reskit.Org. На этом этапе, который не производит вывод в консоли внутри имеющегося AD создаётся учётная запись SRV2. Это означает, что пользователь с низким уровнем полномочий теперь может добавить в свой домен SRV2. Кроме того, обратите внимание, что вы исполняете эту команду удалённо в DC1 - это обусловлено тем, что вы пока не добавили инструменты AD в SRV2.

На окончательном Шаге 13 вы запрашиваете у своей службы DNS разрешение установленного доменного имени, SRV2.Reskit.Org. Этот шаг производит следующий вывод:

В этом рецепте вы настраиваете сервер рабочей группы на наличие статического IP адреса. Вы также настраиваете службу DNS на разрешение SRV2 зарегистрировать запись DNS внутри домена Reskit.Org. В большинстве промышленных сценариев вы также будете присоединять SRV2 к своему домену и в таком случае регистрация DNS просто срабатывает без необходимости в Шагах с 7 по Шаг 11.

На Шаге 5 вы проверяете IP адрес SRV2. Этот тест не проверяет конфигурацию DNS SRV2. Для проверки также и адреса DNS, вы можете воспользоваться Get-NetIPConfiguration.

На Шаге 7 вы создаёте полномочия, которые позволяют вам исполнять команды в DC1. На этом шаге вы пользуетесь учётной записью Enterprise/Domain Administrator. В промышленной среде рекомендуется подход, при котором вы создаёте другого пользователя с неким подмножеством полномочий группы Enterprise Admin, а затем применяете такого пользователя чтобы выполнить Шаг 9.

На Шаге 8 вы настраиваете WinRM на доверительные отношения с сервером DNS, DC1. Такая конфигурация требуется для среды рабочей группы по той причине, что компьютерам рабочей группы не доверяют прочие серверы при использовании удалённого подключения PowerShell. По умолчанию, удалённое подключение PowerShell применяет взаимную аутентификацию. Kerberos осуществляет взаимную аутентификацию в среде домена, в то время как в среде рабочей группы для подключения к DC1 вы можете применять SSL. Настраивая SRV2 на доверительные отношения с DC1, вы отключаете аутентификацию DC1 в SRV2. В некой защищённой среде, подобной той, которая имеется у вас настроенной в серверах Reskit.Org, это допустимо. В промышленной среде и, в особенности, в крупном окружении, будет лучше для удалённого подключения к хосту включать SSL в отдельной сфере безопасности.

В современном мире подключений сетевые соединения жизненно важны. Когда вы добавляете некий новый сервер в свою инфраструктуру, полезно убедиться что этот сервер способен подключаться к сетевой среде и применять её.

В этом рецепте вы выполняете необходимые сетевые проверки подключений во вновь установленном хосте SRV2. Перед добавлением сервера в домен вы должны убедиться в наличии полной связности.

Этот рецепт пользуется SRV2, хостом рабочей группы. В предыдущем рецепте Настройка адресации IP вы получили для этого хоста статический IP адрес.

На Шаге 1 вы убеждаетесь что адаптер контура обратной петли SRV2 работает и что базовый стек TCP/IP поднят и работает. Вот вывод с этого шага:

На Шаге 2 при помощи приводимого ниже вывода вы убеждаетесь что порт WinRM открыт и работает:

В сетевой среде Reskit.Org имеется некий Контроллер домена и сервер DNS. На Шаге 3 вы проверяете соединение с этим критически важным корпоративным сервером с выводом, подобным приводимым ниже:

В любой среде домена хостам требуется доступ к совместному ресурсу SYSVOL в DC для выгрузки файлов .POL групповой политики. На Шаге 4 вы проверяете что SRV2 способен получать доступ к соответствующему порту 445 SMB в своём Контроллере домена со следующим выводом:

На Шаге 5 вы проверяете что SRV2 имеет возможность доступа к DC1 по порту LDAP, 389, что отражает следующий вывод:

На Шаге 6 вы проверяете подключение к Интернету и тестируете сетевой путь к вебсайту издательства www.packt.com. Вот что вы наблюдаете:

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

На Шаге 6 вы проверяете подключение к Интернету через вебсайт нашего издательства (www.packt.com). Поскольку мы всего лишь проверяем подключение к этой площадке, вам требуется предписать лишь реальное название компьютера и нет необходимости в префиксе HTTP или HTTPS.

В предыдущих рецептах вы настраивали SRV2 со статическим IP адресом и проверяли его подключение. Всякому серверу требуется некий уникальный IP адрес и прочие параметры конфигурации для настроек на основе в=сервер- к- серверу. Вы также можете настраивать компьютеры клиентов под управлением Windows 10 или прочих ОС вручную, хотя в крупной организации это может быть гигантской задачей с большими проблемами.

DHCP (Dynamic Host Control Protocol, протокола динамической конфигурации хоста) позволяет клиентам DHCP получать их конфигурации IP и прочие сетевые подробности автоматически от сервера DHCP. DHCP автоматизирует настройку IP и избегает необходимой работы и неизбежных проблем с конфигурированием IP вручную.

Windows и большинство прочих операционных систем клиентов, включая Linux и Apple Macs обладают встроенными клиентами DHCP. Windows Server также содержит службу сервера DHCP, которую вы можете устанавливать для предоставления служб DHCP своим клиентам. Вы можете установить DHCP при помощи Диспетчера Сервера и настроить соответствующую службу при помощи GUI приложения DHCP. В качестве альтернативы вы способны автоматизировать такую установку DHCP, как вы обнаружите это в данном рецепте. В нашем следующем рецепте, Настройка областей действия и параметров DHCP, вы настроите свою службу DHCP на выпуск IP адресов в неком конкретном диапазоне. Вы также сконфигурируете DHCP для предоставления клиентам DHCP прочих параметров конфигурации IP, таких как маска подсети, шлюз по умолчанию и IP адрес или адреса DNS сервера.

Данный рецепт применяет DC1, контроллер домена в нашем домене Reskit.Org. Вы должны обладает установленным AD в этом хосте и настроить его как в более ранних рецептах из Главы 5, Изучаем .NET и Главы 6, Управляем Active Directory.

На Шаге 1 вы импортируете модуль ServerManager и применяете Install-WindowsFeature для добавления службы сервера DHCP в DC1. Вот вывод с этого шага:

На Шаге 2 вы добавляете некий набор авторизованных серверов DHCP в свой домен и добавляете группы безопасности DHCP в свой сервер DHCP, что не предоставляет вывода на консоли. Те группы, которые добавляет эта команда, это группы безопасности DHCP Users и DHCP Administrators. Для получения дополнительных сведений относительно этих групп отправляем вас к https://secureidentity.se/delegate-dhcp-admins-in-the-domain/.

На Шаге 3 вы настраиваете запись реестра чтобы сообщить Windows что все активности после развёртывания DHCP выполнены. Процесс графического интерфейса выполняет это автоматически. При установке через PowerShell вам требуется настроить эту запись реестра для завершения конфигурирования.

Когда вы завершили действия по конфигурированию, вы перезапускаете свою службу DHCP. Будучи запущенной повторно, эта служба DHCP способна испускать конфигурации IP клиентам DHCP. Чтобы это происходило, вы должны обладать предписанными сведениями о конфигурации, которые вы определяете в следующем рецепте Настройка областей действия и параметров DHCP. Шаг 2, Шаг 3 и Шаг 4 не производят никакого вывода.

На Шаге 5 вы завершаете данный рецепт, убеждаясь что ваша служба DHCP стартовала. Вот вывод с этого шага:

После запуска службы DHCP Windwos, она проверяет что её сервер пребывает в списке авторизованных серверов DHCP в вашем домене. Такая служба DHCP не запускается ни в каком сервере DHCP без авторизации. Добавление DC1 в список авторизованных серверов может помочь охране против мошеннических серверов DHCP.

На Шаге 5 вы проверяете службу DHCP. Получаемый из Get-Service вывод содержит некое описание самой службы и значение названия пути к исполняемой службе. Служба DHCP не запускается в своём собственном процессе. Вместо этого она исполняется внутри svchost.exe. Именно по этой причине вы не наблюдаете такую службу в в явном виде когда пользуетесь Get-Service.

Как вы могли наблюдать в рецепте Установка DHCP, установка DHCP выполняется просто. Вы добавляете компонент Windows и затем приводите в исполнение два небольших шага конфигурирования. В большинстве случаев вам, скорее всего, не понадобится предпринимать дополнительные шаги. Такие дополнительные шаги позволяют вам применять подходящие группы безопасности и избегать появления сообщения графического интерфейса Диспетчера Сервера о том, что имеются ещё шаги настройки, которые ещё не были выполнены.

Прежде чем ваш сервер DHCP сможет предоставлять сведения конфигурации IP клиентам DHCP, вам требуется создать сферу действия DHCP и параметров DHCP. Сфера действия DHCP это некий диапазон адресов, который ваш сервер DHCP способен выдавать для некого заданной подсети IP. Параметры DHCP это особые параметры конфигурации, которые предоставляет ваш сервер DHCP, такие как IP адрес вашего сервера DNS и шлюз по умолчанию IPv4.

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

В данном рецепте вы создаёте новую сферу действий для подсети 10.10.10.0/24 и определяете и сферу и параметры уровня сервера.

Вы исполняете этот рецепт в DC1, Контроллере домена в домене Reskit.Org, после установки соответствующей службы DHCP сервера. Вы должны иметь в этом хосте установленными PowerShell 7 и VS Code.

На Шаге 1 вы импортируете модуль DHCPServer. Когда вы установили DHCP (в рецепте Установка DHCP), вы импортировали необходимые инструменты управления, включая это модуль. Тем не менее, команда DHCP ещё не превратила этот модуль в совместимый с PowerShell 7. Этот не производящий вывода шаг загружает данный модуль при помощи решения Совместимости Windows PowerShell. Вы прочли о решении Совместимости Windows PowerShell в Главе 3, Изучаем совместимость с Windows PowerShell.

На Шаге 2 вы создали новую область действия DHCP для адресов IPv4. Эта область действия позволяет серверу DHCP выпускать адреса IP в диапазоне 10.10.10.150 - 10.10.10.199. Этот шаг не производит вывод.

На Шаге 3 вы применяете Get-DHCPServerIPV4Scope для выборки подробностей всех областей DHCP, которые вы определили в DC1. Вывод этого шага выглядит примерно так:

На Шаге 4 вы устанавливаете два параметра DHCP для серверов, что не производит вывод. Это параметры и значения, которые предлагаются всем клиентам любой определённой в этом сервере области DHCP. На Шаге 5 вы определяете параметр области действия. Эти два шага не производят вывод.

На Шаге 6 вы просматриваете параметры DHCP для всех серверов и вот как это выглядит:

На Шаге 7 вы просматриваете те параметры, которые вы настроили для области 10.10.10.10 что выглядит так:

Имеется 66 параметров DHCP, которые вы можете применять для предоставления значений параметров клиентам DHCP. Большинство этих параметров слабо применяются в большинстве вариантов, но предоставляют поддержку для нишевых и необычных вариантов. Вы просматриваете определяемые по умолчанию параметры на Шаге 8, что отображено ниже:

На Шаге 2 вы создаёте новую область действия и предоставляете ей название области действия. Тем не менее, как вы можете видеть на Шаге 5 и где- то в иных местах, имеющиеся командлеты DHCP не предоставляют параметра -DHCPScopeName. Вместо этого вы определяете ScopeID. В целом, именно это та подсеть, которая применяется в этой области действий для адресов IP, 10.10.10.0/24. Но даже там, как вы можете наблюдать на Шаге 7, этот командлет принимает любой адрес IP из подсети 10.10.10.0/24 в качестве идентификатора соответствующей подсети, включая, как показано, 10.10.10.10.

После установки службы DHCP и настройки соответствующей области (областей) действия и значений параметров, ваши службы DHCP способны выпускать данные конфигурации IP любым клиентам. Поскольку протокол DHCP действует на уровне IP, этот протокол не осуществляет аутентификации когда любой клиент DHCP применяет этот протокол для запросов подробностей конфигурации IP. Это означает, что всякий клиент, которого вы подключаете к физической подсети способен запрашивать и получать подробности подтверждения IP.

В рецепте Настройка адресации IP вы настроили статический IP адрес для SRV2. В этом рецепте вы повторно настраиваете этот сервер для получения IP адресов на основе DHCP (а также те параметры, которые вы настроили в рецепте Настройка областей действия и параметров DHCP).

Вы исполняете это рецепт в SRV2, который вы повторно настроили и получили его адреса через DHCP. Вам также требуется DC1, Контроллер домена для домена Reskit.Org и сервера DHCP, который вы установили и настроили в более ранних рецептах из этой главы.

На Шаге 1 вы устанавливаете компонент RSAT-DHCP для добавления модуля PowerShell сервера DHCP в SRV1 со следующим выводом:

Этот модуль сервера DHCP не совместим с .NET Core. На Шаге 2 вы в явном виде загружаете этот модуль при помощи Import-Module, который не производит вывод.

На Шаге 3 вы просматриваете доступную в DC1 область действия (том сервере DHCP, который вы установили в рецепте Установка DHCP). Вот вывод с этого шага:

На Шаге 4 вы изучаете статистики имеющейся области действия для той области действия DHCP, которую вы создали в рецепте Настройка областей действия и параметров DHCP, который производит такой вывод:

На Шаге 5 вы пользуетесь командлетом Get-DhcpServerv4FreeIPAddress для поиска первого доступного IP адреса в нашей области действия. Получаемый выход походит на такое:

На Шаге 6 вы получаете установленные подробности NIC и сохраняете в своей переменной $NIC, не производя вывода. Обратите внимание что вы определили InterfaceIndex как 6, который должен быть NIC вашей ВМ.

На Шаге 7 вы пользуетесь этой переменной для получения всех подробностей вашей NIC со следующим выводом:

На Шаге 8 вы изменяете свой NIC для получения подробностей конфигурации из своего сервера DHCP. Этот шаг не производит вывод. На Шаге 9 вы просматриваете значение IPv4 адреса NIC; на этот раз он назначается DHCP. Вот его вывод:

На Шаге 10 вы повторно изучаете статистики области действия со следующим выводом:

На Шаге 11 вы повторно проверяете и выявляете следующий свободный IP адрес в области действия DHCP со следующим выводом:

На заключительном Шаге 12 вы проверяете что SRV2 зарегистрировал свой новый IP адрес в установленном сервере DNS в DC1. Вот получаемый вывод:

В этом рецепте вы применяете командлеты DHCP сервера для получения сведений от своего сервера DHCP в DC1. Эти командлеты отображают как вы можете получать сведения от своего сервера DHCP, включая следующий свободный адрес IP и статистики в его области действий (свободные/ применяемые адреса и прочее).

Шаге 6 вы получаете значения сетевой конфигурации для своего NIC с InterfaceIndex равным 6. В некоторых случаях вы можете обнаруживать, что Windows назначал различный индекс интерфейса для вашей NIC. В качестве альтернативы вы можете применять параметр -InterfaceAlias для определения значения названия вашего интерфейса.

Шаге 7 вы получаете подробности доступного вам IP интерфейса, на Шаге 8, для преобразования установок NIC со статичного IP адреса на динамический на основе DHCP.

Шаге 9 вы просматриваете поставляемые DHCP сведения по адресу IP для SRV2. Если вы выполняете Шаг 8 сразу после Шага 9, вы можете обнаружить, что ваша NIC отображает IP адрес APIPA (Automatic Private IP Addressing, автоматической частной IP адресации) из подсети 169.254.0.0/24. Этот адрес краткосрочен. Как вы изменяете на DHCP (сто вы сделали на Шаге 8), Windows удаляет настроенный статический адрес и создаёт адрес APIPA. После того как SRV2 контактирует со своим DHCP сервером и договаривается о неком адресе, вы наблюдаете вывод с Шага 9 как на Рисунке 7-24. Получение выделения может занять несколько секунд, не торопитесь.

Как показано в наших двух предыдущих рецептах, установка и настройка отдельного сервера DHCP по запросу является простой. Тем не менее, единственный сервер DHCP представляет единственную точку отказа, что никогда не является хорошим моментом. Решение состоит в том, чтобы всегда был второй сервер DHCP. В более ранних версиях Windows вы могли выполнять это при помощи двух серверов DHCP, причём каждый со своей областью действия. Обычно вы пользуетесь расщеплением своего полного набора IP адресов и позволяете каждому серверу обладать частью этого набора. Традиционная "мудрость" состояла в том чтобы выполнять расщепление 80/20 - иметь 80% от общей предоставляемой области вашим первичным сервером DHCP и 20% сервером резервного копирования.

Независимые серверы DHCP являются подверженным ошибкам подходом и никогда не был идеальным, поскольку эти независимые серверы не координируют подробности областей действий. Такое 80/20 "правило" было рекомендовано для одного конкретного сценария пользователя (крупной фирмы на Тихоокеанском Северо-Западе) и возможно не предназначалось чтобы превратиться в рекомендацию.

В Windows Server 2012, Microsoft добавил механизм отказоустойчивости и балансировки нагрузки DHCP, который упрощает развёртывание DHCP в некой организации. Теперь вы можете настраивать два сервера DHCP, определять некую область действия DHCP и позволить обоим серверам работать в тандеме.

В этом рецепте вы устанавливаете DHCP, второй сервер, DC2 и затем настраиваете возможности отказоустойчивости и балансировки нагрузки Windows Server.

Этот рецепт пользуется двумя установленными вами Контроллерами домена, DC1 и DC2. Вы должны также обладать установленными DHCP и DNS (Установка DHCP) и настроенной некую зону DNS. (Настройка областей действия и параметров DHCP). Вы выполняете этот рецепт в DC2.

При помощи первых трёх шагов из этого рецепта вы устанавливаете компонент сервера DHCP в DC2. Эти шаги дублируют тот подход, которым мы пользовались в Установка DHCP для установки DC1.

На Шаге 1 вы импортируете модуль ServerManager и затем устанавливаете компонент DHCP со следующим выводом:

На Шаге 2 вы устанавливаете ключ реестра для сообщения Windows что вы завершили установку компонента DHCP. Без этого шага всякий раз когда вы будете применять в DC2 графический интерфейс Диспетчера Сервера, вы будете наблюдать сообщение, указывающее что требуется дополнительная настройка. Данный шаг не производит вывод.

На Шаге 3 вы импортируете модуль PowerShell своего сервера DHCP и добавляете DC2 в свой перечень авторизованных серверов в домене Reskit. Этот шаг также не производит вывод.

На Шаге 4 вы изучаете свой набор авторизованных серверов DHCP, что производит такой вывод:

На Шаге 5 вы настраиваете балансировку нагрузки и отказоустойчивость DHCP с таким выводом:

На Шаге 6 вы ищучаете области действия обоих серверов DHCP с приводимым ниже выводом:

На Шаге 7 вы просматриваете статистики своего сервера DHCP со своих двух серверов со следующим выводом:

В отличии от рецепта Установка DHCP, в этом рецепте вы не добавляете в DC2 относящиеся к DHCP группы безопасности. Если вы планируете делегировать административные полномочия, вы можете пожелать добавлять эти группы, как вы это делали в предыдущем рецепте.

На Шаге 5 вы устанавливаете взаимосвязь балансировки нагрузки и отказоустойчивости между своими двумя серверами DHCP. При помощи переключателя -Verbose для командлета Add-DhcpServerV4Failover, вы можете в точности наблюдать что выполняет эта команда, шаг за шагом. Как вы можете наблюдать в выводе на Рисунке 7-30, эта команда копирует все подробности всех областей действия из DC1 в DC2. Вы должны обратить внимание, что это взаимодействие зависят от области действия.

В зависимости от ваших потребностей вы способны настраивать различные виды взаимодействия между серверами DHCP при помощи параметра -ServerRole. Для получения дополнительных сведений относительно этого и прочих параметров, которые вы можете применять для тонкой настройки взаимодействия между такими двумя партнёрами отсылаем вас к https://docs.microsoft.com/powershell/module/dhcpserver/add-dhcpserverv4failover.

Компонент отказоустойчивости DHCP предоставляет некоторые дополнительные настройки для точного управления в случае отработки отказа и как долго (и когда) его выполнять. Эти настройки позволяют вам управлять, к примеру тем, что может происходить в процессе планируемого перезапуска вашего сервера DHCP.

Когда вы устанавливали Active Directory в Главе 6, Управляем Active Directory, вы добавили отдельный сервер DNS в DC1. Когда вы добавляли Контроллер домена реплики, DC2 и когда вы добавляли при помощи UKDC1 дочерний домен, мы не устанавливали никаких дополнительных серверов DNS в своём Лесу. В некой корпоративной организации это не совсем то что рекомендуется. Вы всегда желаете настраивать своих клиентов и серверы так, чтобы они пользовались по крайней мере двумя серверами DNS. Для серверов со статическими настройками DNS вам также надлежит обновлять настройки параметров DHCP сервера DNS для обеспечения того, что ваши серверы DHCP также предоставляют две записи сервера DNS клиентам DHCP.

В большинстве организаций имеются различные параметры настроек службы DNS, который вы бы могли пожелать настроить. Они включают будете ли вы допускать рекурсию сервера DNS в своём сервере, максимальный размер значения кэша DNS и будет ли применяться Extended DNS (EDNS).

EDNS (также именуемый как EDNS0 или, в последнее время, EDNS(0)) это некий механизм расширения, который позволяет более последним серверам DNS взаимодействовать с более старыми серверами, которые могут оказываться не совместимыми с определёнными действиями. Для дополнительных сведений по EDNS(0) обращайтесь к https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS.

Этот рецепт является некой отправной точкой. Существуют и прочие параметры сервера DNS, которые вы бы могли пожелать рассмотреть для их обновления, например, безопасность DNS. Кроме того, вам может потребоваться повторная настройка прочих серверов и обновление статических настроек IP адресов (чтобы указывать на оба сервера DNS). И, наконец, в вашем Лесу Reskit.Org вам также следует обновить свой дочерний домен UK.Reskit.Org.

В данном рецепте вы обновляете настройки DNS всего домена для домена Reskit.Org. Эти настройки обеспечивают что вы настроили службу DNS DC2 точно также как и в DC1, обновили установки конфигурации сервера DNS, настроили и DC1, и DC2 чтобы они указывали на верные DNS серверы, а также обновляли DHCP для решения проблем адресации с обоими серверами DNS. Затем вы исследуете эти установки DNS.

В рецепте Настройка адресации IP вы настроили SRV2, хост рабочей группы на обновление DNS. Вы настроили в DC1 зону Reskit.Org чтобы допускать не участвующим в домене обновлять их регистрации DNS при помощи динамического DNS. Такая конфигурация не рекомендуется. В заключительных этапах данного рецепта вы обновляете имеющиеся зоны DNS для Reskit.Org чтобы допускать только безопасные обновления и присоедините SRV2 к домену Reskit.Org со статическим IP адресом.

Вы исполняете этот рецепт в DC2 при том что DC1 и SRV2 также работают. Вы запускаете этот рецепт после настройки DNS и в DC1, и в DC2, а также после реализации DHCP.

На Шаге 1 вы установили в DC2 со следующим выводом:

На Шаге 2 вы создаёте блок сценария, который содержит параметры вашего сервера DNS. На Шаге 3 вы исполняете этот блок и в DC1, и в DC2. На Шаге 4 вы создаёте блок сценария для применения его для установок IP конфигурации в DC2. На Шаге 5 вы выполняете этот блок сценария для повторной настройки DC2. На Шаге 6 и на Шаге 7 вы повторно настраиваете установки статического IP в DC1. На Шаге 8 вы обновляете свой параметры DHCP своего сервера DHCP чтобы они обеспечивали поддержку в ваших обоих серверах DHCP адресов IP двух серверов DNS для клиентов или для сервера DHCP. Эти этапы не производят вывод.

На Шаге 9 вы получаете подробности сервера DNS из DC2, что не вырабатывает вывод. На Шаге 10 вы изучаете настройки рекурсии своего сервера DNS со следующим выводом:

На Шаге 11 вы изучаете установки кэширования сервера DNS в DC2 с приводимым далее выводом:

На Шаге 12 вы просматриваете установки EDNS в DC2, что выводит следующее:

На Шаге 13 вы изменяете домен dNS для Reskit.Org с тем, чтобы он принимал бы только безопасные динамические обновления в обоих серверах DNS в этом домене.

На окончательном Шаге 14 этого рецепта вы добавляете SRV2 в свой домен Reskit.Org. Этот шаг не производит вывод.

В этом рецепте вы установили и настроили DNS в DC2. Вы также установили параметры сервера DNS в обоих серверах DNS (DC1 и DC2). На Шаге 5 и на Шаге 7 вы настроили свои Контроллеры домена так, чтобы они указывали сначала сами на себя, и далее, вторым, на прочие серверы DNS. Рекомендуется именно такая настройка DNS.

В одном из предыдущих рецептов вы настраивали свои сервера DHCP с тем, чтобы они предоставляли единственный IP адрес клиентам DHCP. На Шаге 8 вы обновляете DHCP с тем, чтобы он предоставлял два IP адреса серверов DNS.

Затем вы получаете и просматриваете рекурсию своего DNS сервера, кэширование сервера и установки EDNS в DC2. Вы можете расширить эти шаги изучением всех установок в DC2 и их сопоставлением чтобы гарантировать согласованность конфигурации.

В рецепте Настройка адресации IP вы пользовались компьютером рабочей группы, SRV2 и дозволяли ему регистрироваться в DNS настраивая свой домен принимать не безопасные обновления. Применение не безопасных обновлений не рекомендуется, поскольку это позволяет какому- то компьютеру злоумышленника "воровать" реальное имя DNS. На Шаге 13 вы обеспечиваете что домен DNS Reskit.Org допускает только безопасные обновления. Затем, на Шаге 14 и на Шаге 15 вы добавляете SRV2 в свой домен. На протяжении всей оставшейся книги, SRV2 это присоединённый к домену компьютер, а не система из рабочей группы. Эти три последних шага не производят вывод.

В этом рецепте вы настроили DNS на применение в своём домене Reskit.Org. Вы не вносили никаких изменений в отношении подчинённого домена UK.Reskit.Org. В промышленной среде вы бы пожелали, по крайней мере, чтобы вашему второму Контроллеру домена не приходилось бы обновлять установки адреса вашего сервера DNS для серверов в вашем домене UK.

Другая сторона промышленного применения относится к репликации доменов. В этой главе вы создали зону DNS для Reskit.Org. Использованный вами рецепт настроил этот домен как интегрированный в AD и подлежащий репликации во все Контроллеры домена в вашем Лесу Reskit.Org. Это означает, что все изменения сервера DNS для домена Reskit.Org автоматически реплицируются в UKDC1. В зависимости от применяемого вами сценария вы можете пожелать выровнять сферу репликации своей зоны для интегрированных в AD зон.

Когда некий сервер DNS получает запрос на RR (resource record), не хранящийся самим сервером, он может применять рекурсию для обнаружения сервера DNS, который способен разрешить такой RR. Если, например, вы пользуетесь Resolve-DNSName для разрешения www.packt.com, ваш настроенный сервер может не содержать зону, которая могла бы вам помочь. Затем ваша служба DNS просматривает свои корневые серверы DNS для выявления сервера DNS, который сможет это выполнить через процесс рекурсии. В конечном итоге, этот процесс находит сервер DNS, который способен разрешить такой RR. Затем ваш сервер DNS кэширует эти подробности локально в кэше вашего сервера DNS.

Когда вы разрешаете публично доступные имена, этот процесс работает великолепно. Однако вы можете обладать поддерживаемые внутренне имена DNS, которые такой DNS не способен разрешать через данный механизм. Неким примером может служить слияние двух компаний. Они могут обладать внутренними именами хостов (например, intranet.kapoho.com и intranet.reskit.org), которые способны разрешать ваши внутренние серверы DNS, но они не доступны в развёрнутых в публичное пространство серверах DNS. В такой ситуации вы можете настроить условную переадресацию (conditional forwarding). Условная переадресация позволяет одному серверу DNS перенаправлять некий запрос в другой сервер DNS или набор серверов и не применять рекурсию. Вы можете слегка больше узнать об условной переадресации в https://medium.com/tech-jobs-academy/dns-forwarding-and-conditional-forwarding-f3118bc93984.

Альтернативой применению условной переадресации является применение зон заглушек. Вы можете узнать дополнительно о различиях между условной переадресацией и зонами заглушек здесь: https://blogs.msmvps.com/acefekay/2018/03/20/what-should-i-use-a-stub-conditional-forwader-forwarder-or-secondary-zone/.

В этом рецепте вы пользуетесь DC1, Контроллером домена и сервером DNS для Reskit.Org. Вы ранее активировали DC1в качестве Контроллера домена и установили/ настроили DNS следуя приведённым ранее в этой главе и в книге.

На Шаге 1 вы разрешаете серверы имён, обслуживающие домен packt.com в Интернете и затем вы отображаете полученные результаты:

На Шаге 2 вы пользуетесь только что полученными серверами и разрешаете их IPv4 адреса из их имён хостов (которые получены на Шаге 1). На этом шаге производится такой вывод:

На Шаге 3, который не производит вывод, вы создаёте зону переалресации DNS для packt.com, который вы наполняете IP адресами, возвращёнными на Шаге 2.

На Шаге 4 вы просматриваете домен условной переадресации, определённый в DC1 с выводом, подобным следующему:

На окончательном Шаге 5 вы разрешаете www.packt.com, что возвращает и адреса IPv4, и адреса IPv6, подобно следующему:

На Шаге 1 вы обнаруживаете названия серверов имён для тех серверов DNS, которые обслуживают packt.com. В этом случае такие серверы выступают частью распределённой службы DNS Cloudflare. Для получения дополнительных сведений о том как работает эта служба, обращайтесь к https://www.cloudflare.com/dns/.

На Шаге 2 вы разрешаете имена этих серверов DNS в IP адреса. На Шаге 3 вы создаёте некий домен условной переадресации, который перенаправляет запросы для packt.com (например, www.packt.com) в один из шести IP адресов, которые вы наблюдаете на Шаге 2.

На Шаге 4 вы просматриваете установленную в DC1 зону условной переадресации. Поскольку эта зона не интегрирована в DNS, DNS не реплицирует её в DC2. В промышленной среде вам следует повторять Шаг 3 в DC2.

На Шаге 5 вы разрешаете www.packt.com через условную переадресацию. Поскольку обнаруженные вами серверы имён поддерживают записи адресов IPv6, этот шаг возвращает и адреса IPv4, и адреса IPv6. Когда вы пребываете в среде, которая поддерживает IPv6, вам следует изменить Шаг 2 с тем, чтобы он возвращал полученные адреса IPv4 и IPv6, а затем воспользоваться ими на Шаге 3.

Ваша служба DNS позволяет вам разрешать имена в прочие сведения. Большинство применений DNS разрешает некое имя хоста в их адреса IP (IPv4 и IPv6). Однако имеются прочие разрешения, такие как определение серверов электронной почты или для антиспама, которые также полагаются на DNS.

Серверы DNS содержат зоны. Некая зона DNS это контейнер для набора RR, полагающегося на конкретный домен DNS. Когда вы вводите www.packt.com, ваш браузер применяет DNS для разрешения такого названия вебсайта в некий IP адрес и взаимодействует с сервером по этому IP адресу. Когда вы пользуетесь для отправки почты клиентом электронной почты, например, к DoctorDNS@Gmail.Com, соответствующий клиент применяет DNS для выявления сервера электронной почты, к которому отправлять эту почту.

Прежде чем вы сможете применять DNS для содержания RR, вы обязаны вначале создать некую зону просмотра переадресации DNS. Зона это одна часть общего глобального (или внутреннего) пространства имён DNS. Вы можете настраивать различные зоны для содержания различных частей своего пространства имён. В Главе 6, Управляем Active Directory вы добавили некий дочерний домен в Лесу Reskit.Org, UK.Reskit.Org. Вы моете, например, обладать одной зоной содержащей RR для Reskit.Org в DC1 и DC2, в то время как для UKDC1 делегируется новая зона, UK.Reskit.Org.

Зона обратного просмотра это выполняющая обратное зона - вы пользуетесь ею для получения имени хоста из его IP адреса. Вы можете найти полезные зоны обратного просмотра, но они не нужны вам в большинстве случаев применения домена. Для дополнительных подробностей по DNS в Windows обращайтесь к https://docs.microsoft.com/windows-server/networking/dns/dns-top.

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

В Windows 2000 Microsoft добавил интегрированные с AD зоны. DNS хранит данные DNS для этих типов зон внутри AD. Эти зоны реплицируют данные своей зоны через репликацию AD, что упрощает всю установку. Это также означает, что когда вы создали свою службу AD в DC1, DNS создаёт зону в своём сервере DNS в DC1 и реплицирует данные этой зоны во все Контроллеры домена в своём Лесу. Для получения дополнительных сведений по интегрированным в AD зонам обращайтесь к https://docs.microsoft.com/windows-server/identity/ad-ds/plan/active-directory-integrated-dns-zones.

В этом рецепте вы создаёте некое перенаправление DNS и зону обратного просмотра, а затем создаёте в этих зонах RR. После добавления вы проверяете разрешение DNS.

Вы выполняете этот рецепт в DC1, однако вам требуются и DC1, и DC2. Вы установили DNS в обоих серверах и, сделав это, вы создаёте единую зону прямого просмотра для леса Reskit.Org.

На Шаге 1, который вы исполняете в DC1, вы создаёте новую первичную зону DNS прямого просмотра для домена DNS Cookham.Net. На Шаге 2 вы создаёте первичную зону обратного просмотра для 10.10.10.0/24. На Шаге 3 вы исполняете Register-DNSClient и в DC1, и в DC2. Это обеспечивает что оба Контроллера домена обновили свои подробности DNS. Эти три шага не производят вывода в консоли.

На Шаге 4 вы проверяет зоны DNS, содержащиеся вашей службой DNS в DC1. Вот вывод с этого шага:

На Шаге 5 вы добавляете три RR для Cookham.Net: запись A, запись CNAME и запись MX. На Шаге 6 вы перезапускаете свою службу DNS и в DC1, и в DC2 чтобы гарантировать современность обеспеченности репликациями обоих серверов DNS. Эти два шага не вырабатывают вывод.

На Шаге 7 вы получаете все записи ресурсов DNS для Cookham.Net, что выглядит так:

На Шаге 8 вы проверяете разрешение имён из DC1 и DC2. Вначале вы разрешаете CNAME RR Mail.Cookham.Net из DC1, затем проверяете запись MX из DC2. Вывод этих команд приводится ниже:

На Шаге 9 вы проверяете имеющуюся зону обратного просмотра и разрешаете 10.10.10.10 в доменное имя подобно следующему:

На Шаге 5 вы создаёте некоторые новые RR для зоны Cookham.Net, которые вы проверяете на последующих шагах. Чтобы обеспечить что AD и DNS реплицируют эти новые RR (записи ресурсов) из, в данном случае, DC1 и DC2, на Шаге 6 вы перезапускаете свои службы DNS в обоих Контроллерах домена. Перезапуск этих служб DNS обеспечивает репликацию между имеющимися службами DNS.