Клиенты получают неверные настройки (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.
- Remove From My Forums
-
Question
-
We are running W2K8 R2, and had successfully started running DHCP. But, because of a need to remote boot a new machine we needed to add Active Directory to the server. After adding Active Directory our DHCP server would not run, saying that it
first needs to be authorized. However, there is no option (either under the Action menu or when right-clicking on the DHCP server) to authorize. We thought that maybe the problem was caused by DHCP being on prior to Active directory, but even after
removing DHCP and then adding it back we get the same problem.Can anyone help on this?
Rick
Rick
Answers
-
Unfortunately, nothing was actually resolved from what we originally needed to do. To resolve the DHCP issue we had to remove all relevant services and re-add them, losing all user accounts at the same time, so we almost had to start from scratch.
And, the creating a terminal is apparently not possible with Windows Server, so we are back to just using an XP machine and logging in with RDP, which is exactly what we were trying to change.I do appreciate the help that everyone tried to give, but ultimately we just went around in a big circle and have ended up back where we started.
Rick
Rick
-
Marked as answer by
Thursday, August 26, 2010 2:14 PM
-
Marked as answer by
Обновлено 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/
- Remove From My Forums
-
Question
-
We are running W2K8 R2, and had successfully started running DHCP. But, because of a need to remote boot a new machine we needed to add Active Directory to the server. After adding Active Directory our DHCP server would not run, saying that it
first needs to be authorized. However, there is no option (either under the Action menu or when right-clicking on the DHCP server) to authorize. We thought that maybe the problem was caused by DHCP being on prior to Active directory, but even after
removing DHCP and then adding it back we get the same problem.Can anyone help on this?
Rick
Rick
Answers
-
Unfortunately, nothing was actually resolved from what we originally needed to do. To resolve the DHCP issue we had to remove all relevant services and re-add them, losing all user accounts at the same time, so we almost had to start from scratch.
And, the creating a terminal is apparently not possible with Windows Server, so we are back to just using an XP machine and logging in with RDP, which is exactly what we were trying to change.I do appreciate the help that everyone tried to give, but ultimately we just went around in a big circle and have ended up back where we started.
Rick
Rick
-
Marked as answer by
Thursday, August 26, 2010 2:14 PM
-
Marked as answer by
|
13 / 17 / 1 Регистрация: 29.08.2010 Сообщений: 566 |
|
|
1 |
|
|
Server 2008 02.05.2018, 08:58. Показов 3138. Ответов 3
Здравствуйте. Дело такое Есть сервак на Windows server 2008 r2
0 |
|
Programming Эксперт 94731 / 64177 / 26122 Регистрация: 12.04.2006 Сообщений: 116,782 |
02.05.2018, 08:58 |
|
3 |
|
162 / 74 / 23 Регистрация: 06.07.2017 Сообщений: 315 |
|
|
03.05.2018, 14:50 |
2 |
|
0 |
|
1044 / 528 / 66 Регистрация: 16.01.2013 Сообщений: 4,093 |
|
|
07.05.2018, 12:26 |
3 |
|
казах, служба DNS поднята на сервере?
0 |
|
13 / 17 / 1 Регистрация: 29.08.2010 Сообщений: 566 |
|
|
10.05.2018, 19:59 [ТС] |
4 |
|
Решениерешил проблему я маршрутизатор не прописал
0 |
Сообщение было отмечено Maks как решение
Не удалось настроить dhcp сервер код ошибки 0x80074e66
Клиенты получают неверные настройки (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 не включен на сетевом адаптере».
Содержание:
Что такое DHCP?
DHCP — это сетевой протокол, который выполняет функцию автоматической настройки параметров сети TCP/IP, получая их по запросу от DHCP сервера.
На практике это означает обмен определенными сообщениями между DHCP клиентом на устройстве и сервером во время установки сетевого подключения. В ходе коммуникации клиент получает новые или подтверждает старые значения таких параметров сети:
IP адрес для устройства;
DHCP: как работает?
Сервер обрабатывает клиентские запросы и выдает в аренду на определенное время IP адреса из своего диапазона. Если время заканчивается, клиент либо продлевает срок аренды, либо освобождает адрес, что также происходит путем обмена специальными сообщениями. Все запросы сервер записывает в свою базу данных, чтобы избежать конфликта адресов, то есть не выделить один адрес двум узлам одновременно.
Конфликт адресов все же может возникнуть, если на одном из устройств в сети IP присвоен вручную. При подключении нового компьютера, сервер может попытаться выдать ему адрес, который уже занят, в результате чего интернет соединение не будет установлено. Как решить эту проблему, будет рассмотрено далее.
Протокол DHCP широко используется благодаря тому, что дает возможность легко добавлять новые компьютеры к сети и изменять параметры подключения на сервере вместо ручной перенастройки каждого устройства.
Для использования протокола DHCP вам понадобится:
настроить DHCP на маршрутизаторе, который будет играть роль DHCP сервера.
запустить службу DHCP на ПК (она выполняет функцию клиента);
в настройках сетевого адаптера выбрать опцию автоматического получения IP адреса.
Рассмотрим каждый шаг детально.
Как включить DHCP на роутере?
Запустить на маршрутизаторе работу DHCP сервера нужно через веб-интерфейс. Вам потребуется выполнить следующие действия:
подключиться к роутеру по Wi-Fi или при помощи сетевого кабеля;
в адресной строке веб-браузера прописать локальный IP адрес маршрутизатора, который можно найти на наклейке внизу устройства (чаще всего 192.168.0.1 либо 192.168.1.1, но возможны и другие варианты вроде tplinklogin. net);
в появившемся окне набрать логин и пароль, значения которых по умолчанию посмотрите на той же наклейке, чаще всего это логин: admin, пароль: admin или 1234 (если вы поставили другие логин и пароль, воспользуйтесь ими, а если не можете вспомнить, придется провести на роутере сброс настроек до заводских и попробовать заново);
в открывшемся меню, вид которого будет отличаться в зависимости от производителя маршрутизатора, выберете пункт «Настройка локальной сети» или нечто подобное, там поставьте отметку напротив опции включения DHCP сервера;
сохраните новые параметры.
Если сразу не получается открыть настройки роутера, попробуйте войти из другого браузера или из другого устройства. Самое радикальное и действенное решение проблемы — сброс настроек маршрутизатора. Чтобы его сделать, найдите маленькую кнопку с подписью «Reset» нажмите её чем-то тонким и удерживайте в течение 5-15 секунд. Важно иметь в виду: минус этого решения в том, что вам придется настраивать роутер полностью заново.
Запуск и настройка на компьютере с Windows
Чтобы включить DHCP на ПК под управлением Windows 7 или Windows 10, нужно выполнить похожий набор действий.
Проверка службы
Чтобы включить службу DHCP клиент на ПК, или убедиться, что она работает, откройте «Выполнить» (Win+R), напишите «services. msc».
В открывшемся окне «Службы» найдите dhcp клиент, нажмите правой кнопкой и выберете «Свойства».
Если вы видите, что служба работает и запускается автоматически, ничего менять не нужно.
В случае отображения других параметров, запустите службу и поставьте автоматический запуск.
Настраиваем сетевой адаптер
Войдите в «Сетевые подключения» нажатием Win+R и вводом «ncpa. cpl».
Откройте свойства вашей сети, TCP/IPv4.
Выберете автоматическое получение IP адреса и адреса DNS-сервера, сохраните изменения.
Аналогичные манипуляции можно провести из командной строки. Открываем «Выполнить» (Win+R ), пишем «cmd».
Команда для установки IP адреса автоматически:
netsh interface ip set address «имя вашего подключения» dhcp
Команда для установки адреса DNS сервера автоматически:
netsh interface ip set dnsserver «имя вашего подключения» dhcp
Источники:
https://gb. ru/posts/klienty-poluchayut-nevernye-nastrojki-ip-adresa-po-dhcp
https://vr4you. net/59-configuring-dhcp-connection. html