Найти информацию для локального IP-адреса?

Недавно мы посетили инженера BT, пытаясь решить проблему с нашей системой IP-телефонии.

Они отметили, что у нас в сети работает четыре DHCP-сервера. Я отключил два из них (один из них должен быть запущен) и проверил все работает как надо. Однако четвертый DHCP-сервер ускользает от меня!

Устройство имеет IP-адрес 192.168.1.59, я могу успешно пропинговать IP-адрес.

Если я запускаю 'nbtstat -a 192.168.1.59', я получаю следующий результат:

$ nbtstat -a 192.168.1.59
$ Local Area Connection:
$ Node IpAddress: [192.168.1.45] Scope Id: []
$ Host not found.

Если я запускаю RDP или VNC Viewer для IP-адреса, они не подключаются.

Есть ли другой способ узнать больше об устройстве?

Nmap отлично подходит для этого. Помимо сообщения о том, какие порты прослушивает сервер (чего часто достаточно для идентификации его операционной системы), он также может выполнять дактилоскопию ОС, что обычно довольно хорошо. Дактилоскопия ОС часто может даже идентифицировать модели принтера.

Пытаться nmap -A -v 192.168.1.59

Вы можете проверить свои таблицы arp для MAC-адреса, который в UNIX делается с

arp -a -n | grep 192.168.1.59

Я предполагаю, что у Windows есть аналог.

Затем вы можете сопоставить первые три октета MAC-адреса с поиском идентификации поставщика, которых много в сети. Один такой здесь (я ничего не знаю об этом, он просто появился первым в поиске Google). Это должно сказать вам, кто сделал элемент оборудования, который часто помогает в его идентификации.

Если у вас есть управляемые коммутаторы, вы можете также связать этот mac-адрес с связующим деревом на коммутаторе, который скажет вам, на каком порту коммутатора этот MAC-адрес отображается, что часто идентифицирует отдельный кабель, на котором есть устройство на другом конце. , Как разговаривать с вашим управляемым коммутатором, зависит от того, кто его сделал, и выходит за рамки простого ответа SF. В этих случаях это самый быстрый метод поиска блока, но он требует некоторых сетевых умов и управляемых коммутаторов.

В противном случае вы можете попробовать использовать telnetизвестные порты; Я часто пробую 139 (установление соединения означает, что это либо Windows-бокс, либо Unix-бокс с SaMBa), 22 (баннер ssh может дать подсказки производителю) и 80 (если запущен веб-сервер, ввод текста GET /<CR><CR>часто возвращает полезное текст ошибки.

Похоже, ваш вывод nbtstat указывает на то, что устройство не является хостом Windows. Это может быть маршрутизатор, коммутатор, брандмауэр, WAP и т. Д.?

Кроме того, не должно быть ничего плохого в работе нескольких серверов DHCP, если они настроены правильно и не имеют перекрывающихся областей.