Как связаны длительность аренды DHCP и процесс сбора мусора в DNS

Цель нашей компании - предложение широкого ассортимента услуг на постоянно высоком качестве обслуживания.

Задать вопрос
Наши специалисты ответят на любой интересующий вопрос по услуге
Привет всем, меня зовут Шон Айви и я US PFE (Premier Field Engineer). Моя специализация — операционная система Windows и службы Active Directory. Проще говоря, я специализируюсь на Active Directory и связанных с ней сетевых службах. Недавно, у трёх разных клиентов, я помогал SCCM администраторами, у которых была проблема с установкой SCCM агента. В логе ccm.log значилась ошибка Failed to get token for current process (5). Мы обнаружили, что проблема была не в SCCM, а во взаимодействии DNS и DHCP. Как оказалось, другие службы тоже испытывали связанные с этим проблемы, просто либо демонстрировали иные симптомы, либо не демонстрировали их совсем. Давайте поговорим о том почему так получалось и как это можно предотвратить!

Рассмотрим следующий сценарий:

DHCP


  • В DHCP настроена область IP адресов, со сроком аренды 8 дней
  • В области DHCP осталось мало свободных IP адресов
  • Клиент А не обновлял аренду своего адреса 8 дней и она истекла
  • Клиент Б запрашивает новый IP адрес
  • DHCP сервер отдаёт Клиенту Б адрес, которым раньше пользовался Клиент А


Пока всё хорошо. Это довольно типовой сценарий работы DHCP сервера и всё происходит именно так, как мы ожидаем. Давайте теперь добавим сюда DNS сервер.

DNS


  • Интегрированная с Active Directory зона DNS с настроенной очисткой зоны
  • Настройки очитски по умолчанию: “Интервал блокирования = 7 дней” и “Интервал обновления = 7 дней”
  • Настройки сервера также по умолчанию: “Период очистки = 7 дней”
  • Клиент А обновил DNS запись 8 дней назад (в тот самый день, когда получил свой адрес)
  • Клиент А является владельцем своей DNS записи и она не может быть удалена DHCP сервером (при настройках по умолчанию)
  • Клиент Б пытается зарегистрировать DNS запись с новым адресом, который он получил от DHCP сервера
  • Это тот же самый IP адрес, который использовал Клиент А!
  • DNS сервер не сможет вычистить старую запись Клиента А еще 6 дней!

(Если, вдруг, вы не знаете, что такое “очистка зоны”, “интервал блокирования/обновления”, то рекомендую вам почитать блог моего коллеги. Он шикарен! Примечание: раз вы читаете перевод оригинальной статьи, то, возможно, вам проще будет ознакомиться с русскоязычным материалом)
Вот теперь всё уже не так хорошо. Такое случается гораздо чаще, чем вы можете подумать. Теперь у Клиентов А и Б DNS записи ссылаются на одинаковый IP адрес.


Рисунок 1

Итак, у нас в DNS есть два разных имени, ссылающихся на одинаковый IP адрес. И, скорее всего, всё именно так и останется еще минимум 6 дней, пока не истекут описанные выше интервалы. Какие проблемы это может вызвать? Давайте посмотрим.

Проблема


Я уже упомянул, что симптомом этой ситуации была проблема с установкой SCCM клиента, но, на самом деле, мы можем использовать для демонстрации более простой пример — доступ к общей папке. Принцип один и тот же.

Давайте представим, что мне нужно получить доступ к общей папке на Клиенте А. Для примера, возьмём одну из административных папок общего доступа.


Рисунок 2

А вот это уже интересно. Во первых, клиент А даже не включен… но мы получаем ответ от его имени. И это ошибка аутентификации! Некоторые из вас уже догадались, что это происходит, когда вы посылаете сеансовый ключ Kerberos предназначенный для одного компьютера другому, но давайте по порядку.

Мы видим, что наш компьютер (Infra-App1) посылает в DNS запрос на имя client-a.corp.contoso.com. В ответ он получает IP адрес 10.0.0.100.


Рисунок 3

Насколько знает DNS, так оно и есть. Клиент А действительно имеет адрес 10.0.0.100, но точно такой же адрес имеет Клиент Б.

Отлично, теперь мы получаем сеансовый ключ Kerberos. Вот только DNS запрос был на имя Клиента А, так что ответ от службы Kerberos также будет на имя клиента А.


