Клиенты получают неверные настройки (IP-адреса) по DHCP | GeekBrains — образовательный портал
Клиенты получают неверные настройки (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. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.
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».
Если подключение к интернет не появится и статус «Неопознанная сеть» возле адаптера не пропадает, то убедитесь, что вы меняли настройки именно того адаптера, через который выполняете подключение. Так же выполните перезагрузку компьютера.
Выше я показал два основных решения, с помощью которых чаще всего удается избавится от этой ошибки. Если у вас ничего не получилось – смотрите другие решения.
Дополнительные решения и подсказки
Источники:
Https://gb. ru/posts/klienty-poluchayut-nevernye-nastrojki-ip-adresa-po-dhcp
Https://help-wifi. com/reshenie-problem-i-oshibok/dhcp-ne-vklyuchen-na-setevom-adaptere-besprovodnaya-set-ethernet-podklyuchenie-po-lokalnoj-seti/
Обновлено 02.11.2019
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов рунета Pyatilistnik.org. В прошлый раз я вам рассказывал, как устанавливается и что из себя представляет DHCP сервер, на чем его можно организовывать. Уверен, что у каждого на предприятии используется данный сервис. В сегодняшней публикации я хочу вам показать решение по ошибке авторизации DHCP в Active Directory и звучит она вот так «Указанные серверы уже существуют в службе каталогов (The specified servers are already present in the directory service)».
Описание ситуации
Есть лес Active Directory, в одном из доменов была установлена служба DHCP, которая исправно работала. На данном контроллере в какой-то момент служба DHCP остановилась и пул адресов перестал быть активным, в интерфейсе было видно, что сервис запущен, но не авторизован в AD. При попытке его авторизации выскакивало окно:
Указанные серверы уже существуют в службе каталогов
или
The specified servers are already present in the directory service
Я вам уже подробно описывал процесс авторизации DHCP в Active Directory, там я рассмотрел:
- Где прописывается запись авторизации, как ее удалить или создать заново
- Как дать права на авторизацию
- Устранение проблем
Для начала я первым делом полез в логи Windows, чтобы посмотреть что там происходит, для этого можно воспользоватся просмотром событий или утилитой Windows Admin Center. Там я нашел ошибку 1035 и 1036:
Ошибка ID 1035 и 1036: The DHCP service was unable to create or lookup the DHCP Users local group on this computer. The error code is in the data. (Службе DHCP не удалось создать или выполнить поиск локальной группы пользователей DHCP на этом компьютере. Код ошибки находится в данных.)
А так же ошибка ID 1046:
Ошибка ID 1046: The DHCP/BINL service on the local machine, belonging to the Windows Administrative domain root.pyatilistnik.org, has determined that it is not authorized to start. It has stopped servicing clients. The following are some possible reasons for this:
This machine is part of a directory service enterprise and is not authorized in the same domain. (See help on the DHCP Service Management Tool for additional information).
This machine cannot reach its directory service enterprise and it has encountered another DHCP service on the network belonging to a directory service enterprise on which the local machine is not authorized.
Some unexpected network error occurred.
(Служба DHCP/BINL на локальном компьютере, принадлежащем административному домену Windows root.pyatilistnik.org, определила, что она не авторизована для запуска. Он прекратил обслуживание клиентов. Ниже приведены некоторые возможные причины этого:
Этот компьютер является частью службы каталогов и не авторизован в том же домене. (Для получения дополнительной информации см. Справку в инструменте управления службами DHCP).
Эта машина не может связаться со своей службой каталогов, и в сети обнаружена другая служба DHCP, принадлежащая службе каталогов, на котором локальный компьютер не авторизован.
Произошла непредвиденная ошибка сети.)
Как видно из описанных выше ошибок нам нужно проверить:
- Сетевые настройки на интерфейсе, а именно DNS сервера
- Проверить нет ли блокировок со стороны антивирусных решений
- Нет ли старых записей авторизации в базе Active Directory
- Нет ли повреждений со стороны базы данных DHCP
Если обратиться к решению ошибки ID 1036 и 1035, то Microsoft советует произвести перезапуск службы:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc726946(v=ws.10)
Для этого полностью остановите службу DHCP, через все задачи «Остановить«.
или можете через PowerShell:
Get-Service Dhcp | Stop-Service -Force
После этого запустите службу, через графический интерфейс или через команду:
Get-Service Dhcp | Start-Service
Проверьте появилась ли возможность авторизовать вашу службу. Если ошибка «Указанные серверы уже существуют в службе каталогов (The specified servers are already present in the directory service)» осталась, и вы в логах видите так же события ID 1046, то нужно проверить сетевые настройки. Для этого откройте окно выполнить и введите в нем ncpa.cpl, чтобы вызвать сетевые настройки.
Проверяем, что у вас не прописаны внешние DNS сервера.
Если были внесены изменения, то пробует проверить снова. Следующим, этапом я бы порекомендовал открыть командную строку от имени той учетной записи или запустите PowerShell, это не принципиально, у которой есть права «Администратора предприятия (Enterprise Admin)«, именно у него есть права на авторизацию сервиса. Далее введите команду для авторизации:
netsh dhcp add server dc01.root.pyatilistnik.org 192.168.31.3
Если все хорошо, то должно активироваться, но у меня выскочила ошибка:
Указанные серверы уже существуют в службе каталогов (The specified servers are already present in the directory service)
Помня в голове про ошибку 1046, я понимал, что либо была повреждена база данных, либо была кривая запись в контейнере Services. Давайте начнем с контейнера, напоминаю, что вам необходимо открыть утилиту ADSIEdit.msc и перейти в раздел конфигурации, там далее CN=Services,CN=Configuration,DC=root,DC=pyatilistnik,DC=org, не забудьте поменять данные на свой домен. В итоге я вижу запись dhcpServer: CN=dc01.root.pyatilistnik.org,CN=NetServices,CN=Services,CN=Configuration,DC=root,DC=pyatilistnik,DC=org
В итоге попробуйте удалить старую запись, для этого просто через контекстное меню выберите соответствующий пункт.
Обязательно произведите выключение и включение DHCP службы, как я описывал выше
Теперь пробуйте авторизовать роль, мне помогло и ошибка «Указанные серверы уже существуют в службе каталогов (The specified servers are already present in the directory service)» исчезла, запись в контейнере CN=Services,CN=Configuration,DC=root,DC=pyatilistnik,DC=org так же была пересоздана.
Переустановка роли из-за поврежденной базы
Ошибка может оставаться и проблема тут к сожалению связана с поврежденной базой данных роли. Если у вас есть бэкап, то попробуйте восстановить из него, например в случае если у вас это виртуальная машина. По умолчанию встроенное резервное копирование делается в папку:
C:WindowsSystem32dhcpbackup
Пробуем удалить и заново установить роль DHCP. Проще всего, это сделать через PowerShell
Remove-WindowsFeature DHCP -IncludeManagementTools или Uninstall-WindowsFeature DHCP -IncludeManagementTools
Первый является псевдонимом для второго. Далее перезагрузите сервер, если старая база вам не нужна зачистите все в папке C:WindowsSystem32dhcp
Install-WindowsFeature -Name DHCP -IncludeAllSubFeature
После переустановки DHCP я снова проверил с помощью BPA роль DHCP.
На этот раз было опубликовано предупреждение о том, что группа безопасности DHCP будет отсутствовать. Я использовал команду netsh для добавления группы безопасности dhcp.
C:Windowssystem32 netsh dhcp add securitygroups
Затем остановка и повторный запуск службы DHCP и другое сканирование с помощью инструмента BPA больше не отображали никаких предупреждений или ошибок. И новый идентификатор 1035/1036 больше не виден в средстве просмотра событий.
Дополнительные решения
- Попробуйте отключить на сервере DCHP если это Windows встроенный брандмауэр
- Если на сервере есть антивирус, то так же на время выключите его
Надеюсь, что вам удалось решить проблему с авторизацией DHCP сервера, на этом у меня все. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
Не удалось настроить DHCP-сервер, код ошибки 0x80074E54
Во время добавления роли DHCP при включеном NAT вы можете встретить данную ошибку: “Не удалось настроить DHCP-сервер, код ошибки 0x80074E54”
и получим такую картину, где показывается gw.mshome.net, который мы не настраивали
Используя стандартное средство поиска ошибок,
получаем подсказку
“Проблема:Порт 67 используется процессом с ИД 2976.
Воздействие:Если порт 67 используется другим процессом, DHCP-сервер не может обмениваться данными с DHCPv4-клиентами.
Разрешение:Настройте процесс с ИД 2976 так, чтобы он использовал порт с другим номером.”
Всё кажется логично, порт занят, DHCP сервер не стартует, но кто же его
занял? Пытаемся выяснить это при помощи команд (хотя можно сразу
использовать вторую команду с PID из сообщения об ошибке):
netstat -a -o|findstr :67 — будут показаны процессы использующие данный порт
tasklist /SVC /FI «PID eq 2976» – подскажет, кто виновен (2976 это номер процесса, который мы получили ранее)
Почесывая затылок, вспоминаем о чудесной возможности NAT назначать адреса, смотрим, включена ли она:
Отключаем данный функционал, удаляем роль DHCP, перегружаемся
чистим настройки del c:WindowsSystem32dhcp* /F /S /Q
ставим роль DHCP снова и получаем работоспособный DHCP сервер, т.к.
теперь никто не занимает наш 67ой порт и не портит картину кривыми
настройками
—-
PS
Полностью содрано с Zona Sumraka, поскольку помогло в решение практической задачи.
Клиенты получают неверные настройки (IP-адреса) по DHCP | GeekBrains — образовательный портал
Клиенты получают неверные настройки (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. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.
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».
Если подключение к интернет не появится и статус «Неопознанная сеть» возле адаптера не пропадает, то убедитесь, что вы меняли настройки именно того адаптера, через который выполняете подключение. Так же выполните перезагрузку компьютера.
Выше я показал два основных решения, с помощью которых чаще всего удается избавится от этой ошибки. Если у вас ничего не получилось – смотрите другие решения.
Дополнительные решения и подсказки
Источники:
Https://gb. ru/posts/klienty-poluchayut-nevernye-nastrojki-ip-adresa-po-dhcp
Https://help-wifi. com/reshenie-problem-i-oshibok/dhcp-ne-vklyuchen-na-setevom-adaptere-besprovodnaya-set-ethernet-podklyuchenie-po-lokalnoj-seti/
Обновлено 02.11.2019
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов рунета Pyatilistnik.org. В прошлый раз я вам рассказывал, как устанавливается и что из себя представляет DHCP сервер, на чем его можно организовывать. Уверен, что у каждого на предприятии используется данный сервис. В сегодняшней публикации я хочу вам показать решение по ошибке авторизации DHCP в Active Directory и звучит она вот так «Указанные серверы уже существуют в службе каталогов (The specified servers are already present in the directory service)».
Описание ситуации
Есть лес Active Directory, в одном из доменов была установлена служба DHCP, которая исправно работала. На данном контроллере в какой-то момент служба DHCP остановилась и пул адресов перестал быть активным, в интерфейсе было видно, что сервис запущен, но не авторизован в AD. При попытке его авторизации выскакивало окно:
Указанные серверы уже существуют в службе каталогов
или
The specified servers are already present in the directory service
Я вам уже подробно описывал процесс авторизации DHCP в Active Directory, там я рассмотрел:
- Где прописывается запись авторизации, как ее удалить или создать заново
- Как дать права на авторизацию
- Устранение проблем
Как починить авторизацию DHCP
Для начала я первым делом полез в логи Windows, чтобы посмотреть что там происходит, для этого можно воспользоватся просмотром событий или утилитой Windows Admin Center. Там я нашел ошибку 1035 и 1036:
Ошибка ID 1035 и 1036: The DHCP service was unable to create or lookup the DHCP Users local group on this computer. The error code is in the data. (Службе DHCP не удалось создать или выполнить поиск локальной группы пользователей DHCP на этом компьютере. Код ошибки находится в данных.)
А так же ошибка ID 1046:
Ошибка ID 1046: The DHCP/BINL service on the local machine, belonging to the Windows Administrative domain root.pyatilistnik.org, has determined that it is not authorized to start. It has stopped servicing clients. The following are some possible reasons for this:
This machine is part of a directory service enterprise and is not authorized in the same domain. (See help on the DHCP Service Management Tool for additional information).
This machine cannot reach its directory service enterprise and it has encountered another DHCP service on the network belonging to a directory service enterprise on which the local machine is not authorized.
Some unexpected network error occurred.
(Служба DHCP/BINL на локальном компьютере, принадлежащем административному домену Windows root.pyatilistnik.org, определила, что она не авторизована для запуска. Он прекратил обслуживание клиентов. Ниже приведены некоторые возможные причины этого:
Этот компьютер является частью службы каталогов и не авторизован в том же домене. (Для получения дополнительной информации см. Справку в инструменте управления службами DHCP).
Эта машина не может связаться со своей службой каталогов, и в сети обнаружена другая служба DHCP, принадлежащая службе каталогов, на котором локальный компьютер не авторизован.
Произошла непредвиденная ошибка сети.)
Как видно из описанных выше ошибок нам нужно проверить:
- Сетевые настройки на интерфейсе, а именно DNS сервера
- Проверить нет ли блокировок со стороны антивирусных решений
- Нет ли старых записей авторизации в базе Active Directory
- Нет ли повреждений со стороны базы данных DHCP
Если обратиться к решению ошибки ID 1036 и 1035, то Microsoft советует произвести перезапуск службы:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc726946(v=ws.10)
Для этого полностью остановите службу DHCP, через все задачи «Остановить«.
или можете через PowerShell:
Get-Service Dhcp | Stop-Service -Force
После этого запустите службу, через графический интерфейс или через команду:
Get-Service Dhcp | Start-Service
Проверьте появилась ли возможность авторизовать вашу службу. Если ошибка «Указанные серверы уже существуют в службе каталогов (The specified servers are already present in the directory service)» осталась, и вы в логах видите так же события ID 1046, то нужно проверить сетевые настройки. Для этого откройте окно выполнить и введите в нем ncpa.cpl, чтобы вызвать сетевые настройки.
Проверяем, что у вас не прописаны внешние DNS сервера.
Если были внесены изменения, то пробует проверить снова. Следующим, этапом я бы порекомендовал открыть командную строку от имени той учетной записи или запустите PowerShell, это не принципиально, у которой есть права «Администратора предприятия (Enterprise Admin)«, именно у него есть права на авторизацию сервиса. Далее введите команду для авторизации:
netsh dhcp add server dc01.root.pyatilistnik.org 192.168.31.3
Если все хорошо, то должно активироваться, но у меня выскочила ошибка:
Указанные серверы уже существуют в службе каталогов (The specified servers are already present in the directory service)
Помня в голове про ошибку 1046, я понимал, что либо была повреждена база данных, либо была кривая запись в контейнере Services. Давайте начнем с контейнера, напоминаю, что вам необходимо открыть утилиту ADSIEdit.msc и перейти в раздел конфигурации, там далее CN=Services,CN=Configuration,DC=root,DC=pyatilistnik,DC=org, не забудьте поменять данные на свой домен. В итоге я вижу запись dhcpServer: CN=dc01.root.pyatilistnik.org,CN=NetServices,CN=Services,CN=Configuration,DC=root,DC=pyatilistnik,DC=org
В итоге попробуйте удалить старую запись, для этого просто через контекстное меню выберите соответствующий пункт.
Обязательно произведите выключение и включение DHCP службы, как я описывал выше
Теперь пробуйте авторизовать роль, мне помогло и ошибка «Указанные серверы уже существуют в службе каталогов (The specified servers are already present in the directory service)» исчезла, запись в контейнере CN=Services,CN=Configuration,DC=root,DC=pyatilistnik,DC=org так же была пересоздана.
Переустановка роли из-за поврежденной базы
Ошибка может оставаться и проблема тут к сожалению связана с поврежденной базой данных роли. Если у вас есть бэкап, то попробуйте восстановить из него, например в случае если у вас это виртуальная машина. По умолчанию встроенное резервное копирование делается в папку:
C:WindowsSystem32dhcpbackup
Пробуем удалить и заново установить роль DHCP. Проще всего, это сделать через PowerShell
Remove-WindowsFeature DHCP -IncludeManagementTools или Uninstall-WindowsFeature DHCP -IncludeManagementTools
Первый является псевдонимом для второго. Далее перезагрузите сервер, если старая база вам не нужна зачистите все в папке C:WindowsSystem32dhcp
Install-WindowsFeature -Name DHCP -IncludeAllSubFeature
После переустановки DHCP я снова проверил с помощью BPA роль DHCP.
На этот раз было опубликовано предупреждение о том, что группа безопасности DHCP будет отсутствовать. Я использовал команду netsh для добавления группы безопасности dhcp.
C:Windowssystem32 netsh dhcp add securitygroups
Затем остановка и повторный запуск службы DHCP и другое сканирование с помощью инструмента BPA больше не отображали никаких предупреждений или ошибок. И новый идентификатор 1035/1036 больше не виден в средстве просмотра событий.
Дополнительные решения
- Попробуйте отключить на сервере DCHP если это Windows встроенный брандмауэр
- Если на сервере есть антивирус, то так же на время выключите его
Надеюсь, что вам удалось решить проблему с авторизацией DHCP сервера, на этом у меня все. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
- Remove From My Forums
-
Question
-
Hi am Selasi,
am doing my project work which required me to install a DHCP to enable distribute IP addresses to my client. actually am using HP PAVILION G7 1310us
and am running the DHCP on a VMWARE machine. Any time i tried to install it tells me INSTALLATION SUCCESSFUL WITH ERRORS
ATTEMPT TO CONFIGURE DHCP SERVER FAIL WITH ERRORS CODE 0X80074E66. the DHCP server could not contact active directory.
can anyone help me out here.
Answers
-
This forum is for Small Business Server (SBS). I think you need a different server forum or even something for VMWare.
Steve
-
Marked as answer by
Tuesday, May 21, 2013 8:48 AM
-
Marked as answer by