Срок истечения аренды на роутере

DHCP — протокол автоматизации назначения IP-адреса клиенту. Он широко используется в современных сетях. В статье рассмотрим принципы работы, процесс DORA, основные опции и другие аспекты протокола.

Для чего нужен протокол DHCP

DHCP — протокол прикладного уровня модели TCP/IP, служит для назначения IP-адреса клиенту. Это следует из его названия — Dynamic Host Configuration Protocol. IP-адрес можно назначать вручную каждому клиенту, то есть компьютеру в локальной сети. Но в больших сетях это очень трудозатратно, к тому же, чем больше локальная сеть, тем выше возрастает вероятность ошибки при настройке. Поэтому для автоматизации назначения IP был создан протокол DHCP.

Впервые протокол был описан в 1993 году в документе RFC 1531, но с тех пор в описание вносились правки. На сегодняшний день основным документом, регламентирующим протокол, является RFC 2131. Помимо автоматизации процесса настройки IP, DHCP позволяет упростить диагностику подключения и переход из одной подсети в другую, оставляя уведомления для системного администратора в логах.

Принцип работы DHCP

Из вступления ясно, какие функции предоставляет DHCP, но по какому принципу он работает? Получение адреса проходит в четыре шага. Этот процесс называют DORA по первым буквам каждого шага: Discovery, Offer, Request, Acknowledgement.

Давайте подробнее рассмотрим DORA — принцип работы DHCP.

Протокол DHCP, получение адреса IP — DORA

Discovery, или поиск

Изначально клиент находится в состоянии инициализации (INIT) и не имеет своего IP-адреса. Поэтому он отправляет широковещательное (broadcast) сообщение DHCPDISCOVER на все устройства в локальной сети. В той же локальной сети находится DHCP-сервер. DHCP-сервер — это, например, маршрутизатор или коммутатор, существуют также выделенные DHCP-серверы.

Не всегда одну сеть обслуживает один DHCP-сервер, нередко организации устанавливают сразу несколько. Какие порты использует DHCP? Сервер всегда слушает 67 порт, ожидает широковещательное сообщение от клиента, а после его получения отправляет ответное предложение — DHCPOFFER. Клиент принимает сообщение на 68 порту.

Offer, или предложение

DHCP-сервер отвечает на поиск предложением, он сообщает IP, который может подойти клиенту. IP выделяются из области (SCOPE) доступных адресов, которая задается администратором.

Если имеются адреса, которые не должны быть назначены DHCP-сервером, область можно ограничить, указав только разрешенные адреса. Например, администратор может задать диапазон используемых IP-адресов от 192.0.0.10 до 192.0.0.254.

Бывает и так, что не все доступные адреса должны быть назначены клиентам. Например, администратор может исключить (exclude) диапазон 192.0.0.100 — 192.0.0.200 из используемой области. Такое ограничение называется исключением.

DHCP выделяет доступные IP-адреса из области только временно (об этом позже), поэтому нет гарантии, что при следующем подключении у данного клиента останется прежний IP. Но есть возможность назначить какому-либо клиенту определенный IP навсегда. К примеру, забронировать 192.0.0.10 за компьютером системного администратора. Такое сохранение IP для отдельных клиентов называют резервацией (reservation).

DHCPOFFER содержит IP из доступной области, который предлагается клиенту отправкой широковещательного (broadcast, «если вы тот, кто запрашивал IP-адрес, то доступен вот такой») или прямого (unicast, «вы запрашивали IP, предлагаю вот такой») сообщения. При этом, поскольку нужный клиент пока не имеет IP, для отправки прямого сообщения он идентифицируется по MAC-адресу.

Request, или запрос

Клиент получает DHCPOFFER, а затем отправляет на сервер сообщение DHCPREQUEST. Этим сообщением он принимает предлагаемый адрес и уведомляет DHCP-сервер об этом. Широковещательное сообщение почти полностью дублирует DHCPDISCOVER, но содержит в себе уникальный IP, выделенный сервером. Таким образом, клиент сообщает всем доступным DHCP-серверам «да, я беру этот адрес», а сервера помечают IP как занятый.

Acknowledgement, или подтверждение

Сервер получает от клиента DHCPREQUEST и окончательно подтверждает передачу IP-адреса клиенту сообщением DHCPACK. Это широковещательное или прямое сообщение утверждает не только владельца IP, но и срок, в течение которого клиент может использовать этот адрес.

