У меня странная проблема в моей локальной сети, которая не позволяет некоторым клиентам иногда получать IP-адрес с реального DHCP-сервера (x.x.x.3). Dhcp-server - это виртуальная машина CentOS, на которой запущен isc-dhcp-server для ipv4. Маршрутизатор от моего интернет-провайдера, Sagemcom, отключил dhcp-сервер (x.x.x.1).
Однако, когда клиент подключен напрямую к маршрутизатору Sagemcom, я иногда вижу такой ответ:
The server offers address x.x.x.181 from x.x.x.3
NACK: Requested address not available from x.x.x.1
(не совсем так ...) Итак, почему маршрутизатор выдает NACK, когда он должен быть выключен? Какую роль здесь играет директива "authoritive" из dhcpd.conf?
Итак, мой самый важный вопрос, как я могу решить эту проблему?
Если я запустил nmap --script broadcast-dhcp-discover когда мой собственный dhcp-сервер неактивен, я не получаю ответа.
Какую роль здесь играет директива "authoritive" из dhcpd.conf?
Из руководства dhcpd:
DHCP-сервер обычно предполагает, что информация о конфигурации для данного сегмента сети неизвестна и не является достоверной. Это сделано для того, чтобы, если наивный пользователь устанавливает DHCP-сервер, не полностью понимая, как его настроить, он не отправляет ложные сообщения DHCPNAK клиентам, которые получили адреса от легитимного DHCP-сервера в сети.
Это означает, что сервер DHCP отправит NACK, если получит запрос на адрес, о котором он не знает. В вашем случае это другой сервер DHCP, который отправляет NACK, поэтому «авторитетный» на вашем сервере не имеет значения в этом случае, но это было бы, если бы клиент запросил адрес, принадлежащий другому серверу DHCP.
Вы можете запустить tcpdump с параметром -e, чтобы увидеть, какой хост Ethernet отправляет NACK. Это может быть маршрутизатор или прокси, настроенный для пересылки на маршрутизатор. В зависимости от конфигурации потенциального прокси-сервера он может ответить NACK, если не получит ответа от DHCP-сервера.
Возможно, у вас есть настроенный где-то в сети помощник dhcp relay / dhcp, который указывает на «отключенный» DHCP-сервер. Запрос будет содержать IP-адрес устройства ретрансляции, и если он не совпадает с подсетью DHCP, будет выдан NACK. Подробности вы можете узнать, выполнив трассировку пакетов.
Плес смотрите здесь: https://documentation.meraki.com/zGeneral_Administration/Tools_and_Troubleshooting/DHCP_NAK
DHCP NAK - это отрицательное подтверждение от DHCP-сервера. Сервер отправит DHCP NAK в следующих сценариях:
Запрошенный адрес, возможно, из той же подсети, но не из пула адресов сервера. Это может быть сценарий аварийного переключения в
какие 2 DHCP-сервера обслуживают одну и ту же подсеть, так что когда один
отключается, другой не должен НАКать клиентам, получившим IP от
первый сервер.Запрошенный адрес находится в другой подсети.
Запрошенный адрес уже используется другим клиентом.
На другие ваши вопросы:
Итак, почему маршрутизатор выдает NACK, когда он должен быть выключен? Какую роль здесь играет директива "authoritive" из dhcpd.conf?
Похоже, что dhcp-сервер на самом деле не выключен.
Цитата из https://linux.die.net/man/5/dhcpd.conf :
Авторитетное заявление
авторитетный;
не авторитетный;
DHCP-сервер обычно предполагает, что информация о конфигурации для данного сегмента сети неизвестна и не является достоверной. Это сделано для того, чтобы, если наивный пользователь устанавливает DHCP-сервер, не полностью понимая, как его настроить, он не отправляет ложные сообщения DHCPNAK клиентам, которые получили адреса от легитимного DHCP-сервера в сети.
Сетевые администраторы, устанавливающие авторитетные DHCP-серверы для своих сетей, всегда должны писать авторитетные; в верхней части файла конфигурации, чтобы указать, что DHCP-сервер должен отправлять сообщения DHCPNAK неправильно настроенным клиентам. Если этого не сделать, клиенты не смогут получить правильный IP-адрес после смены подсети до истечения срока их старой аренды, что может занять довольно много времени.
Обычно пишут авторитетные; на верхнем уровне файла должно быть достаточно. Однако, если DHCP-сервер должен быть настроен так, чтобы он знал о некоторых сетях, для которых он является авторитетным, и о некоторых сетях, для которых он не является, может быть более целесообразным объявить полномочия для каждого сегмента сети.
Обратите внимание, что наиболее конкретной областью, для которой понятие полномочий имеет смысл, является физический сегмент сети - либо оператор совместно используемой сети, либо оператор подсети, который не содержится в операторе совместно используемой сети. Не имеет смысла указывать, что сервер является авторитетным для некоторых подсетей в общей сети, но не является полномочным для других, а также не имеет смысла указывать, что сервер является авторитетным для некоторых объявлений хоста, а не для других.
Итак, мой самый важный вопрос, как я могу решить эту проблему?
Ответ - отслеживание пакетов. https://www-01.ibm.com/support/docview.wss?uid=swg21175744