Dhcp сервер получил сообщение от клиента который недопустим

Обновлено: 02.07.2024

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

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

Как происходит ошибка DHCP

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

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

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

Если автоматическое устранение неполадок не исправило ваши настройки DHCP, вы можете сделать это вручную.

Этот параметр позволяет DHCP-серверу или маршрутизатору в сети назначать компьютеру следующий доступный IP-адрес в сети.

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

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

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

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

Симптомы

Обычно всё начинается с жалоб на неработающий интернет или отсутствие доступа к локальным сетевым ресурсам. Иногда достаточно провести диагностику только на стороне клиента, но может понадобиться полная диагностика и со стороны сервера в том числе. Начнём с первой опции.

Диагностика на стороне клиента

Чтобы понять, что происходит, первым делом, конечно, следует проверить, подключён ли клиент физически к проводной или беспроводной сети. Если да, то самое время приступать к проверке сетевых настроек на устройстве клиента с помощью утилит ipconfig /all (в командной строке Windows), ifconfig или ip addr (в терминале Linux).

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

Вариант 1. Текущий IP-адрес имеет вид 169.254.Х.Х

Скорее всего, на клиентской машине при этом установлена ОС Windows. Это значит, что клиенту действительно не удалось получить сетевые настройки, потому что DHCP-сервер не отвечал, и адрес был сгенерирован службой APIPA (Automatic Private IP Addressing) из диапазона 169.254.0.0 – 169.254.255.255. Если клиент — Linux-машина, адрес может принимать вид 0.0.0.0, либо отсутствовать в принципе.

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

отключиться от сети на 10–30 секунд и подключиться снова;
перезагрузить устройство;
выполнить последовательно команды. В командной строке Windows: ipconfig /release, затем ipconfig /renew. В терминале Linux: dhclient -v -r, потом dhclient или dhcpcd -k, затем dhcpcd ().

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

Вариант 2. Текущий IP-адрес не из диапазона 169.254.0.0 – 169.254.255.255, но и не из того диапазона адресов, которые должен выдавать DHCP-сервер

Как известно, чудес не бывает. Если настройки, которые получает клиент, не от доверенного DHCP-сервера в сети, значит, их раздаёт кто-то другой. Тот, кто случайно или специально подключил к сети DHCP-сервер со своей конфигурацией. Возможно, это обычный Wi-Fi-роутер, к которому кабель по ошибке подключили через один из LAN-портов. Тогда ваша задача — найти недоверенный DHCP-сервер и предотвратить такие попытки в будущем.

Здесь нужно вспомнить, как работает DHCP-протокол. Клиент отправляет широковещательный запрос (DHCPDISCOVER), который получат все DHCP-серверы в сети и отправят в ответ свои предложения IP-адреса (DHCPOFFER). При этом клиент примет первое полученное предложение (DHCPOFFER), скорее всего, от ближайшего DHCP-сервера, а остальные отклонит.

Очевидно, что предложение от доверенного DHCP-сервера приходит позже, скорее всего, потому, что он дальше от клиента. Для последующей диагностики на устройстве клиента нужно установить анализатор сетевого трафика (Wireshark или tcpdump), запустить его, отфильтровав трафик по типу протокола DHCP или портам 67–68, и посмотреть в DHCP-ответах IP и MAC адрес DHCP-сервера, который их отправляет:

Вариант 3. Текущий IP-адрес корректный, но доступа к интернету и другим сетевым ресурсам по-прежнему нет

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

Следует помнить, что DHCP-сервер может раздавать настройки выборочно, а сам клиент может выборочно их применять. Например, только IP-адрес, маску и шлюз. Это скорее исключение, но в таком случае адреса DNS придётся прописать руками. Гораздо хуже, если настройки адресов DNS-серверов от DHCP-сервера игнорируются просто потому, что их переопределяет стороннее ПО или неверные статические настройки. Такое тоже бывает.

Диагностика на стороне сервера

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

Запущен ли DHCP как сервис?

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

Приходят ли запросы от клиентов на DHCP-сервер?

Чтобы определить это, нужно снова запустить анализатор сетевого трафика. На этот раз на сервере. После запуска на сервере tcpdump, dhcpdump или Wireshark клиенту, у которого проблемы с получением адреса, необходимо попытаться получить его снова любым способом, описанным в начале статьи. Если DHCP-сервер работает в штатном режиме, то должны быть и запросы, и ответы. Но всё может быть иначе.

Предположим, что у нас есть по крайней мере один клиент, которому не удаётся получить настройки, и запрос от него точно должен был прийти на сервер. Если этого не произошло, очевидно, что клиент либо сам не отправляет запрос, либо запрос не доходит до сервера по разным причинам. Может, он блокируется на промежуточном сетевом оборудовании или в сети некорректно работает ретрансляция DHCP-запросов dhcp_relay.
Чтобы это проверить, можно в первом случае вернуться к диагностике на стороне клиента и проследить с помощью анализатора сетевого трафика, что клиент отправляет DHCP-запрос. Во втором — проверить настройки на промежуточном сетевом оборудовании.

Запрос(ы) есть, ответа(ов) нет?

