Поэтапное переключение нагрузки на контроллеры Эллес с использованием технологии Split DNS

Для минимизации рисков при внедрении Эллес переключение существующих у клиента информационных систем (ИС) на работу с новыми контроллерами домена может выполняться поэтапно.

В этом случае к новым контроллерам домена обращается только часть ИС. Например, на Рис. 1 ИС №2 работает со всеми контроллерами, включая Эллес, тогда как ИС №1 продолжает работать только с контроллерами под управлением Microsoft Active Directory Domain Services на ОС Windows Server (Windows AD DS).

split dns overview
Рис. 1. Общая схема поэтапного переключения нагрузки

Одним из способов организации поэтапного перехода ИС клиента на работу с контроллерами домена Эллес является использование возможностей технологии Split DNS.

Общий подход к переключению нагрузки

Перед вводом в существующий домен клиента контроллера Эллес выполняется настройка DNS следующим образом:

  • все ИС клиента при обращении к DNS получают IP-адреса только контроллеров Windows AD DS, что исключает возможность обращения к контроллеру Эллес;

  • определенные, выбранные для тестирования ИС при обращении к DNS получают IP-адрес контроллера Эллес и могут обращаться к нему.

Для обеспечения такой настройки может использоваться режим Split DNS, который поддерживается как DNS-сервером Microsoft (MS DNS), используемым на серверах под управлением ОС Windows Server (см. описание доступных возможностей в официальной документации Microsoft), так и DNS-сервером BIND 9, развертываемым вместе с Эллес на серверах под управлением ОС Linux (см. описание настройки в официальной документации BIND 9).

В качестве примера рассмотрим домен со следующими параметрами (Рис. 2):

  • до ввода контроллеров Эллес в домене присутствуют контроллеры wdc1 и wdc2 под управлением AD DS с развернутыми MS DNS;

  • в качестве DNS-серверов в сетевых настройках всех компьютеров указаны IP-адреса этих двух контроллеров;

  • в основной зоне домена IP-адреса контроллеров указаны и как A-записи с именами контроллеров (wdc1, wdc2), и как A-записи верхнего уровня (@):

    @ A 10.0.18.61
@ A 10.0.18.62
wdc1 A 10.0.18.61
wdc2 A 10.0.18.62
split dns inno local before
Рис. 2. Домен inno.local до ввода контроллеров Эллес

После ввода в домен inno.local контроллеров Эллес (ldc1, ldc2 на Рис. 3) добавляются соответствующие записи в DNS:

@ A 10.0.18.61
@ A 10.0.18.62
@ A 10.0.18.65
@ A 10.0.18.68
wdc1 A 10.0.18.61
wdc2 A 10.0.18.62
ldc1 A 10.0.18.65
ldc2 A 10.0.18.68
split dns inno local after
Рис. 3. Домен inno.local после ввода контроллеров Эллес

Изолирование контроллеров Эллес

Чтобы изолировать контроллеры Эллес, необходимо:

  • удалить A-записи верхнего уровня, так как некоторые системы запрашивают все A-записи верхнего уровня при поиске домена;

  • в A-записях контроллеров Эллес IP-адреса заменить IP-адресами контроллеров Windows AD DS.

В этом случае в основной зоне домена IP-адреса контроллеров будут указаны следующим образом:

@ A 10.0.18.61
@ A 10.0.18.62
wdc1 A 10.0.18.61
wdc2 A 10.0.18.62
ldc1 A 10.0.18.61
ldc2 A 10.0.18.62

После этого любая система при обращении с DNS-запросом по имени верхнего уровня (inno.local) получит только IP-адреса контроллеров Windows AD DS (wdc1, wdc2).

При попытке получить IP-адрес контроллера Эллес (например, при обработке SRV-записей) будет возвращен адрес контроллера Windows AD DS.

Между собой контроллеры домена (как Windows AD DS, так и Эллес) должны взаимодействовать с использованием реальных IP-адресов — подмена может привести к непредсказуемым последствиям. Для защиты от возможных проблем следует указать реальные IP-адреса контроллеров Эллес в файле hosts на всех контроллерах домена и/или использовать возможности Split DNS, как описано ниже.

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

Вместо редактирования вручную может использоваться технология Split DNS.

Для настройки Split DNS необходимо выполнить следующую последовательность шагов:

  1. Создать для зоны дополнительную область (в примере — winscope).

  2. В дополнительной области создать A-записи верхнего уровня и контроллеров Эллес, указав для контроллеров Эллес адреса подменяющих их контроллеров Windows AD DS.

  3. Создать клиентскую подсеть (или несколько подсетей) контроллеров домена (в примере — 10.0.18.61/32 с именем WDC1Net, 10.0.18.62/32 с именем WDC2Net и т. д.).

  4. Создать политику, согласно которой все клиенты, кроме контроллеров, при запросе A-записей верхнего уровня и A-записей контроллеров Эллес получали бы ответ из дополнительной области (в примере — ws1 при запросе A-записи для имени ldc1.inno.local должен получить IP-адрес 10.0.18.61, а при запросе A-записи для имени inno.local — список, состоящий из IP-адресов 10.0.18.61, 10.0.18.62).

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

Примеры команд PowerShell для выполнения описанных шагов по настройке Split DNS:

  • создание области и записей для контроллеров:

    Add-DnsServerZoneScope -ZoneName "inno.local" -Name "winscope"  -PassThru
