Отключенный dhcp-сервер на маршрутизаторе не позволяет клиентам получить адрес
У меня странная проблема в моей локальной сети, которая не позволяет некоторым клиентам иногда получать IP-адрес от реального dhcp-сервера (xxx3). Dhcp-сервер - это виртуальная машина CentOS, на которой запущен isc-dhcp-сервер для ipv4. Маршрутизатор от моего провайдера, Sagemcom, имеет отключенный dhcp-сервер (xxx1).
Однако, когда клиент подключен напрямую к маршрутизатору 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-сервер неактивен, я не получаю ответ.
2 ответа
Какую роль здесь играет директива `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 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