Подскажите пжлст как как решить задачу программного выявления в сети устройств для дальнейшего управления ими. Фактически имеем клиента, который не знает по какому адресу находится сервер. Нужно, чтобы сервер давал возможность клиентам узнавать свой адрес. Научите как. Заранее спасибо
Здравствуйте, Infineon, Вы писали:
I>Подскажите пжлст как как решить задачу программного выявления в сети устройств для дальнейшего управления ими. Фактически имеем клиента, который не знает по какому адресу находится сервер. Нужно, чтобы сервер давал возможность клиентам узнавать свой адрес. Научите как. Заранее спасибо
Клиент и сервер находятся в одной подсети? Если да, то клиент может спросить броадкастом о сервере.
Здравствуйте, Infineon, Вы писали:
I>Подскажите пжлст как как решить задачу программного выявления в сети устройств для дальнейшего управления ими. Фактически имеем клиента, который не знает по какому адресу находится сервер. Нужно, чтобы сервер давал возможность клиентам узнавать свой адрес. Научите как. Заранее спасибо:)
Здравствуйте, Infineon, Вы писали:
I>Нужно, чтобы сервер давал возможность клиентам узнавать свой адрес. Научите как. Заранее спасибо
Broadcast'ы. И лучше сразу взять фреймворк типа Avahi.
Здравствуйте, Infineon, Вы писали:
I>Подскажите пжлст как как решить задачу программного выявления в сети устройств для дальнейшего управления ими. Фактически имеем клиента, который не знает по какому адресу находится сервер. Нужно, чтобы сервер давал возможность клиентам узнавать свой адрес. Научите как. Заранее спасибо
Бродкасты — сразу нет. Не в каменном веке, слава богу.
Смотреть в сторону (перечисляю в порядке приоритета):
SLP
UPnP
DNS SRV records
multicast запросы
AC>Не могли бы Вы поподробнее рассказать, чем плохи бродкасты (кроме распространения лишь по одному сегменту сети)?
Ну вообще-то распространение лишь под одному сегменту сети это самый большой минус. Один сегмент есть только у совсем мелких организаций, либо у организаций где очень неграмотные люди сидят. Современная сеть всегда резана на кучу VLAN'ов в зависимости от функций ПК, включенных в тот или иной VLAN. Есть опять же VPN туннели между удаленными офисами, а не все средства построения VPN туннелей умеют расширять бродкастовый домен.
Кроме того, бродкасты создают заметную нагрузку на сеть, а небольшая ошибка в настройке маршрутизации просто положит всю сеть намертво.
Ну и последнее — системы основанные на бродкаст/мультикаст запросах обладают нулевой безопасностью — плодотворная почва для атак типа человек-по-середине.
Да и до кучи сам механизм: запросили, подождали, еще запросили, еще подождали (но уже больше) — вызывает неприятие у пользователя, потому что процесс "висит" (например, сетевое окружение в MS).
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, Infineon, Вы писали:
I>>Подскажите пжлст как как решить задачу программного выявления в сети устройств для дальнейшего управления ими. Фактически имеем клиента, который не знает по какому адресу находится сервер. Нужно, чтобы сервер давал возможность клиентам узнавать свой адрес. Научите как. Заранее спасибо:)
DOO>Бродкасты — сразу нет. Не в каменном веке, слава богу. DOO>Смотреть в сторону (перечисляю в порядке приоритета): DOO>SLP DOO>UPnP DOO>DNS SRV records DOO>multicast запросы
И по любому это будет начинаться с того, что устройство захочет получить IP адрес, а это минимум мультикаст, а то и бродкаст. А потом ещё несколько запросов, уже к тому, кто отвечал на первый запрос (или к кому он переадресовал). Так нафига такие мучения, если можно просто выбрать мультикастового получателя и послать ему запрос, на который будет один ответ со всеми данными?
Здравствуйте, DOOM, Вы писали:
DOO>Ну и последнее — системы основанные на бродкаст/мультикаст запросах обладают нулевой безопасностью — плодотворная почва для атак типа человек-по-середине.
Чушь несёте, коллега. Они ровно в той же мере безопасны, насколько весь Ethernet. Если нет защиты от анонса чужих MAC, от подписки на неразрешённые мультикаст-группы — никакой безопасности на сегменте от посторонних нет в принципе. В условиях, когда устройство начинает свою работу с того, что запрашивает "а кто мне выдаст IP?" — защиты нет. Хотите защиты? Тотальный 802.1x + IGMP security. Или же клиент пусть сразу хранит сертификат сервиса, тогда можно игнорировать всех MITM — они разве что процессор пригрузят. Но это уже, насколько я понимаю, за пределами контекста треда.
DOO>Да и до кучи сам механизм: запросили, подождали, еще запросили, еще подождали (но уже больше) — вызывает неприятие у пользователя, потому что процесс "висит" (например, сетевое окружение в MS).
N>И по любому это будет начинаться с того, что устройство захочет получить IP адрес, а это минимум мультикаст, а то и бродкаст. А потом ещё несколько запросов, уже к тому, кто отвечал на первый запрос (или к кому он переадресовал).
Ну DHCP это хотя бы стандарт, минусы которого уже более-менее устранены разными методами.
N>Так нафига такие мучения, если можно просто выбрать мультикастового получателя и послать ему запрос, на который будет один ответ со всеми данными?
Из этого предложения не очень понятно кто кому и куда запрос шлет, но я понял, что упустил еще один вариант (вообще говоря, тоже неплохой) — своя опция DHCP.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, DOOM, Вы писали:
DOO>>Ну и последнее — системы основанные на бродкаст/мультикаст запросах обладают нулевой безопасностью — плодотворная почва для атак типа человек-по-середине.
N>Чушь несёте, коллега. Они ровно в той же мере безопасны, насколько весь Ethernet.
Не надо таких громких заявлений — для Ethernet'а в целом и некоторых не очень удачных протоколов в частности давно существует масса воркэраундов, чтобы минимизировать риски.
N>Если нет защиты от анонса чужих MAC,
port security — есть почти везде.
N>от подписки на неразрешённые мультикаст-группы
Это реже (просто в силу некоторой экзотики использования мультикаст, до сих пор), но возможности-то также есть.
N>В условиях, когда устройство начинает свою работу с того, что запрашивает "а кто мне выдаст IP?" — защиты нет.
Это еще почему? Если коммутаторы знают кто тут DHCP, то левому чувачку они не позволят сервером прикинуться. Я же говорю — для всех стандартных протколов костылей понаделали. А новые уж лучше делать грамотно.
N>Хотите защиты? Тотальный 802.1x + IGMP security.
Тоже неплохо, но нередко невыполнимо.
N>Или же клиент пусть сразу хранит сертификат сервиса, тогда можно игнорировать всех MITM — они разве что процессор пригрузят. Но это уже, насколько я понимаю, за пределами контекста треда.
Это да.
DOO>>Да и до кучи сам механизм: запросили, подождали, еще запросили, еще подождали (но уже больше) — вызывает неприятие у пользователя, потому что процесс "висит" (например, сетевое окружение в MS). N>Я ж говорю — всё одним запросом надо получать.
Даже DHCP запрашивается несколько раз со все более удлиняющимся промежутком. Но тут еще простая ситуация — надо хоть один ответ получить, а вот поиск браузеров MS или SLP Directory Agents — уже хуже, здесь надо получить ответ от всех — поэтому и идет 3-4 запроса + период ожидания между ними.
Здравствуйте, DOOM, Вы писали:
N>>Чушь несёте, коллега. Они ровно в той же мере безопасны, насколько весь Ethernet. DOO>Не надо таких громких заявлений — для Ethernet'а в целом и некоторых не очень удачных протоколов в частности давно существует масса воркэраундов, чтобы минимизировать риски.
Безусловно. И в таком случае секьюрен и мультикаст-запрос.
N>>В условиях, когда устройство начинает свою работу с того, что запрашивает "а кто мне выдаст IP?" — защиты нет. DOO>Это еще почему? Если коммутаторы знают кто тут DHCP, то левому чувачку они не позволят сервером прикинуться. Я же говорю — для всех стандартных протколов костылей понаделали. А новые уж лучше делать грамотно.
Только вот это "грамотно" в стиле SLP+UPnP+хрень_рогатая — чрезмерно.
Здравствуйте, Michael Chelnokov, Вы писали:
MC>Здравствуйте, DOOM, Вы писали:
DOO>>не все средства построения VPN туннелей умеют расширять бродкастовый домен.
MC>А мультикаст, значит, проходит везде? Ню-ню...
Обращаю внимание, что мультикаст я привел как наименее привлекательный вариант из всех перечисленных. А поддержка мультикастовой маршрутизации есть уже почти во всех сетевых устройствах.
Здравствуйте, DOOM, Вы писали:
DOO>Обращаю внимание, что мультикаст я привел как наименее привлекательный вариант из всех перечисленных. А поддержка мультикастовой маршрутизации есть уже почти во всех сетевых устройствах.
Уточните, пожалуйста: каким образом, например, в D-Link или Planet маршрутизаторе (беру наиболее распространённые) я могу включить DVMRP или PIM-SD?
А заодно, каким образом (или предметом, похожим на свечку;)) включить выборочный бродкаст на, например, Cisco 38xx. (DHCP relay не вспоминаем, это частный случай.)
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, netch80, Вы писали: N>>Только вот это "грамотно" в стиле SLP+UPnP+хрень_рогатая — чрезмерно. DOO>Зависит от задачи. Между прочим, UPnP ты первый предложил ;)
Да, но без SLP и рогатых хреней.
DOO>А SLP штука хорошая, жаль малораспространенная из-за слабой поддержки MS'ами...
Я что-то вообще её нигде не видел.
DOO>Вообще для простого случая действительно лучше всего DHCP опция...
N>Уточните, пожалуйста: каким образом, например, в D-Link или Planet маршрутизаторе (беру наиболее распространённые) я могу включить DVMRP или PIM-SD?
Ниче себе распространенные
N>А заодно, каким образом (или предметом, похожим на свечку) включить выборочный бродкаст на, например, Cisco 38xx. (DHCP relay не вспоминаем, это частный случай.)
Выборочный бродкаст? Ты что под этим понимаешь?
А вообще на 38-й серии что только не включишь — главное IOS нужный купи
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, netch80, Вы писали: N>>>Только вот это "грамотно" в стиле SLP+UPnP+хрень_рогатая — чрезмерно. DOO>>Зависит от задачи. Между прочим, UPnP ты первый предложил
N>Да, но без SLP и рогатых хреней.
Ну я же тоже не все вместе реализовывать предложил, а на выбор — SLP, UPnP вещи довольно похожие...
N>Я что-то вообще её нигде не видел.
Его любит Novell и Sun.
Открытая реализация под Linux — OpenSLP.