Со схемой отправки сообщений разобрались, но, если в сети несколько DHCP-серверов, пославших предложение, какое из них выберет клиент? Хороший вопрос. В состоянии INIT, если клиент получает адрес впервые, он будет принимать только первое предложение IP. Однако, если клиент уже общался ранее с определенным DHCP-сервером, он отдаст предпочтение этому серверу и, наоборот, сервер выберет знакомого клиента.

Арендуйте выделенные серверы с запуском от двух минут.

Срок аренды

Когда DHCP-сервер выделяет IP из области, он оставляет запись о том, что этот адрес зарезервирован за клиентом с указанием срока действия IP. Этот срок действия называется срок аренды (lease time). Срок аренды по умолчанию выставлен на 24 часа, но может доходить до нескольких дней, недель или даже месяцев. Период задается в настройках самого сервера.

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

После получения адреса из области, клиент берет его в аренду на время, называемое T. Клиент переходит в связанное (BOUND) состояние и продолжает нормальную работу, пока не наступит время половины срока аренды — T1.

По наступлении T1 клиент инициализирует процедуру получения нового IP или обновления адреса — состояние RENEWING. Процесс повторного получения происходит по упрощенной схеме: клиент прямым сообщением запрашивает (DHCPREQUEST), а сервер подтверждает (DHCPACK) запрос. Время аренды начинает отсчитываться заново.

Если подтверждение (DHCPACK) от сервера не поступает, клиент снова запрашивает адрес, но только когда истекает половина T1. Если запрос адреса остается без ответа второй раз, клиент отправляет еще одно сообщение, когда истекает половина от T1/2 (25% от полного срока аренды). Следующий запрос будет отправлен после истечения еще половины оставшегося времени, потом еще половины. И так далее, пока не наступит T2, которое равняется 87,5%, или 7/8 от всего времени аренды. После T2 все попытки продлить аренду IP будут широковещательными. Это значит, что, если первый сервер по какой-то причине недоступен, на запрос адреса сможет ответить любой другой, и работа не будет прервана.

Три подхода к распределению адресов

Сервер назначает IP одним из трех основных способов.

Статическое распределение (static allocation). Почти как ввод адреса на каждом компьютере вручную. Отличие в том, что системный администратор задает нужные соответствия IP для MAC-адресов клиентов на самом DHCP-сервере. IP останется за клиентом, даже если тот выйдет из сети, отключится, перейдет в новую сеть и т.п.

Автоматическое распределение (automatic allocation). Сервер закрепляет IP из области за каждым клиентом навсегда. Срок аренды не ограничен.

Динамическое распределение (dynamic allocation). DHCP-сервер назначает адрес из области на определенное время, называемое сроком аренды. Такой подход полезен, если число доступных IP ограничено. IP назначается каждому клиенту при подключении к сети и возвращается в область, как только клиент его освобождает. В таком случае IP может отличаться при каждом подключении, но обычно назначается прежний.

Особые DHCP сообщения

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

DHCPNAK. Нередко в источниках можно встретить написание DHCPNACK, что является неправильным, так как RFC 2131 регламентирует именно NAK. DHCPNAK отправляется сервером вместо окончательного подтверждения. Такой отказ может быть отправлен клиенту, если аренда запрашиваемого IP истекла или клиент перешел в новую подсеть.

DHCPRELEASE. Клиент отправляет это сообщение, чтобы уведомить сервер об освобождении занимаемого IP. Иными словами, это досрочное окончание аренды.

DHCPINFORM. Этим сообщением клиент запрашивает у сервера локальные настройки. Отправляется, когда клиент уже получил IP, но для правильной работы ему требуется конфигурация сети. Сервер информирует клиента ответным сообщением с указанием всех запрошенных опций.

Опции DHCP

Для работы в сети клиенту требуется не только IP, но и другие параметры DHCP — например, маска подсети, шлюз по умолчанию и адрес сервера. Опции представляют собой пронумерованные пункты, строки данных, которые содержат необходимые клиенту сервера параметры конфигурации. Дадим описания некоторым опциям:

• Option 1 — маска подсети IP;
• Option 3 — основной шлюз;
• Option 6 — адрес сервера DNS (основной и резервный);
• Option 51 определяет, на какой срок IP-адрес предоставляется в аренду клиенту;
• Option 55 — список запрашиваемых опций. Клиент всегда запрашивает опции для правильной конфигурации. Отправляя сообщение с Option 55, клиент выставляет список запрашиваемых числовых кодов опций в порядке предпочтения. DHCP-сервер старается отправить ответ с опциями в том же порядке.