Рисунок 4

Рисунок 5

Мы видим запрос на Рисунке 4 и ответ контроллера домена на Рисунке 5.

Теперь, получив ключ, мы можем попытаться подключиться, к тому, что мы считаем Клиентом А.


Рисунок 6

Здесь мы видим сеансовый ключ Kerberos.

И, наконец, мы видим сообщение об ошибке от Клиента А. Почему? Потому, что клиент А это не Клиент А, а Клиент Б.


Рисунок 7

Всё это только подтверждает то, что вы, вероятно, и так знали. Для того чтобы Kerberos отработал нормально, вы должны обратиться с правильным сеансовым ключом к правильному адресату (Если вы хотите узнать больше о Kerberos, почитайте блог Роба Грина "Kerberos для занятых админов" Примечание: аналогичного материала на русском я не нашёл, но с общими сведениями можно ознакомиться вот здесь).

Конечно, всё отлично сработает, если вместо FQDN имени мы обратимся по IP адресу. Почему? Потому, что в этому случае вместо Kerberos будет использована аутентификация NTLM. Используя IP адрес, мы не делаем никаких предположений о том, к какому клиенту мы подключаемся. Мы просто подключаемся по определённому IP адресу. Некоторые из вас могут подумать, что и для FQDN должно сработать. В конце концов, получив ошибку при использовании Kerberos, мы должны переключиться на NTLM, верно? Не совсем. Я не буду углубляться в детали, но мы переключимся на NTLM, только если мы не смогли договориться об использовании Kerberos. Вы можете прочитать об этом подробнее здесь. В любом случае, Kerberos не возвращал нам ошибки, он штатно ответил нам сеансовым ключом.

Как предотвратить


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

Примечание: я рекомендую уменьшить интервал очистки для каждого из этих способов до 1-3 дней. Интервал в 7 дней, используемый по умолчанию, позволяет проблемным записям оставаться в DNS чересчур долго.

  1. Увеличить длительность аренды DHCP, чтобы она соответствовала сумме интервалов обновления и блокирования. В нашем примере, мы увеличим его до 14 дней.

    Преимущества:
    1. К тому времени, как DHCP сможет выдать адрес новому клиенту, DNS запись старого уже может быть удалена
    2. Простота реализации

    Недостатки:
    1. Если у вас уже осталось мало свободных IP адресов в DHCP, то они могут просто закончится
    2. Момент очистки зоны не обязательно совпадёт с моментом истечение интервалов обновления и блокирования (а значит и времени аренды DHCP) и мы на небольшой промежуток времени можем получить ситуацию описанную выше. Чтобы уменьшить число таких проблем мы можем уменьшить интервал очистки до 1 дня.

  2. Уменьшить интервалы обновления и блокирования, чтобы их сумма совпадала с длительностью аренды DHCP. В нашем примере, мы сократим оба интервала до 4 дней.

    Преимущества:
    1. Существующая DNS запись будет очищена раньше. По сути, результат будет аналогичен предыдущему варианту
    2. Простота реализации

    Недостатки:
    1. Несколько увеличиться нагрузка на Active Directory репликацию (если, конечно, это Active Directory интегрированная зона). Это вызвано тем, что клиенты будут чаще обновлять свои DNS записи (в нашем случае, каждые 4 дня вместо 7)
    2. Момент очистки зоны не обязательно совпадёт с моментом истечение интервалов обновления и блокирования (а значит и времени аренды DHCP) и мы на небольшой промежуток времени можем получить ситуацию описанную выше. Чтобы уменьшить число таких проблем мы можем уменьшить интервал очистки до 1 дня.

  3. Настроить DHCP сервер, чтобы он регистрировал DNS записи от имени клиентов (почитать как это настроить можно здесь Примечание: а на русском, здесь)

    Преимущества:
    1. DHCP сервер будет удалять записи в DNS сразу по истечении аренды IP адреса
    2. При правильной настройке у вас никогда не появится таких проблемных записей

    Недостатки:
    1. Более сложная настройка требует вовлечения более квалифицированного персонала
    2. Настройка дополнительно усложняется тем, что потребуется сервисная учётная запись, от имени которой будут работать DHCP сервера или все DHCP сервера нужно будет добавить в группу DNSUpdateProxy (менее безопасный вариант)



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

