Как найти второй DHCP-сервер в сети: Wireshark, Nmap и поиск порта коммутатора

В сети периодически меняются шлюз или DNS, компьютеры получают адреса чужой подсети либо часть пользователей теряет доступ? Одной из причин может быть дополнительный DHCP-сервер: домашний роутер, виртуальная машина или ошибочно настроенная служба. Но два ответа ещё не доказывают нарушение — это может быть штатная отказоустойчивая схема.

Задача администратора: увидеть ответы, определить Server Identifier, связать источник с оборудованием и подтвердить его назначение. Ниже — диагностика DHCPv4 в своей сети с Wireshark и Nmap. Захваты выполняйте с разрешения владельца сети; файлы могут содержать внутренние адреса и сведения клиентов.

1. Сначала определить VLAN и ожидаемые серверы

Запишите VLAN, подсеть, интерфейс клиента и разрешённые DHCP-серверы. Уточните наличие relay, отказоустойчивой пары и сетевых устройств, выдающих адреса. Проверка в одной VLAN не обследует автоматически остальные сегменты.

На Windows посмотрите текущую аренду:

ipconfig /all

Для нужного адаптера запишите IPv4, маску, DHCP Server, Default Gateway, DNS Servers и время аренды. Поле DHCP Server показывает сервер выбранной аренды, а не перечень всех отвечающих серверов. Команда описана в справочнике Microsoft.

Не считайте адрес из другой подсети автоматически подозрительным: при DHCP relay сервер может находиться вне VLAN клиента. Сравнивайте с утверждённой схемой.

2. Подготовить тестовый клиент и захват

Выберите рабочую станцию в проблемном сегменте, к которой есть локальный доступ. Установите Wireshark с компонентом захвата и выберите физический адаптер, через который клиент подключён к исследуемой VLAN. VPN-адаптер и соседний интерфейс дают другой набор пакетов.

Задайте capture filter перед запуском захвата:

udp port 67 or udp port 68

Затем начните захват. Capture filter определяет, что сохраняется; display filter только скрывает часть уже записанных пакетов. Настройка захвата и фильтрации описана в руководстве Wireshark.

Обычный порт коммутатора не видит весь unicast-трафик соседних клиентов. Для своего DHCP-обмена этого достаточно; для чужого обмена может потребоваться согласованное зеркалирование порта. Не включайте SPAN наугад на нагруженном коммутаторе.

3. Как получить новый Discover на тестовом клиенте

Простое /renew может продлить существующую аренду через уже известный сервер, поэтому несколько DHCP-серверов не обязательно проявятся. Для нового цикла на тестовом клиенте используйте освобождение и получение адреса.

Уточните имя адаптера в ipconfig. Пример для адаптера Ethernet:

ipconfig /release "Ethernet"
ipconfig /renew "Ethernet"

/release временно лишает адаптер адреса и может оборвать удалённую сессию. Делайте это локально на тестовом устройстве, не на сервере или рабочем компьютере, через который ведётся обслуживание. Не освобождайте сразу все адаптеры.

Дождитесь завершения попытки, остановите захват и сохраните pcapng. Если компьютер использует статический адрес, этот сценарий получения DHCP к нему не относится. Если Discover не виден, проверьте выбранный интерфейс и порядок запуска захвата.

4. Как найти DHCP Offer и сравнить серверы

Для актуального Wireshark используйте display filter:

dhcp.option.dhcp == 2

Он показывает Offer. Для Discover используйте значение 1, для ACK — 5. Имена полей dhcp относятся к современной версии Wireshark; в старых инструкциях встречается bootp. Точные поля проверяйте по Display Filter Reference.

Выберите Offer и раскройте DHCP options. Сравните Option 54 Server Identifier, предложенный адрес, Option 3 Router и Option 6 DNS. Отдельно запишите Transaction ID и MAC клиента, чтобы не смешать предложения для разных запросов.

Два Offer для одного Discover с разными идентификаторами — основание исследовать оба сервера. Но сначала сопоставьте их с разрешённой схемой: штатный failover тоже может участвовать в распределении адресов. Предложение неожиданного шлюза или DNS — сильный диагностический признак, но требуется подтверждение владельца оборудования.

5. Как выгрузить адреса Offer через tshark

Для сохранённого захвата можно получить короткую выборку без ручного просмотра каждого пакета:

tshark -r dhcp-test.pcapng -Y "dhcp.option.dhcp == 2" -T fields \
  -e frame.time -e dhcp.id -e ip.src -e eth.src \
  -e dhcp.option.dhcp_server_id

Пример выше использует перенос строк shell в Linux. В PowerShell выполните команду одной строкой:

tshark -r dhcp-test.pcapng -Y "dhcp.option.dhcp == 2" -T fields -e frame.time -e dhcp.id -e ip.src -e eth.src -e dhcp.option.dhcp_server_id