Option 82 — ретрансляция DHCP-сервера

Option 82 — информация об агенте ретрансляции (relay agent information). Благодаря ретранслятору клиент и сервер могут общаться, находясь в разных подсетях. По умолчанию широковещательные сообщения не могут выходить за пределы текущего широковещательного домена (подсети). Внимательный читатель скажет, что выше мы писали, как клиент отправляет широковещательное сообщение DHCPDISCOVER всем доступным DHCP-серверам. А что если в сети нет DHCP?

Предположим, широковещательные сообщения не выходят за пределы подсети компании, которая не установила DHCP-сервер. В таком случае сообщение DHCPDISCOVER должно будет пропасть, и ни один компьютер компании не сможет выйти в интернет. Однако в реальности отсутствие DHCP-сервера не мешает выходу в сеть.

Значит ли это, что широковещательные сообщения каким-то образом выходят за пределы подсети? Не совсем. За пределы подсети выходят только широковещательные DHCP-сообщения. Это становится возможным благодаря агенту ретрансляции. Обычно в его роли выступает маршрутизатор или сервер. Ретранслятор получает сообщения от клиента в своей подсети, направляют его на DHCP-сервер, который тем же образом — через ретранслятор — отправляет ответ. Так ретранслятор выступает в качестве посредника между подсетями.

Опции DHCP для загрузки PXE

Протокол DHCP позволяет загрузку компьютера без использования носителя данных. Такая загрузка происходит с сетевой карты и называется PXE (Preboot eXecution Environment). Для конфигурации сетевой загрузки LEGACY BIOS PXE используются DHCP-опции 43, 60, 66 и 67.

• Option 43 зарезервирована для обмена информацией производителей;
• Option 60 — классовый идентификатор; здесь указывается, например, PXE клиент;
• Option 66 и 67 необходимы для указания имени сервера PXE и имени файла загрузки соответственно.

Взаимодействие DHCP и DNS

Как мы упоминали выше, Option 6 — это сервер DNS. Давайте рассмотрим подробнее взаимодействие двух протоколов.

DNS (система доменных имен) отвечает за соответствие доменных имен и IP-адресов. Доменное имя — это не только адрес в интернете, например, selectel.ru, но также имя компьютера в локальной сети, например, Director PC. DNS проводит соединительную линию между IP и буквенно-числовым доменным именем компьютера или веб-сайта. DHCP занимается выделением и назначением IP из области. Очевидно, что два протокола должны тесно взаимодействовать между собой.

В статье мы уже говорили, что DHCP-сервер имеет область IP-адресов, которые допускается распределять между клиентами в сети. DNS-сервер занимается тем, что сопоставляет IP-адреса и доменные имена. Это не только имена сайтов, но и имена компьютеров в сети, (например, NetworkServer PC).

Если вы хотите создать свою локальную сеть на базе Linux, потому что это бесплатно и вы не хотите связываться Windows, то вы можете столкнуться с проблемой взаимодействия DNS и DHCP. Linux не имеет Active Directory, как в Windows, позволяющей тесно связать DHCP и DNS, избегая необходимости обращаться к клиенту каждый раз по IP. Однако способы организовать такую связь существуют и для свободной системы.

Первый вариант — настроить DHCP-сервер так, чтобы фиксировал адрес за клиентом. Второй вариант — настроить взаимодействие DHCP- и DNS- серверов. Первый вариант подходит, если область IP-адресов широкая и вы можете позволить себе фиксировать IP за каждым клиентом. Если же для вас такой метод будет расточительным, то необходимо дать двум серверам работать вместе.

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

Настроить данное взаимодействие можно в четыре шага при помощи пакета dnsmasq, доступного в стандартных репозиториях Ubuntu и Debian. Мы не будем давать детальную инструкцию по осуществлению, а лишь кратко опишем каждый шаг.

Шаг 1 — конфигурация сети

В первую очередь необходимо определиться с компьютером, который будет выполнять роль сервера. Важно выбрать тот компьютер (Ubuntu Server или Ubuntu Desktop), который вы не планируете выключать слишком часто. Если после полной настройки вы решите выключить компьютер, то вся сеть тоже выключится.

Выбранному компьютеру необходимо назначить статический IP. Делается это редактированием конфигурационного файла в директории /etc/network/interfaces.

