как узнать какой dhcp сервер выдал адрес
Анализируем DHCP-сервер с помощью PowerShell
DHCP-сервер является важным компонентом ИТ-инфраструктуры в большинстве локальных сетей организаций. Давайте разберемся какие функции мониторинга DHCP может предоставить нам PowerShell. Для этого рассмотрим работу нескольких профильных командлетов.
Команды для управления DHCP-серверами на базе Windows являются частью модуля DhcpServer, к которому можно получить доступ установив RSAT для DHCP на Ваш ПК. Упомянутые здесь командлеты особенно полезны для анализа возникающих проблем.
Определение всех серверов и запрос их настроек
Первый шаг — получить список серверов, на которых в сети развернута служба DHCP. Это особенно важно для больших сред с несколькими DHCP-серверами. командлет Get-DhcpServerInDC как правило вызывается без параметров и в качестве выхлопа мы имеем IP адреса и Dns имена всех найденных DHCP серверов.
Однако для дальнейшего использования в других командах вы можете сохранить имена возвращенных серверов в переменной:
Как следует из названия, командлет возвращает список DHCP-серверов, зарегистрированных в Active Directory. Это означает, что вы не найдете мошеннических серверов DHCP, которые были подключены к сети без ведома ИТ-отдела.
Некоторые основные настройки DHCP-сервера, например, является ли он членом домена и авторизован, можно получить с помощью следующего запроса:
С помощью командлета Get-DhcpServerAuditLog вы можете узнать, было ли активировано ведение журнала для службы DHCP и где хранится файл журнала. Однако вы не можете отобразить содержимое журнала с помощью этой команды.
Командлеты для IPv4 и IPv6
Большинство функций модуля доступно в двух версиях. Все функции имеют в своих именах «4» или «6», что идентифицирует их принадлежность к IPv4 или IPv6 соответственно. Поэтому следующие примеры для IPv4 могут быть применены и к IPv6:
Чтобы получить статистику по службе DHCP IPv4 в целом, воспользуйтесь следующим командлетом:
Анализ диапазонов
Чтобы получить обзор наиболее важных данных для IPv4-областей DHCP-сервера, воспользуйтесь командлетом Get-DhcpServerv4ScopeStatistics
Если нам необходимо узнать какой процент диапазона уже используется и сколько адресов уже занято и доступно:
Свободные, арендованные и зарезервированные IP адреса
В этом примере перечислено 15 свободных адресов, начиная с 172.16.1.100
Возможно вам необходимо узнать, какие адреса и каким устройствам уже назначены:
Помимо свободных и уже назначенных IP адресов, обычно есть также зарезервированные для устройств с фиксированным IP. Их можно запросить следующим образом:
Если клиент не может получить адрес, проверьте, возможно он в списке запрещенных:
Модуль DhcpServer содержит в общей сложности 121 команду, которые не только запрашивает параметры и их состояние, но также могут выполнять настройки службы.
Курс по основам компьютерных сетей на базе оборудования Cisco. Этот курс поможет вам подготовиться к экзаменам CCENT/CCNA, так как за его основу взят курс Cisco ICND1.
9.2 Процесс получения IP-адреса по DHCP. DHCP-клиент и DHCP-сервер
Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей. Продолжаем разбираться с протоколом DHCP в рамках подготовки к CCNA. На этот раз мы посмотрим на процесс получения IP-адреса по DHCP, а также разберемся с тем как и при помощи каких сообщений происходит взаимодействие между DHCP-сервером и DHCP-клиентом.
9.2.1 Введение
Протокол DHCP, как и любой порядочный протокол, очень просто включается на устройствах, но внутри происходят довольно интересные процессы, о которых нужно знать и которые необходимо понимать на тот случай, если где-то что-то сломается, чтобы это что-то быстро починить. Давайте рассмотрим процесс получения IP-адреса по DHCP, а заодно разберемся со структурой DHCP сообщений и поговорим про алгоритм взаимодействия между клиентом и сервером по DHCP.
9.2.2 Упрощенный алгоритм взаимодействия DHCP-сервера и DHCP-клиента.
Сразу скажу, что сейчас мы разберем упрощенный алгоритм взаимодействия между DHCP-сервером и клиентом, мы не будем рассматривать специфичные случаи, а прикинемся, что работаем в идеальной сети, где нет никаких конфликтов, дублирований и проблем. В дальнейшем этот алгоритм мы будем расширять.
Первое и важное условие нормальной работы DHCP-сервера заключается в том, что он должен находиться в одной подсети/канальной среде с клиентом, иначе ничего работать не будет. В дальнейшем мы убедимся, что это не всегда так и если сервер и клиент находятся в разных подсетях, то им необходим посредник, который называется DHCP Relay Agent. Ну а теперь перейдем к алгоритму взаимодействия между клиентом и сервером по DHCP.
Схема действительно очень упрощена, здесь мы даже не рассмотрели ситуацию, когда предложенный IP-адрес уже занят другим устройством или то, как проверяется занятость IP-адреса перед тем как он будет предложен клиенту, но об этом речь пойдет ниже. Сейчас же предлагаю посмотреть на схему обмена сообщениями DHCP в тот момент, когда клиент пытается получить IP-адрес от сервера.
9.2.1 DHCP сообщения, которыми обмениваются клиент и сервер, когда клиент пытается получить IP-адрес
На этой схеме показаны DHCP пакеты, которыми будут обмениваться устройство в тот момент, когда клиент пытается получить IP-адрес от сервера в первый раз, на схеме не показаны сообщения, которые могут возникать при различного рода конфликтах. В общем, это идеальный случай, его вы будете встречать чаще всего.
9.2.3 DHCP-клиент и DHCP-сервер, базовая настройка.
Теперь нам нужно закрепить полученные знания о взаимодействие между DHCP-сервером и DHCP-клиентом на практике, для этого мы расчехлим Cisco Packet Tracer и соберем простую схему, которая показана ниже.
9.2.2 Схема сети для демонстрации взаимодействия между DHCP-клиентом и сервером
Вокруг этой схемы мы и будем плясать, в центре схемы находится обычный L2 коммутатор, в его настройки мы не лезем, поэтому можно смело утверждать, что все устройства в нашей сети находятся в одной канальной среде. К коммутатору подключен роутер, который будет выпускать наших клиентов в Интернет, его мы безбожно обозвали основной шлюз (про разницу между хабами, коммутаторами и роутерами можно почитать здесь). Также на схеме есть два DHCP-сервера, которые уже подключены к коммутатору и три клиента, из которых пока подключен только один.
Перед началом настройки схемы не забудьте переключить Cisco Packet Tracer в режим симуляции. Роутеру и двум серверам нужно будет назначить статический IP-адрес, так как здесь адреса ни при каких сбоях не должны измениться, роутер для клиентов является основным шлюзом, а DHCP-сервера источником настроек. Клиент должен получать настройки динамически.
9.2.3.1 Настройка протокола DHCP на сервере и клиенте в Cisco Packet Tracer
Покажу настройку только одного DHCP-сервера, на втором настройки должны быть идентичны, за исключением IP-адреса. Для начала назначим серверу IP-адрес вручную, сам себе сервер выдавать IP-адреса не умеет.
9.2.3 Настройки протокола IP на DHCP сервере
Серверу я не стал давать адрес шлюза по умолчанию, так как серверу не нужен доступ в Интернет, где найти IP настройки для устройств в Cisco Packet Tracer, вы уже должны знать, показывал и не один раз. Следующим пунктом нашей программы будет настройка DHCP на сервере. Для этого перейдите на вкладку Services и в левом меню выберете DHCP.
9.2.4 Настройки DHCP на сервере
Обратите внимание, здесь уже заполнены поля Start IP Address и Subnet Mask, мы же еще помним, что и клиент, и сервер должны находиться в одной канальной среде, чтобы было всё гуд. Когда мы назначили IP-адрес на интерфейс сервера, Cisco Packet Tracer сам назначил значения в эти поля за нас, если IP-адрес не назначать, то в этих полях будут унылые нули.
Предлагаю пока не трогать эти поля, а изменить значения у полей Pool Name и Default Gateway. Мои настройки показаны ниже.
9.2.5 Продолжаем настраивать DHCP сервер
Все изменения я выделил, для начала был включен DHCP при помощи чекбокса, затем я дал имя новому пулу IP-адресов, который сервер будет использовать для выдачи клиентам, а также была указана дополнительная опция в виде адреса шлюза по умолчанию. Чтобы пул был добавлен, следует нажать кнопку Add, после чего внизу у нас появится два пула IP-адресов: один – этот тот, что создали мы, второй – это тот, что был создан Cisco Packet Tracer автоматически. Чтобы не было проблем, удалите второй, для этого его нужно выделить и нажать на кнопку Remove, если не получится удалить автоматический пул, настройте его так, как я показал и удалите свой собственный. На втором сервере настройки нужно сделать аналогичными, разница будет только в IP-адресе, который вы назначите серверу.
Итак, что мы сделали, чтобы настроить DHCP-сервер, а сделали мы следующее:
Собственно, это всё, что нам сейчас необходимо. Сейчас мы сконфигурировали DHCP-сервер в режиме автоматической выдачи динамических IP-адресов, для нас этот режим самый интересный.
9.2.3.2 Настройки DHCP на клиенте
Настройка DHCP на клиенте гораздо проще, нужно только поставить галочку напротив «Получать IP-адрес по DHCP» и забыть про утомительный ручной труд.
9.2.6 Настройка протокола DHCP на клиенте
Фразы «Гибкая настройка» и Cisco Packet Tracer плохо совместимы, в реальных операционных системах вы сможете задать: какие параметры рабочая станция должна получить по DHCP, а какие параметры вы можете ввести своими руками. Но это нам сейчас не интересно, нам важно разобраться с тем, как клиент получает IP-адрес от DHCP сервера и это мы сделаем. Настройка протокола DHCP на клиенте на этом закончена.
9.2.4 Как клиент получает IP-адрес по DHCP
Схема собрана и настроена, теперь нам надо понять, как клиент получает IP-адрес по DHCP от сервера. В тот момент, когда вы завершите настройку DHCP на клиенте, машина поймет, что она не имеет IP-адрес, а также увидеть указание о том, что она должна получить этот IP-адрес по DHCP. Поэтому первое, что сделает DHCP-клиент – это сформирует запрос DHCPDISCOVER, которым попытается найти сервер.
9.2.7 Клиент сформировал сообщение DHCPDISCOVER
На зеленый пакет, сформированный сервером, не обращайте внимание. Нас интересует желтый пакет, который сформировал клиент, это и есть DHCPDISCOVER, давайте на него посмотрим.
9.2.8 Сообщение DHCPDISCOVER в Cisco Packet Tracer
Здесь сразу видно, что пртокол DHCP работает на прикладном уровне моделей OSI 7 и TCP/IP. Также тут видно, что клиент еще не разу не получал IP-адрес от сервера и даже не знает, где этот сервер находится. На транспортном уровне протокол DHCP инкапсулируется в UDP дейтаграммы, когда клиент делает запрос серверу, то в качестве порта источника он выбирает 68 порт, а в качестве порта назначения используется 67 порт.
Клиент не знает IP-адрес сервера, да и своего у него еще нет, поэтому на сетевом уровне в качестве IP-адреса источника он использует IP-адрес 0.0.0.0, а в качестве IP-адреса назначения используется 255.255.255.255. Мы видим, что это широковещательный запрос.
9.2.9 Структура пакета DHCPDISCOVER в Cisco Packet Tracer
А сейчас продолжим разбираться и посмотрим, что будет, когда запрос DHCPDISCOVER дойдет до серверов.
9.2.10 Запрос DHCPDISCOVER дошел до всех участников канальной среды
Здесь мы видим, что DHCPDISCOVER, посланный клиентом, дошел до всех участников канальной среды, что и не мудрено, ведь он широковещательный, но этот запрос оказался интересным только двум нашим DHCP-серверам. Когда сервер получил DHCPDISCOVER он понял, что в сети появился клиент, которому нужно выдать IP-адрес, сервер смотрит на пул IP-адресов, который у него есть и ищет свободный адрес, обычно это процесс упорядоченный и клиенту будет выдан первый свободный адрес из пула.
Но тут всё не так просто, дело в том, что компьютерная сеть – это то место, где изменения происходят очень быстро, поэтому прежде чем сформировать DHCPOFFER, сервер должен убедиться, что в сети еще не появился какой-нибудь негодяй, который уже начал использовать IP-адрес, который сервер решил выдать этому клиенту, а может случиться так, что другой сервер выдал выбранный адрес клиенту чуть раньше, это надо проверить.
ARP-запрос – это зеленый пакет, на котором нет значка паузы. Наши сервера настроены одинаково, базы данных у них сейчас одинаковые, поэтому и ARP-запросы они делают одинаковые, сам запрос показан ниже.
9.2.11 DHCP-сервер делает ARP запрос, чтобы проверить занятость IP-адреса
Тут мы видим, что наш первый сервер спрашивает всех соседей по канальной среде: у кого IP-адрес 192.168.0.1, я сервер с IP-адресом 192.168.0.2? Но, как мы помним, адрес 192.168.0.1 мы настроили на роутере, он уже занят. И ничего страшного, что этот адрес занят нашим маршрутизатором, маршрутизатор получит ARP-запрос и любезно на него ответит своим ARP-ответом, получив ответ, наши сервера поймут, что адрес 192.168.0.1 занят и нужно искать следующий адрес для выдачи.
В зависимости от реализации, после ARP-запроса, сервер может еще попробовать и попинговать IP-адрес 192.168.0.1, чтобы окончательно убедиться в том, что он занят. Такие проверки будут продолжаться до тех пор, пока DHCP-сервера не доберутся до IP-адрес 192.168.0.4 в своем пуле, ведь это первый адрес, который еще не используется в нашей сети, для этого адреса будет сформирован ARP-запрос, на который никто не ответит.
9.2.13 ARP-запрос от DHCP сервера, на который никто не ответит
Тут опять же, всё зависит от конкретного DHCP-сервера, ARP-запрос может быть повторен, а после него сервер может еще и попробовать опросить адрес по ICMP, все это нужно, чтобы убедиться, что адрес еще никто не занял, а только после этого формировать сообщение DHCPOFFER.
9.2.14 Сообщение DHCPOFFER от первого DHCP-сервера клиент уже получил, а от второго сервера OFFER еще в буфере коммутатора
На рисунке показано ниже, что сообщение DHCPOFFER широковещательное, хотя это бывает и не всегда так, тут учитывается два момента:
2.15 Сообщение DHCPOFFER в Cisco Packet Tracer
9.2.16 Внутренности пакета DHCPOFFER
Рисунок выше показывает, что при первом получении IP-адреса по DHCP в своем пакете сервер указывает свой IP-адрес, а в качестве адреса клиента используется 0.0.0.0. Поскольку это сообщение сформировано сервером, то порт источника 68, а порт назначения 67. Если сейчас заглянуть во внутренности пакета DHCPOFFER, то без всяких пояснений можно увидеть несколько интересных моментов.
Получив DHCPOFFER клиент не забирает себе IP-адрес, сперва он должен убедиться, что этот адрес еще никто не использует, для этого он делает ARP-запрос в сеть, в данном случае ему был предложен адрес 192.168.0.4, значит и спрашивать клиент будет: кто в сети использует адрес 192.168.0.4? Клиенты не используют ICMP для проверки, им это не надо, а вот серверам надо, в дальнейшем мы поймем – в каких ситуациях это действительно необходимо.
Если клиент не получит ARP-ответ на свой запрос, то он может смело соглашаться на предложение DHCP-сервера, при этом соглашаться он будет на предложение того сервера, от которого был получен первый DHCPOFFER. Если клиент получит ARP-ответ на свой запрос, то он отправит серверу сообщение DHCPDECLINE, в котором сообщит о том, что он отказывается от его предложения, если же ARP-ответа не будет, то клиент сформирует широковещательное сообщение DHCPREQUEST и отправит его. Таким образом все сервера поймут две вещи:
В процессе написания я столкнулся с еще одной странностью в Cisco Packet Tracer: после ARP-запроса клиент получил IP-адрес и на этом всё закончилось. Поэтому дальше только словесное описание, а потом мы его дополним дампами из Wireshark.
DHCP сервер, с которым клиент решил сотрудничать, тоже получит DHCPREQUEST и на этот REQUEST сервер должен будет выслать подтверждение в виде DHCPACK. Так сервер сообщает клиенту: пользуйся адресом на здоровье, я внес в свою базу данных информацию о том, что IP-адрес 192.168.0.4 закреплен за тобой. Сообщение DHCPACK может быть отправлено как адресно, так и широковещательно, чаще всего оно отправляется адресно.
Если в командной строке клиента сейчас выполнить команду ipconfig, то можно будет увидеть настройки, которые клиент получил от сервера.
Как узнать какой dhcp сервер выдал адрес
Добрый день! Уважаемые читатели и гости одного из популярнейших IT блогов Pyatilistnik.org. В прошлый раз мы с вами разобрали тему по отключению защитника Windows 8.1. Сегодня мы разберем интересную тему по системному администрированию, а именно, как и где посмотреть историю аренды IP-адресов на сервере DHCP в Windows. Я расскажу вам сценарии, при которых эти знания окажутся для вас весьма полезными и необходимыми, да и вообще инженеры очень редко смотрят и изучают логи DHCP сервера.
Постановка задачи
И так у вас развернут DHCP сервер на Windows. В какой-то момент вам потребовалось выяснить, кем был зарезервирован IP-адрес, например несколько дней назад. Когда у вас время аренды большое, это сделать проще, если настроено резервирование, то это еще проще, но мы рассмотрим, что у вас время аренды, пусть будет сутки и резервирования нет. Благодаря моей инструкции вы сможете вычислить компьютер и mac-адрес устройства, кто получал нужный нам ip-адрес.
Как найти историю аренды ip-адресов DHCP
Откройте оснастку DHCP, и откройте свойства вашего пула IPV6 или IPV6. Убедитесь, что у вас включена функция «Вести журнал аудита DHCP«, если нет то включаем ее.
На вкладке «Дополнительно» вы можете посмотреть куда сохраняется журнал с событиями сервера. По умолчанию, это C:\Windows\system32\dhcp.
Переходим в каталог C:\Windows\system32\dhcp. Тут будут нужные нам файлы DhcpSrvLog.log. таких файлов будет 7, на каждый день недели.
Открыв файл вам сразу выскочит подсказка по кодам событий:
Вот для примера, как выглядит продление аренды адреса.
Как найти DHCP серверы в сети?
Иногда при разборе чужой сети требуется определить насколько правильно работает сеть и нет ли там чужих DHCP серверов.
Делается это довольно просто. Для этого можно использовать небольшую утилиту RogueChecker.
Скачиваем, запускаем, видим такое окошко:
Нажимаем кнопку «Detect Rogue Servers» и в верхнем окне получаем список всех серверов, которые отозвались.
Если же клентский компьютер был введен в домен, то список авторизованных серверов появится в нижней части окна.
После первого поиска все найденные DHCP серверы будут считаться неизвестными. Утилита не сверяет найденные серверы со списком авторизованных в AD.
Если поставить галочку в столбце «Valid DHCP Servers» напротив нашего правильного сервера, то программа будет его считать авторизованным, и больше не будет рисовать красный кружочек с восклицательным знаком около него. Это сделано для удобства просмотра и поиска «левых» DHCP серверов в сети. Иконка в трее меняется, если обнаружен неизвестный DHCP сервер: 
Также программу можно использовать для автоматического вылавливания периодически появляющихся DHCP серверов.
Для этого надо зайти во вкладку Configuration и установить настройки, как часто делать поиск DHCP серверов. В данном примере я поставил проверку на каждые 5 минут.
Также в этом окне можно выбрать через какие сетевые карты делать поиск серверов (при условии, что сетевых карт несколько в этом компьютере).