Add-DnsServerResourceRecord -ZoneName "inno.local" -A -Name "@" -IPv4Address 10.0.18.61 -ZoneScope "winscope"
Add-DnsServerResourceRecord -ZoneName "inno.local" -A -Name "@" -IPv4Address 10.0.18.62 -ZoneScope "winscope"
Add-DnsServerResourceRecord -ZoneName "inno.local" -A -Name "ldc1" -IPv4Address 10.0.18.61 -ZoneScope "winscope"
Add-DnsServerResourceRecord -ZoneName "inno.local" -A -Name "ldc2" -IPv4Address 10.0.18.62 -ZoneScope "winscope"

  • создание клиентских подсетей для контроллеров:

    Add-DnsServerClientSubnet -Name "WDC1Net" -IPv4Subnet "10.0.18.61/32" -PassThru
Add-DnsServerClientSubnet -Name "WDC2Net" -IPv4Subnet "10.0.18.62/32" -PassThru
Add-DnsServerClientSubnet -Name "LDC1Net" -IPv4Subnet "10.0.18.65/32" -PassThru
Add-DnsServerClientSubnet -Name "LDC2Net" -IPv4Subnet "10.0.18.68/32" -PassThru
Add-DnsServerClientSubnet -Name "LocalhostNet" -IPv4Subnet "127.0.0.0/8" -PassThru
    Подсеть LocalhostNet необходима для случая, когда программное обеспечение на контроллере обращается к DNS-серверу на этом же контроллере. Альтернативный вариант настройки — при создании политики явно указать интерфейсы в параметре -ServerInterfaceIP.

  • создание политики:

    Add-DnsServerQueryResolutionPolicy -Name "ExcludePolicy" -Action ALLOW -ClientSubnet "ne,WDC1Net,WDC2Net,LDC1Net,LDC2Net,LocalhostNet" -FqDN "eq,ldc1.inno.local,ldc2.inno.local,inno.local" -QType "eq,A" -InternetProtocol "eq,IPv4" -ZoneName "inno.local" -ZoneScope "winscope" -PassThru

Проверка настроек

Для вывода текущих настроек с целью проверки их корректности могут использоваться следующие команды PowerShell:

Get-DnsServerClientSubnet
Get-DnsServerResourceRecord -ZoneName " inno.local" -ZoneScope "winscope"  -RRType "A" | ForEach-Object {$PSItem.RecordData, $PSItem.HostName}
Get-DnsServerQueryResolutionPolicy -ZoneName " inno.local"
(Get-DnsServerQueryResolutionPolicy -ZoneName " inno.local").Criteria

Также рекомендуется проверить работу DNS-сервера с помощью утилиты nslookup — при запуске на контроллерах адреса, возвращаемые для имен контроллеров и имени домена верхнего уровня, должны соответствовать изначальным.

Подключение информационных систем к контроллеру Эллес

Для обеспечения работы какой-либо ИС с контроллером Эллес (в примере на Рис. 3 это ИС №2, работающая с контроллерами ldc1 и ldc2) необходимо при запросе A-записей возвращать реальный IP-адрес контроллера Эллес.

Реальный IP-адрес контроллера Эллес может быть указан в файле hosts на компьютерах с ИС, но такой способ приемлем только при небольшом числе ИС.

Практичнее поступить так же, как при исключении подмены IP-адресов:

  1. Создать клиентскую подсеть (в примере — 10.0.18.63/32 с именем IS2Subnet).

  2. Модифицировать политику, включив в фильтр новую клиентскую подсеть.

Примеры команд PowerShell для создания клиентской подсети и изменения политики:

Add-DnsServerClientSubnet -Name "IS2Subnet" -IPv4Subnet "10.0.18.63/32" -PassThru
Remove-DnsServerQueryResolutionPolicy -Name "ExcludePolicy" -ZoneName "inno.local"
Add-DnsServerQueryResolutionPolicy -Name "ExcludePolicy" -Action ALLOW -ClientSubnet "ne,WDC1Net,WDC2Net,LDC1Net,LDC2Net,LocalhostNet,IS2Subnet" -FqDN "eq,ldc1.inno.local,ldc2.inno.local,inno.local" -QType "eq,A" -InternetProtocol "eq,IPv4" -ZoneName "inno.local" -ZoneScope "winscope" -PassThru

Настройка BIND 9

Поскольку все ИС изначально настроены на работу с контроллерами Windows AD DS, то есть все DNS-запросы поступают на MS DNS, дополнительная настройка серверов BIND 9 не требуется.

Дополнительная настройка при использовании LDAPS

В рассмотренной схеме подменяются IP-адреса контроллеров. Это может привести к сбою при использовании TLS (например, при обращении по протоколу LDAPS), так как клиент обращается по имени одного контроллера, а фактически клиенту отвечает контроллер с другим именем и сертификатом.

Для решения данной проблемы могут использоваться сертификаты, содержащие имена как самого контроллера, так и подменяемого контроллера (в примере на wdc1 устанавливается сертификат с именами wdc1 и ldc1, а на wdc2 устанавливается сертификат с именами wdc2 и ldc2).

Также может использовать wildcard-сертификат (.inno.local).

Пример сертификата:

spit dns ldaps