Поиск DNS записей с одинаковыми IP адресами



Почти всё! Теперь мы понимаем, почему происходит такая ситуация, когда возникает проблема и как её предотвратить. Но как нам легко и быстро найти такие записи, если беда уже случилась? Вы можете легко найти такие парные записи в DNS используя несложный PowerShell скрипт (это, конечно же, не единственный способ).

#Import the Active Directory Module
import-module activedirectory

#Define an empty array to store computers with duplicate IP address registrations in DNS
$duplicate_comp = @()

#Get all computers in the current Active Directory domain along with the IPv4 address
#The IPv4 address is not a property on the computer account so a DNS lookup is performed
#The list of computers is sorted based on IPv4 address and assigned to the variable $comp
$comp = get-adcomputer -filter * -properties ipv4address | sort-object -property ipv4address

#For each computer object returned, assign just a sorted list of all 
#of the IPv4 addresses for each computer to $sorted_ipv4
$sorted_ipv4 = $comp | foreach {$_.ipv4address} | sort-object

#For each computer object returned, assign just a sorted, unique list 
#of all of the IPv4 addresses for each computer to $unique_ipv4
$unique_ipv4 = $comp | foreach {$_.ipv4address} | sort-object | get-unique

#compare $unique_ipv4 to $sorted_ipv4 and assign just the additional 
#IPv4 addresses in $sorted_ipv4 to $duplicate_ipv4
$duplicate_ipv4 = Compare-object -referenceobject $unique_ipv4 -differenceobject $sorted_ipv4 | foreach {$_.inputobject}

#For each instance in $duplicate_ipv4 and for each instance 
#in $comp, compare $duplicate_ipv4 to $comp If they are equal, assign
#the computer object to array $duplicate_comp
foreach ($duplicate_inst in $duplicate_ipv4)
{
    foreach ($comp_inst in $comp)
    {
        if (!($duplicate_inst.compareto($comp_inst.ipv4address)))
        {
            $duplicate_comp = $duplicate_comp + $comp_inst
        }
    }
}

#Pipe all of the duplicate computers to a formatted table
$duplicate_comp | ft name,ipv4address -a


Ниже приведён образец вывода этого скрипта:


Рисунок 8

Скрипт очень простой. Рассматривайте его только как пример. Он вернёт дублированные IP адреса зарегистрированные для компьютерных учётных записей в Active Directory. Помните, что он запросит все компьютерные объекты из Active Directory домена и проверит в DNS IP адрес каждого из них. Если у вас много компьютеров, то используйте ключ -searchbase вместе с командой get-adcomputer, чтобы ограничить количество опрашиваемых каждый раз объектов. Если ваш компьютер не включен в Active Directory домен, то вы не сможете найти его командой get-adcomputer. Мой скрипт специально заточен на то, чтобы получить дублированные записи DNS для сценария, который я описал выше.

Заключение


Есть очень много статей о настройке интеграции DHCP и DNS. Цель этой — обобщить сведения о том, как эти две службы работает вместе, чтобы вам было проще это понять. Подведём итог:

  • Сценарий

    • Длительность аренды адреса в DHCP и интервалы обновления и блокирования по умолчанию = устаревшие DNS записи

  • Симптомы

    • SCCM: “Failed to get token for current process (5)”
    • Общие папки: “Logon Failure: The target account name is incorrect”
    • Любые другие службы использующие Kerberos также могут выдавать различные ошибки

  • Проблема

    • Корректная работа Kerberos требует, чтобы сеансовый ключ был выдан именно для того компьютера, с которым мы пытаемся установить соединение. Устаревшие DNS записи могут приводить к ситуациям, когда мы будем обращаться к одному компьютеру с ключом для другого

  • Решение

    • Изменение интервалов обновления и блокирования и/или длительности аренды DHCP
    • Настройка DHCP, чтобы сервер регистрировал DNS записи от имени клиентов
    • Поиск и удаление дублированных записей



Надеюсь, что статья была вам полезна! Правильная настройка интеграции DNS и DHCP избавит вас от такого рода проблем в вашей сети!

Источник
Заказать услугу
Оформите заявку на сайте, мы свяжемся с вами в ближайшее время и ответим на все интересующие вопросы.
Вернуться к списку