Windows 10 dhcp клиент не получает адрес
Windows 10 не может получить адрес DHCP (IP), но вы можете это исправить
DHCP – это протокол динамического управления хостом, который назначает IP-адреса для Windows 10. Таким образом, DHCP необходим для сетевого подключения.
Если Windows 10 не может получить IP-адрес из протокола Dynamic Host Control Protocol, пользователи не могут открывать любые веб-сайты в своих браузерах. DHCP не включен для Wi-Fi, когда он не назначает IP-адрес.
Пользователи могут проверить, включен ли DHCP, введя «ipconfig/all» в командной строке. Эта утилита командной строки предоставляет сведения об IP-адресе для ПК и сообщает пользователям, включен ли DHCP.
При устранении неполадок в сети Windows может также отображаться сообщение об ошибке « DHCP не включен для Wi-Fi ». Если DHCP не включен, пользователям необходимо будет исправить этот протокол, чтобы он снова назначал IP-адрес.
Именно так пользователи могут включить DHCP, чтобы он снова предоставлял IP-адреса для Windows 10.
Что делать, если DHCP не включен для Wi-Fi
1. Включите службу DHCP-клиента
Сначала убедитесь, что служба DHCP-клиента включена. Windows 10 не получит IP-адреса DCHP, если эта служба не включена. Пользователи могут включить клиент DCHP следующим образом.
– СВЯЗАННО: что делать, если у Wi-Fi нет правильной конфигурации IP
2. Настройте параметры сетевого адаптера.
Ошибка « DHCP не включен для Wi-Fi » часто может быть связана с неправильно настроенными сетевыми настройками. Таким образом, настройка параметров сетевого адаптера IPv4 может исправить DHCP для многих пользователей.
Следуйте приведенным ниже инструкциям, чтобы настроить параметры сетевого адаптера.
3. Отключите брандмауэр Защитника Windows
Брандмауэр Защитника Windows обычно не блокирует DHCP. Тем не менее, он все еще может заблокировать DHCP, если настроен для этого. Таким образом, отключение брандмауэра может восстановить службу DHCP в Windows. Пользователи могут отключить WDF следующим образом.
– СВЯЗАННО: Как открыть порты брандмауэра в Windows 10 [Пошаговое руководство]
4. Отключите сторонние антивирусные утилиты
Сторонние антивирусные утилиты, скорее всего, конфликтуют с DHCP. Таким образом, отключение антивирусного программного обеспечения может также снова включить DHCP.
Большинство антивирусных пакетов включают в своих контекстных меню функцию отключения или отключения, которую пользователи могут выбрать, щелкнув правой кнопкой мыши значки на панели задач.
Или пользователи могут удалить антивирусное программное обеспечение из автозагрузки системы, чтобы убедиться, что они не запускаются с Windows.
5. Переустановите драйвер сетевого адаптера.
Ошибка « DHCP не включен для Wi-Fi » может быть связана с повреждением драйвера сетевого адаптера. Переустановка этого драйвера может затем решить проблему.
Пользователи могут переустановить драйвер сетевого адаптера по умолчанию следующим образом.
– СВЯЗАННО: Как обновить устаревшие драйверы в Windows 10
6. Сбросить протокол TCP/IP и Winsock
Сброс Интернет-протокола и сетевого адаптера к настройкам по умолчанию часто может исправить сетевые соединения. Пользователи могут сделать это, введя несколько команд в командной строке.
Таким образом пользователи могут сбросить настройки сетевого адаптера и TCP/IP.
Это несколько возможных разрешений, которые могут включить DHCP, чтобы Windows получал IP-адрес. Затем пользователи могут снова открывать сайты в своих браузерах.
Служба DHCP-клиента выдает ошибку «Отказано в доступе» в Windows 10
Служба DHCP-клиента выдает ошибку «Отказано в доступе»
DHCP-клиент доступен в качестве службы и передает информацию о конфигурации, такую как IP-адрес, Mac-адрес, имя домена и т. Д., На компьютер. Если эта служба останавливается или ОС не может получить к ней доступ, компьютер не будет получать динамические IP-адреса и обновления DNS.
1] Проверьте разрешения для DHCP
Чтобы получить полное разрешение для раздела реестра, нажмите кнопку «Пуск», затем введите regedit в поле поиска.
Щелкните правой кнопкой мыши файл regedit.exe и выберите команду «Запуск от имени администратора». При появлении запроса введите имя пользователя и пароль и нажмите кнопку «ОК».
Перейдите к следующему ключу:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ DHCP \ Configurations
Нажмите правой кнопкой мыши клавишу Конфигурации и выберите Разрешения.
В разделе Группы или имена пользователей выберите свою учетную запись.
В столбце Разрешить в разделе Разрешения установите флажки Полный доступ и Чтение.
Нажмите Применить, затем нажмите ОК.
Если ваше имя отсутствует, нажмите кнопку «Добавить». Затем введите свое имя пользователя на компьютере и добавьте его. Затем подайте заявку на разрешения.
Далее перейдите к следующей клавише:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Dhcp
В столбце «Разрешить» убедитесь, что установлены флажки «Запрос», «Создать значение», «Перечислить подразделы», «Уведомить», «Чтение». Возможно, вам придется нажать «Показать дополнительные разрешения», чтобы открыть полный список разрешений.
Нажмите ОК, чтобы закрыть окно, затем нажмите Применить, затем нажмите ОК.
Если MpsSvc отсутствует в списке, нажмите «Добавить», а затем выполните поиск « NT SERVICE \ mpssvc ». Добавьте это и примените вышеуказанные разрешения.
Сообщите нам, помогли ли эти советы решить вашу проблему
Клиент DHCP может не получить IP-адрес, присвоенный DHCP
Эта статья поможет устранить проблему, из-за которой DHCP-клиент не может получить IP-адрес, присвоенный DHCP.
Исходная версия продукта: Windows Server 2012 R2
Исходный номер КБ: 167014
Симптомы
При перемещении DHCP-клиента из одной подсети в другую может не получиться действительный IP-адрес в новой подсети.
Решение
Чтобы обойти эту проблему, сделайте один из следующих способов:
Не используйте перекрывающиеся схемы IP-адресов.
После перемещения клиента в новый сегмент запустите следующие команды:
Дополнительные сведения
Когда DHCP-клиент с ранее назначенным DHCP-адресом снова запущен, он переходит в состояние INIT-REBOOT. Клиент попытается убедиться, что он может использовать тот же адрес, отправив пакет DHCPRequest, заполнив поле параметра DHCP «DHCP Requested Address» ранее назначенным IP-адресом.
Если DHCP-сервер остается в тихом режиме, клиент считает предыдущий адрес действительным и сохраняет его. Если DHCP-сервер отправляет пакет NACK в ответ на DHCPRequest, клиент переходит в цикл обнаружения; Он также запрашивает ранее назначенный адрес в пакете DHCPDiscover.
Когда DHCP-сервер получает DHCPRequest с указанным ранее адресом, он сначала проверяет, поступил ли он из локального сегмента, проверив поле GIADDR. Если он был получен из локального сегмента, DHCP-сервер сравнивает запрашиваемую адрес с IP-адресом и маской подсети, принадлежащей локальному интерфейсу, который получил запрос.
Если адрес находится в той же подсети, DHCP-сервер будет оставаться в тихом режиме, даже если адрес находится не в диапазоне его пула адресов. Сервер DHCP предполагает, что адрес был назначен другим DHCP-сервером в том же сегменте, если он не принадлежит к собственному пулу. Если адрес не удается проверить маску подсети или IP-адрес, DHCP-сервер проверяет, поступил ли он из superscope, если он определен. В этом случае сервер отвечает на DHCPRequest пакетом NACK.
Если клиент, отправляющий DHCPRequest, запрашивает адрес, который, как представляется, находится в той же подсети, но фактически был назначен с другой маской подсети, DHCP-сервер будет оставаться в тихом режиме, и клиенту не удастся получить действительный IP-адрес для новой подсети.
Например, предположим, что клиент DHCP получает адрес 172.17.3.x с маской подсети 255.255.255.0, а клиент перемещается в новый сегмент, где адрес DHCP-сервера — 172.17.1.x с маской подсети 255.255.0.0. После сравнения маски подсети и IP-адреса на DHCP-сервере DHCP-сервер будет оставаться в тихом режиме, предполагая, что адрес назначен другому DHCP-серверу в сегменте. Если маски подсети были отменены, клиент получит действительный адрес.
DHCP не включен на сетевом адаптере «Беспроводная сеть», «Ethernet», «Подключение по локальной сети»
Самая популярная проблема при подключении ПК или ноутбука к интернету, это когда вроде бы все подключили, но интернет не работает. В этом случае может быть очень много разных симптомов, причин и решений. Первым делом нужно выяснить в чем причина. Рекомендую ориентироваться на ошибки, которые отображаются в Windows. Мало кто сразу запускает диагностику неполадок. А зря, ведь если само средство диагностики и устранения неполадок не сможет все исправить, то хотя бы сообщит нам об ошибке и подскажет где и как искать проблему. Как в нашем случае с ошибкой «DHCP не включен на сетевом адаптере. «, которую можно увидеть в Windows 10, Windows 7 и т. д.
Когда после подключения кабеля, или после подключения к Wi-Fi сети (или попытки подключения) вы видите ошибку «Неопознанная сеть», «Подключение к интернету отсутствует», «Нет подключения. Вы не подключены ни к одной сети», «Без доступа к интернету» и т. д., то запустите диагностику неполадок.
Вполне возможно, что в процессе диагностики появится ошибка «DHCP не включен на сетевом адаптере Беспроводная сеть» (при подключении по Wi-Fi) :
При этом в самой системе (в моем случае в Windows 10) статус подключения к сети будет выглядеть примерно вот так (может немного отличаться в зависимости от способа подключения) :
Если у вас все примерно так же, то вы зашли по адресу. Сейчас покажу, как можно решить эту проблему. Но сначала несколько слов о том, почему появляется эта ошибка, и почему этот DHCP не включен на сетевом адаптере.
Если просто и коротко, то DHCP позволяет Windows автоматически получать IP-адреса от роутера, или оборудования вашего интернет-провайдера. А эта ошибка появляется тогда, когда DHCP не может автоматически получит адреса, или не может получить те адреса, которые прописаны вручную. Чаще всего это происходит после того, как сам пользователь, или какой-то софт меняет настройки DHCP в свойствах адаптера «Беспроводная сеть», или «Ethernet». Это в Windows 10. А в Windows 7 это адаптеры «Беспроводное сетевое соединение» и «Подключение по локальной сети».
Как исправить ошибку «DHCP не включен на сетевом адаптере. » в Windows 10?
Для Windows 8 и Windows 7 эти рекомендации так же должны подойти. Некоторые пункты меню и настройки могут немного отличатся. Я буду показывать все на примере Windows 10.
Решение №1: через диагностику сетей Windows
Если вам повезет, то сразу после запуска средства диагностики появится следующее сообщение: «Автоматически обновлять параметры сети. В системе поддерживается автоматическое определение параметров сети». Не задумываясь нажимайте на «Внести это исправление».
Или после того, как будет обнаружена проблема, например, «DHCP не включен на сетевом адаптере Беспроводная сеть» нажмите на пункт «Попробуйте выполнить восстановление от имени администратора».
Если системе удастся автоматически решить эту проблему, то напротив обнаруженной проблемы появится надпись «Исправлено» и интернет заработает.
Если не получится с первого раза, то перезагрузите компьютер и запустите диагностику неполадок повторно.
Решение №2: проверяем настройки DHCP вручную
Первым делом нам нужно открыть окно «Сетевые подключения». Сделать это можно с помощью команды ncpa.cpl. Нажмите сочетание клавиш Win+R, скопируйте эту команду в поле «Открыть» и нажмите «Ok».
Дальше нужно нажать правой кнопкой мыши и открыть «Свойства» того адаптера, при подключении через который у вас возникла эта ошибка. В случае с Windows 10: «Ethernet» – это подключение по кабелю, а «Беспроводная сеть» – подключение по Wi-Fi.
Дальше выделяем протокол «IP версии 4 (TCP/IPv4)» и нажимаем на кнопку «Свойства». Выставляем автоматическое получение IP и DNS адресов, как показано на скриншоте ниже и нажимаем «Ok».
Если подключение к интернет не появится и статус «Неопознанная сеть» возле адаптера не пропадает, то убедитесь, что вы меняли настройки именно того адаптера, через который выполняете подключение. Так же выполните перезагрузку компьютера.
Выше я показал два основных решения, с помощью которых чаще всего удается избавится от этой ошибки. Если у вас ничего не получилось – смотрите другие решения.
Дополнительные решения и подсказки
Клиенты получают неверные настройки (IP-адреса) по DHCP
Чтобы взаимодействовать с другими, каждому устройству в сети необходимо иметь четыре основные настройки на сетевом адаптере — IP-адрес, маску, шлюз по умолчанию и адреса DNS-серверов (хотя последнее на самом деле опционально). Есть два основных способа назначения сетевых настроек — статически (вручную) и динамически (автоматически по протоколу DHCP от DHCP-сервера).
Второй вариант чаще всего гораздо удобнее, ведь настройки не придётся прописывать руками. Но наверняка многим приходилось сталкиваться с ситуацией, когда клиентское устройство получает совершенно другой IP-адрес вместо корректных настроек от 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-клиент. Это можно сделать несколькими способами:
При выводе каких-либо ошибок и/или предупреждений нужно в первую очередь их устранить — например если 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-сервера, который их отправляет:
Дальше дело за малым. Во-первых, можно воспользоваться сервисом macvendors.com или аналогичным и по MAC-адресу определить производителя оборудования этого устройства. У Wireshark есть такая функция. Во-вторых, если есть управляемые коммутаторы в сети, найти по MAC, в какой порт какого коммутатора подключено это устройство. После нейтрализации недоверенного DHCP-сервера клиенту, скорее всего, удастся получить верные настройки. Для предотвращения таких инцидентов в будущем рекомендуется внедрить методы защиты от атак на 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. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.
Чтобы взаимодействовать с другими, каждому устройству в сети необходимо иметь четыре основные настройки на сетевом адаптере — IP-адрес, маску, шлюз по умолчанию и адреса DNS-серверов (хотя последнее на самом деле опционально). Есть два основных способа назначения сетевых настроек — статически (вручную) и динамически (автоматически по протоколу DHCP от DHCP-сервера).
Второй вариант чаще всего гораздо удобнее, ведь настройки не придётся прописывать руками. Но наверняка многим приходилось сталкиваться с ситуацией, когда клиентское устройство получает совершенно другой IP-адрес вместо корректных настроек от 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-клиент. Это можно сделать несколькими способами:
При выводе каких-либо ошибок и/или предупреждений нужно в первую очередь их устранить — например если 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-сервера, который их отправляет:
Дальше дело за малым. Во-первых, можно воспользоваться сервисом macvendors.com или аналогичным и по MAC-адресу определить производителя оборудования этого устройства. У Wireshark есть такая функция. Во-вторых, если есть управляемые коммутаторы в сети, найти по MAC, в какой порт какого коммутатора подключено это устройство. После нейтрализации недоверенного DHCP-сервера клиенту, скорее всего, удастся получить верные настройки. Для предотвращения таких инцидентов в будущем рекомендуется внедрить методы защиты от атак на 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. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.