Самая простая и очевидная причина в этом случае — закончился пул свободных адресов. Это легко проверить на самом DHCP-сервере по списку выделенных IP-адресов (leases). Если причина действительно в этом — задумайтесь: возможно, пришло время для увеличения пула пригодных для использования IP-адресов на сервере. Чтобы решить проблему прямо сейчас, можно почистить список существующих адресов, выданных в аренду клиентам, уменьшить время аренды и перезапустить сервис DHCP. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.

Симптомы

Диагностика на стороне клиента

Вариант 1. Текущий IP-адрес имеет вид 169.254.Х.Х

отключиться от сети на 10–30 секунд и подключиться снова;
перезагрузить устройство;
выполнить последовательно команды. В командной строке Windows: ipconfig /release, затем ipconfig /renew. В терминале Linux: dhclient -v -r, потом dhclient или dhcpcd -k, затем dhcpcd ().

Вариант 2. Текущий IP-адрес не из диапазона 169.254.0.0 – 169.254.255.255, но и не из того диапазона адресов, которые должен выдавать DHCP-сервер

Вариант 3. Текущий IP-адрес корректный, но доступа к интернету и другим сетевым ресурсам по-прежнему нет

Диагностика на стороне сервера

Запущен ли DHCP как сервис?

Приходят ли запросы от клиентов на DHCP-сервер?

Запрос(ы) есть, ответа(ов) нет?

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

Код ошибки: 1041

Ситуация такая, стоял DHCP-сервер на серваке (2003 R2). Раздавал адреса. И тут внезапно появилась ошибка, описанная чуть выше. При этом адреса по-прежнему раздаются, но в оснастке DHCP в закладке "арендованные адреса" полная пустота. В чем может быть дело? Как решить проблему?

В этой статье описывается, как устранять неполадки, возникающие на DHCP-клиентах.

Контрольный список по устранению неполадок

Проверьте следующие устройства и параметры:

Кабели подключены и работают.

Фильтрация MAC включена для коммутаторов, к которым подключен клиент.

Сетевой адаптер включен.

Установлен и обновлен правильный драйвер сетевого адаптера.

Служба DHCP-клиента запущена и работает. Чтобы проверить это, выполните команду net start и найдите DHCP-клиент.

На клиентском компьютере нет портов блокировки брандмауэра 67 и 68.

Журналы событий

изучите журналы событий администратора или события клиента microsoft-Windows-dhcp client events/operation и Microsoft-Windows-dhcp client events. Все события, связанные со службой клиента DHCP, отправляются в эти журналы событий. события клиента Microsoft-Windows-DHCP находятся в Просмотр событий в разделе журналы приложений и служб.

Команда PowerShell Get-NetAdapter-Инклудехидден предоставляет необходимые сведения для интерпретации событий, перечисленных в журналах. Например, идентификатор интерфейса, MAC-адрес и т. д.

сбор данных

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

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

На клиенте, на котором возникла проблема, выполните следующие команды:

Затем Wireshark на клиенте и сервере. Проверьте созданные трассировки. Они должны, по крайней мере, сообщать о том, на каком этапе прекращается обмен данными.

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

Модем не получает адрес по DHCP
Добрый день. Имеется RB750UP и билайновский модем, как резервный канал. Модем подключен через.

Получает ip адрес от другого dhcp
На роутере, который раздает интернет, настроен dhcp сервер. К роутеру подключено 2 разных сети.

Запутался с ACL. Клиент не получает адрес по dhcp от Cisco
Есть Int Vlan 1 - inside. Есть Int Fa 4 - outside. Есть ACL, который висит на Int Vlan 1 : .

Компьютер не получает настроек сети по DHCP
Доброго времени суток, перешёл на Linux - всё великолепно, но возникают проблемы с сетью. Компьютер.

Не понятно что за система. 169 это начало или конец?

При чём работало в определённый момент, при автоматическом назначении - нормально выдался адрес, работал доступ, домашняя группа. Сейчас ни при автоопределении ни при статически заданных адресах не работает. Что это? Как сделать?

netsh interface ipv4 reset

Сброс - сбой.
Отказано в доступе.

netsh interface ipv6 reset

Сброс - сбой.
Отказано в доступе.

********************
netsh int ip reset
Сброс - сбой.
Отказано в доступе.

Заданные пользователем настройки для сброса отсутствуют.
********************

- Это на сервере.
На клиенте всё прошло нормально.

Адаптер Ethernet Локалка:

DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Qualcomm Atheros AR8151 PCI-E Gigabit Ethernet Controller (NDIS 6.30)
Физический адрес. . . . . . . . . : 90-2B-34-15-F7-67
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
Локальный IPv6-адрес канала . . . : fe80::b5cf:6972:22a0:7207%7(Основной)
Автонастройка IPv4-адреса . . . . : 169.254.114.7(Основной)
Маска подсети . . . . . . . . . . : 255.255.0.0
Основной шлюз. . . . . . . . . : fe80::1582:768b:a42e:d590%7
IAID DHCPv6 . . . . . . . . . . . : 110111540
DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-1E-4F-BC-BA-90-2B-34-15-F7-67
DNS-серверы. . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBios через TCP/IP. . . . . . . . : Включен

Адаптер Ethernet Donapex:

Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Microsoft ISATAP Adapter
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да

Туннельный адаптер Teredo Tunneling Pseudo-Interface:

Читайте также: