В этой статье я расскажу, как потратил время на решение такого тривиального на первый взгляд вопроса, как выяснение IP-адресов приборов в существующей сети при наличии такого маленького нюанса, как полное отсутствие данных по IP-адресации в этой сети. Что на этом пути удалось выяснить, как мучился с микротиком и какой же в итоге ответ на поставленный в заголовке вопрос. Ну и, естественно, как полученный опыт был воплощён в программном обеспечении А2Тех. В конце статьи предложу наиболее оптимальный, на мой взгляд, алгоритм решения задачи нахождения IP-адресов в неизвестной сети.
Следует оговориться, что одно из существенных отличий промышленных сетей от офисных в России на сегодняшний день состоит в том, что в них (промышленных сетях) редко применяются управляемые коммутаторы, из которых можно было бы через консольный кабель вычитать ARP-кэш и тем самым решить хотя бы часть проблемы – узнать, в каких подсетях находятся интересующие нас девайсы.
Приступим.
Стандартная ситуация: наладчик приезжает на очередной объект адресного списка с задачей подключить контроллеры и коммуникационные устройства к системе диспетчеризации. Только а) объект в работе, и любые действия, которые могут привести к перезагрузке контроллера или к сбоям в его работе, запрещены б) документация, из которой можно было бы узнать IP-адрес контроллера, отсутствует. Как и в принципе отсутствует документация на АСУТП (то есть разделы АК/АТМ/АТХ/МО/ПО и т.д.). М-да. Как тебе такая задачка, Илон Маск? Собственно, после такого описания задачи любой здравомыслящий наладчик скажет: Разворачиваемся и уходим. И статью эту читать дальше нет смысла.
Но, оглядываясь назад, я понимаю, что причислять себя к сообществу здравомыслящих людей я не вправе, поэтому не обременён подобными комплексами. Если Вы дочитали до этого места, то осмелюсь предположить, что Вы тоже любите решать нетривиальные задачи, особенно если Родина в этом нуждается. Думаю, Вы тоже из тех людей, которые считают, что быстро включенный-отключенный резервный сетевой насос не считается запущенным (особенно если диспетчер этого не заметил), зато даёт почти полную информацию о схеме шкафа управления этими насосами. И быстро выткнутый-воткнутый ethernet-кабель не считается обрывом связи, зато даёт точное понимание, откуда и куда он идёт.
Ладно, накидываем кажущиеся перспективными идеи и дальше по каждой из них пройдёмся подробнее:
- Можно всё-таки подключиться к ПЛК через последовательный порт для программирования и выкачать программу, проанализировать её и выяснить сетевые настройки. Вариант интересный, но трудоёмкий – найти кабель, поставить софт (как Вы, полагаю, уже поняли из контекста, речь идёт про десятки объектов с разными контроллерами, на каждый нужно ещё найти этот софт, разобраться, как в нём работать, найти нужный кабель, в общем, долго это всё). В будущем я планирую написать статью про все контроллеры, с которыми я таким образом работал, чтобы сконсолидировать этот опыт.
- Можно выполнить сетевой поиск контроллера утилитами от производителя контроллера. Не потребуется выкачивать программу, но опять-таки нужно скачать софт.
- Просто подключиться конфигуратором к ПЛК или другому девайсу (так же, как через консольный порт к маршрутизатору Cisco или Microtik) через конфигурационный COM-порт и выкачать конфигурацию, из которой узнаем сетевые настройки.
- Помониторить сеть роутером (MikroTik, например). В надежде, что до роутера будут долетать какие-нибудь пакеты, в которых будут указаны IP-адреса контроллеров.
- Помониторить сеть при помощи ПК. То же самое, что предыдущий пункт, только софт другой.
- Помониторить трафик между устройствами сниффером, роль которого будет играть нужным образом настроенный роутер (в режиме бриджа).
- Помониторить трафик между устройствами сниффером, роль которого будет играть нужным образом настроенный ПК (так же, как и роутер в предыдущем пункте, то есть в режиме бриджа).
- Помониторить трафик между устройствами сниффером, роль которого будет играть никак не настроенный ПК с программой-сниффером Ethernet_connect_r.Sniffer от А2Тех.
- Выполнить сканирование сети с ПК программой-сканером сети.
- Выполнить сканирование сети с роутера.
- А если тупо воткнуться в сетевой порт контроллера и wireshark-ом посмотреть, что будет?
- А может, есть протокол, который позволяет по известному MAC-адресу узнать IP-адрес?
Итак, подробнее о каждом варианте.
8. Помониторить трафик между устройствами сниффером, роль которого будет играть никак не настроенный ПК с программой-сниффером Ethernet_connect_r.Sniffer от А2Тех
Берём ПК с двумя сетевыми адаптерами (специальная настройка адаптеров не требуется, у них могут быть любые IP-адреса и другие настройки сети). Запускаем программу Ethernet_connect_r.Sniffer, настраиваем как на скриншоте:
Жмём start_mon, полминуты наблюдаем, как бегут пакеты:
Потом в паке программы находим файл .pcap, открываем его в WireShark и видим пакеты трафика между устройствами в удобной форме:
11. А если тупо воткнуться в сетевой порт контроллера и wireshark-ом посмотреть, что будет?
Если Вам повезло и реализация TCP-стека в устройстве полноценная, то при включении устройства оно будет выплёвывать в сеть ARP-пакеты, называемые ARP probe (могут также быть ARP Announcement, Gratuitous ARP – сути дела не меняет):
На скриншоте такие пакеты выплёвывает контроллер Twido. Редкая удача на самом деле, потому что задача выяснения IP-адреса контроллера в этом случае решается за 2 минуты. И я имею в виду буквально 2 минуты – минуту мониторим, минуту пингуем контроллер, чтобы убедиться, что это он, периодически подключаясь к другим устройствам и убеждаясь, что при этом пинги пропадают. Если не пропадают пинги – значит, Вы пингуете свой собственный сетевой адаптер и даже не знали, что у него есть такой IP-адрес, который Вы увидели в WireShark-е. На примере, представленном в скриншоте, мой ПК имеет адреса 10.10.200.221 и 1.1.1.251, поэтому отличить новый адрес 10.50.19.18 от собственных адресов Ethernet-адаптера моего ПК труда не составило.
Если Ваша винда валит слишком много пакетов, то можно применить дисплейный фильтр “ARP”:
Не рекомендую в данном случае применять фильтры захвата – можно отфильтровать и не сохранить ту часть трафика, которая впоследствии может оказаться ценной. Лучше писать всё без разбора, а фильтровать уже дисплейными фильтрами.
Вывод – вариант классный и рабочий, но для 60% отечественных промышленных девайсов не подходит, потому что они при включении сами не рассылают широковещательных пакетов со своим IP-адресом, ибо незачем потенциальным вредителям в лице наладчиков его знать.
12. А может, есть протокол, который позволяет по известному MAC-адресу узнать IP-адрес?
Согласитесь, логичный вопрос. На корпусе почти всех девайсов набит MAC-адрес. Это наводит на мысль, что есть какой-то способ узнать IP девайса по его MAC-у. И таки есть такой протокол, мои дорогие детишечки! Называется он inverse ARP. Работает, в отличие от обычного ARP, в обратную сторону – позволяет узнавать IP-адрес девайса по известному MAC-адресу. Этот протокол реализован в программе Protocols_analyzer_v3.5. Однако, к моему глубокому разочарованию, итогом реализации этого протокола в программе стало выяснение того факта, что inverse ARP существует только в теории в виде описания RFC. Ни один из опрошенных мной девайсов не ответил на запрос в формате inverse ARP.
Читал в сети, что inverse ARP работает в сетях Frame Relay, но я не знаю, что это за сети. Более того, знающие люди пишут, что RARP (reverse ARP) не поддерживается в Winwows, из чего можно предположить, что и inverse ARP тоже:
https://www.atraining.ru/arp-inarp-rarp-proxy-gratuitous-dai-sticky-and-more/
Вывод: вариант нерабочий. А жаль, он казался таким очевидным и логичным…
Свежие комментарии