Здесь dhcp-test.pcapng — ваш файл. Каждая строка относится к одному Offer. Сопоставляйте идентификатор транзакции и интерфейс захвата; повторные пакеты не означают дополнительные серверы.

Для ACK замените фильтр на dhcp.option.dhcp == 5. Сравнение Offer и ACK позволяет понять, чьё предложение клиент действительно принял. Самое быстрое Offer не всегда описывает итог выбранной аренды.

Не трактуйте eth.src как универсальный MAC DHCP-сервера: при relay это может быть MAC промежуточного устройства. Server Identifier и Ethernet-источник отвечают на разные вопросы.

6. Как выполнить активную проверку Nmap

С тестового Linux-узла в нужном сегменте можно отправить DHCP Discover через NSE-скрипт. Сначала определите интерфейс командой ip link и замените eth0 своим именем:

ip link
sudo nmap --script broadcast-dhcp-discover -e eth0

Скрипт получает предложение и выводит DHCP-параметры; особенности и настройки описаны в официальной документации Nmap. Не переносите команду на чужие сегменты и не запускайте непрерывно: активные запросы могут создавать записи аренды и нагрузку.

Результат зависит от интерфейса, доступности сервера и времени ответа. Отсутствие подозрительного ответа в одном запуске не доказывает, что сервер никогда не появляется. Для периодического сбоя полезнее согласованное наблюдение на проблемном клиенте или зеркальном порту.

7. Как проверить список авторизованных DHCP в Active Directory

На административной Windows-станции с модулем DhcpServer и необходимыми правами:

Get-DhcpServerInDC

Команда возвращает DHCP-серверы, авторизованные в AD, а не всех отвечающих в конкретной VLAN. Назначение команды — в документации Microsoft.

Сопоставьте список с Server Identifier из захвата. Домашний роутер или другой DHCP-сервис может отвечать независимо от авторизации Windows DHCP в AD. Не удаляйте запись авторизации как способ остановить неизвестный сервер: сначала установите, что это за устройство и как оно выдаёт адреса.

Старая утилита RogueChecker из первоначальной статьи больше не является основой инструкции. Пометка сервера как «valid» в диагностической программе не делает его авторизованным в AD и не изменяет сетевую политику.

8. Как найти физический порт по MAC-адресу

Если сервер находится в том же L2-сегменте, сопоставьте его адрес и MAC с захватом и таблицами ARP/FDB. На MikroTik можно посмотреть записи:

/ip arp print detail
/interface bridge host print where mac-address=02:11:22:33:44:55

MAC 02:11:22:33:44:55 — пример, подставьте фактический. Обратите внимание на bridge, on-interface и VID. Если MAC изучен через uplink, перейдите на следующий коммутатор и повторите поиск. Запись FDB указывает направление до устройства, а не обязательно порт его непосредственного подключения.

При DHCP relay сначала определите relay по giaddr и схеме. MAC на клиентской стороне может вести к маршрутизатору, а не серверу. При виртуализации MAC может принадлежать виртуальной машине: продолжите поиск через vSwitch и инвентаризацию гипервизора.

Не отключайте uplink только потому, что на нём обнаружен подозрительный MAC. Таблицы и особенности VLAN в bridge — в документации MikroTik.

9. Как устранить причину и не отключить штатный сервис

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

Если источник легитимный, исправьте scope, relay или выдаваемые options. Несколько серверов с противоречащими шлюзами не всегда означают злоумышленника: возможна ошибка внедрения.

Для профилактики рассматривают DHCP snooping с доверенными uplink/relay-портами и недоверенными клиентскими портами. Но включение зависит от модели коммутатора, VLAN и аппаратной обработки; неверная trust-настройка блокирует штатную выдачу. На MikroTik отдельный разбор — в статье о защите от чужих DHCP.

10. Как проверить результат и задокументировать инцидент

Повторите новый DHCP-цикл на тестовом клиенте, сохраните контрольный захват и сравните Offer/ACK с ожидаемыми серверами. Проверьте адрес, шлюз, DNS и доступ к приложениям. Для периодической проблемы повторите наблюдение в согласованный интервал.

Существующие клиенты могут сохранять старые параметры до обновления аренды. Планируйте их обновление отдельно, не выполняйте массовый release по всей сети. После исправления положительный результат одного клиента не подтверждает состояние всех VLAN.

В отчёте укажите VLAN, время, Server Identifier, MAC с учётом relay, цепочку коммутаторов, порт, владельца и выполненное изменение. DHCPv6 и Router Advertisement требуют отдельной диагностики: обнаружение DHCPv4 не закрывает эти механизмы. За помощью в сетевой диагностике обратитесь в АВАНГАРД ИТ.