Шаг 2 — установка dnsmasq

Установите пакет dnsmasq командой из терминала:

sudo apt-get install dnsmasq -y

А затем откройте файл конфигурации /etc/dnsmasq.conf. Файл конфигурации dnsmasq очень большой, но он содержит комментарии с объяснениями того, за что отвечает каждая настройка. Чтобы добавить требуемые настройки, откройте файл и удалите решетку (#), означающую комментарий, в начале нужных строк.

Шаг 3 — настройка фаервола

Для изменения настроек фаервола можно использовать Ubuntu Uncomplicated Firewall. Используйте следующие команды:

sudo ufw allow bootps

sudo ufw allow 53/udp

sudo ufw allow 53/tcp

Шаг 4 — изменение настроек роутера

Зайдите в настройки вашего роутера из браузера, отключите DHCP для локальной сети, измените все настройки DNS так, чтобы они указывали на ваш только что настроенный сервер. Последнее действие — перезапуск сети на сервере. Для этого вы можете просто перезагрузить компьютер или использовать команды:

sudo service dnsmasq restart

sudo service network-manager restart

Недостатки протокола DHCP

DHCP имеет свои уязвимости. Основная заключается в четырех шагах, необходимых для получения IP. Процесс DORA подразумевает рассылку сообщений широковещательного типа, когда первый откликнувшийся DHCP-сервер получает возможность предложить IP из своей области. Если злоумышленник сможет использовать свой сервер, который даст самый быстрый ответ клиенту, то у него откроется возможность получить контроль над действиями пользователя в сети и нанести существенный ущерб.

Следующий недостаток — ненадежность UDP. UDP не обеспечивает гарантию доставки информации. Этот протокол допускает потери и ошибки, которые могут сказаться и на работе DHCP, в частности при PXE-загрузке.

Заключение

Мы рассмотрели основные принципы работы DHCP-серверов. Несмотря на недостатки и частые доработки, протокол DHCP широко используется в современных сетях. Также изучили процесс DORA, основные опции и другие аспекты протокола. Надеемся, эта статья оказалась вам полезна.

Время аренды (lease time) — это параметр в сетях TCP/IP, который определяет, на какой промежуток времени клиентский компьютер может использовать IP-адрес, назначенный роутером. Настройка времени аренды играет важную роль в поддержке и управлении сетевым соединением.

При подключении к сети, клиентский компьютер получает IP-адрес от DHCP-сервера в роутере с определенным временным сроком. Этот срок назначения IP-адреса определяет, на какой промежуток времени клиентский компьютер может быть активным в сети. По истечении времени аренды, компьютер должен обновить своё подключение, чтобы продлить аренду IP-адреса.

Аренда IP-адреса позволяет роутеру оптимизировать использование доступных IP-адресов и предотвращает потерю адресов из-за неактивных устройств или сбоев сети.

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

Время аренды в роутере влияет на сетевое соединение, поскольку при истечении времени аренды, роутер будет забирать IP-адрес у неактивного компьютера и назначать его другому устройству. Если компьютер не обновляет свою аренду вовремя, возникает риск потери соединения с сетью и проблемы с доступом в Интернет.

Что такое время аренды в роутере

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

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

Время аренды в роутере имеет несколько целей:

1. Управление адресным пространством: время аренды помогает эффективно использовать доступные IP-адреса, предотвращая их блокировку или злоупотребление.
2. Избежание конфликтов: если два устройства запросят один и тот же IP-адрес, сервер DHCP сможет назначить каждому из них уникальный адрес в рамках своего временного диапазона.
3. Упрощение управления: время аренды позволяет автоматически реагировать на изменения в сети и устройствах, обновляя IP-адреса или освобождая их при отключении устройств.

Если устройство не обновляет аренду в течение установленного времени, его IP-адрес может быть назначен другому устройству, что может привести к потере подключения к сети. Поэтому рекомендуется настроить время аренды в роутере таким образом, чтобы оно соответствовало потребностям сети и устройств, подключенных к ней.

Влияние времени аренды на сетевое соединение

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

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

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

Что делать, если срок аренды DHCP истекает каждый час (10.10.23)

У некоторых пользователей Windows возникают проблемы с подключением к Интернету, и причина в том, что их DHCP истекает через каждый час. Если вы зависите от Интернета (а мы все зависим), это может сильно расстраивать. Ошибка DHCP — это как смертный приговор в Интернете, потому что без аренды DHCP вы вряд ли сможете получить доступ к Интернету.

Эта статья поможет вам понять, что такое DHCP и как избежать проблем, связанных с настройками DHCP. .

Что такое DHCP?

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

Что такое процесс аренды DHCP?

Вы должны быть знакомы с договором аренды жилья. Это позволяет вам арендовать дом или недвижимость на определенный период, как указано в контракте. По истечении срока аренды в собственность переезжает другой арендатор. Аналогичным образом, аренда DHCP (протокол динамического управления хостом) позволяет вам иметь доступ к определенному IP-адресу в течение установленного периода времени. Если срок аренды истекает, то IP-адрес больше не доступен для вас, и, следовательно, вы больше не сможете получить доступ к Интернету.

Совет профессионала: просканируйте свой компьютер на предмет проблем с производительностью, ненужных файлов и т.д. вредоносные приложения и угрозы безопасности
, которые могут вызвать проблемы в системе или снизить производительность.

Проблемы с бесплатным сканированием для ПК. Об Outbyte, инструкции по удалению, лицензионное соглашение, политика конфиденциальности.

Чаще всего истечение срока аренды DHCP затрагивает пользователей, у которых нет постоянного IP-адреса. Временные IP-адреса назначаются, например, пользователям, которые пользуются бесплатным Wi-Fi компании. По прошествии определенного времени IP-адрес истекает, а затем его назначают другому устройству. Установленный период, в течение которого устройство имеет IP-адрес, является временем аренды DHCP.

Обычно офисы устанавливают время аренды DHCP на несколько часов или даже минут в зависимости от характера их деятельности. Например, посетитель стоматологической клиники остается не более 30 минут, и поэтому нет необходимости назначать ему постоянный IP-адрес.

Почему истекает срок аренды DHCP?

Одна из причин, по которой срок аренды DHCP истекает, заключается в том, что слишком много устройств обращаются к одной и той же сети. Когда слишком много устройств подключаются к одной сети, возникает нехватка IP-адресов. Установка аренды DHCP на длительный период может быть достаточной для обслуживания устройств, которые регулярно используют сеть, но не всех из них. DCHP также истекает, потому что для него может быть установлен ограниченный период времени, и в этом случае пользователь должен настроить время аренды DHCP.

Настройка времени аренды DHCP

Если вы управляете офисом, в котором несколько устройств получают доступ к internet, вам нужно подумать об изменении времени аренды DHCP. В противном случае у вас не хватит IP-адресов.

Установка правильного времени аренды DHCP — это вопрос экспериментов и в основном зависит от ваших личных потребностей или потребностей вашего бизнеса. Наиболее типичное время аренды DHCP составляет 24 часа, но настройки можно изменить до одной минуты или до определенного количества дней. Установка слишком малого времени аренды с большой вероятностью вызовет перебои в обслуживании, но если подключенные устройства имеют относительно быстрый цикл обслуживания, настройки можно установить на менее 24 часов.

Чтобы сбросить настройки DHCP, выполните выполните следующие действия:

Время на прочтение
8 мин

Количество просмотров 41K

В качестве предисловия. При общении с коллегами, отвечая на их вопросы о совместной настройке DNS и DHCP, часто отсылаю их к замечательной статье Шона Айви на Technet. К сожалению, аналогичного материала на русском языке я не находил. В очередной раз, устно переведя её знакомому, я решил оформить письменный перевод, чтобы иметь возможность отсылать к нему.

Привет всем, меня зовут Шон Айви и я 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 избавит вас от такого рода проблем в вашей сети!

0

1

Имеется роутер asus ac86u, а также домашний проводной интернет от Beeline 100MBit/s Москва с типом подключения в терминологии провайдера IPoE т.е. роутер сразу автоматически от DHCP-сервера провайдера получает белый публичный интернет ip-адрес.
Срок аренды ip-адреса — 10 минут, за половину времени до истечения срока аренды адреса (т.е. за 5 минут) роутер продляет аренду (однако если в роутере включить QoS, то аренда продляется за несколько секунд до истечения срока действия).
Проблема в том, что периодически в интервале в среднем от 1-2 дней до 1-2 недель (явной закономерности не наблюдаю) интренет пропадает т.к. окончился срок действия аренды ip адреса (ip имеет статус expired в админке роутера).
Решение — выключить и включить интренет (WAN) в настройках роутера, т.е. по сути передёрнуть соотвествующий ползунок.

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