Windows 7 не принимает трансляции с ip-адреса 0.0.0.1

у нас есть небольшие сетевые устройства, которые поставляются с IP-адресом 0.0.0.1, чтобы гарантировать, что они никогда не конфликтуют с любым другим устройством в их новой среде (таким образом, ни один из 10.x.x.x, 172.16.x.x или 192.168. диапазоны x.x) до настройки. DHCP не является решением, так как DHCP-сервер может отсутствовать в поле.

Устройства будут прослушивать широковещательные сообщения UDP и отвечать широковещательными сообщениями до тех пор, пока таким образом им не будет присвоен новый IP-адрес.

Это отлично работало с Windows XP, но не с Windows 7: программа конфигурации не получает пакеты ответов от устройств, у которых все еще есть 0.0.0.1. Wireshark видит пакеты, потом система сбрасывает их.

Вопрос. Есть ли какая-либо причина (RFC?), фактически запрещающая использование этого адреса в локальной среде? Или это просто MS, который был слишком осторожен? Где я могу прочитать, почему этот адрес считается недействительным? Какие диапазоны теперь также действительно "недействительны"?

Любая идея обходного пути на стороне ПК (Win 7)?

Я знаю, что не рекомендуется использовать адреса 0.xxx для рабочих мест, но именно по этой причине - имея неиспользуемый адрес - он отлично работает.

Редактировать: есть устройство под названием «Netburner», которое, согласно их форуму, могло столкнуться с подобной проблемой. См.: http://forum.embeddedethernet.com/viewtopic.php?f=5&t=612&p=2198 Кто-нибудь случайно знает какую-нибудь справочную информацию?


networking ip-address broadcast windows-7
person Ingmar    schedule 01.02.2011    source источник
comment
У вас есть эта подсеть в конфигурации вашей сетевой карты? Многие системы будут отбрасывать широковещательные пакеты, поступающие из нелокальной подсети.   -  person thkala    schedule 01.02.2011
comment
Не могли бы вы вместо этого переключиться на использование широковещательных пакетов Ethernet? Казалось бы, удаление всего стека маршрутизации TCP/IP было бы преимуществом.   -  person sarnold    schedule 01.02.2011
comment
@thkala: мы это проверим. спасибо за подсказку. Тем не менее - RFC1918 позволяет использовать любой ip-адрес локально, только не рекомендуют из-за недостатков.   -  person Ingmar    schedule 01.02.2011
comment
@minastaros: под нелокальными я подразумеваю подсети, которые не находятся в той же подсети, что и ваш компьютер. Блокирование таких трансляций имеет смысл с точки зрения безопасности.   -  person thkala    schedule 01.02.2011
comment
@sarnold: о, устройства уже некоторое время находятся в эксплуатации. Таким образом, переключение будет не таким простым, новое программное обеспечение Win 7 для ПК должно иметь возможность работать со старыми (= текущими) устройствами ... Что именно вы имеете в виду, какой-то пинг ARP?   -  person Ingmar    schedule 01.02.2011
comment
@minastaros, о, они уже развернуты? Тогда широковещательные передачи Ethernet не будут работать так хорошо. Я думал о настройке группы широковещательной передачи Ethernet, чтобы ваши устройства транслировались в нее, а ваше управляющее приложение подписывалось на эту группу широковещательной рассылки. Когда они получают ответ, они могут напрямую ответить устройству командой, чтобы перевести маленькое устройство в IP-землю после согласования IP-адреса с локальными серверами DHCP/bootp. Но если они уже развернуты, то немного поздно. :)   -  person sarnold    schedule 01.02.2011
comment
@thkala: конечно, но я чувствую, что блокировка должна быть на уровне брандмауэра (который был отключен во время расследования, просто чтобы добавить) - и тогда должен быть способ разблокировать его, если я действительно захочу получить эти адреса. Я думал, что это особенность BC UDP, что вы можете получить доступ к адресам даже за пределами обычного адресного пространства. В любом случае, мы проверим, будет ли он работать с другими адресами, такими как 4.0.0.1, или с любым другим адресом за пределами нашего собственного диапазона.   -  person Ingmar    schedule 01.02.2011
comment
@minastaros: вы пытались настроить ПК на подсеть 0.0.0.1/255.255.255.0, например. IP-адрес 0.0.0.2, верно? И, кстати, вполне возможно, что эти пакеты блокируются на более низком уровне, чем брандмауэр...   -  person thkala    schedule 01.02.2011
comment
@thkala: нет, на самом деле на установочном ПК просто обычный 192.168.1.x. или что-то. Когда вы говорите, что они блокируются на более низком уровне, то мне было интересно, почему у XP не было проблем, а у Win 7 есть. Кто определяет правила для этих нижних уровней, где я, пользователь, могу их прочитать? Даже Microsoft должна следовать публичным правилам (должны...), и пока 0.0.0.1 не является незаконным в соответствии с каким-либо RFC, или поэтому я думаю, что они не должны просто сказать «нет». -- Или я совсем не прав и что-то проглядел? Все еще открыты для обучения...   -  person Ingmar    schedule 01.02.2011
comment
@minastaros: я постараюсь объяснить проще: Windows поступает правильно. Если ваш компьютер не находится в этой подсети, какого черта он должен получать от нее широковещательные рассылки? Просто потому, что он находится в том же физическом сегменте? Просто добавьте дополнительный IP-адрес в нужной подсети к интерфейсу ПК.   -  person thkala    schedule 01.02.2011
comment
@ministaros: Кстати, если ваше приложение хочет получать или отправлять пакеты в чужие подсети, оно должно использовать необработанные сокеты, такие как Wireshark. Ожидание, что ОС будет передавать широковещательные пакеты из чужих подсетей в приготовленные сокеты, ИМХО, является неправильным поведением, поэтому они, вероятно, исправили это.   -  person thkala    schedule 01.02.2011
comment
идея всего сюжета состоит в том, чтобы иметь возможность находить и настраивать устройства любой подсети (не только 0.0.0.1). Представьте себе, что технический специалист получает на свой стол устройство из любой точки мира, которое настроено с неизвестным IP-адресом. Таким образом, мы смогли связаться с ним, не используя отвертку. Конечно, существует множество других способов сделать это (сырые или ARP-материалы). дело в том, что раньше это работало отлично (на компьютерах Mac O, Linux и XP с сервисным программным обеспечением), а теперь мы сталкиваемся с ограничениями, которые не охватывались ранее известными правилами.   -  person Ingmar    schedule 01.02.2011
comment
@minastaros: А как насчет использования wireshark для поиска IP-адреса устройства, а затем настройки ПК для этой конкретной подсети в качестве обходного пути? Это работает?   -  person thkala    schedule 01.02.2011
comment
Возможно, это работает, так как ПК все еще может выдавать широковещательные сообщения. Мы просто передаем вопрос техническим специалистам, которые проверят. Тогда мы узнаем, связана ли проблема с начальным диапазоном 0-адресов или, как вы предполагаете, с другой подсетью. Я дам вам знать. С другой стороны - это действительно только обходной путь для тестирования и на всякий случай. Сервисное программное приложение не должно работать только с wireshark, и я сомневаюсь, что отдел ИТ-безопасности благословит это... ;-)   -  person Ingmar    schedule 01.02.2011
comment
@thkala: проверил это: не получилось переключить IP-адрес ПК с Windows на 0.x.x.x. Таким образом, обходной путь не будет работать, пока на устройствах все еще есть 0.0.0.1.   -  person Ingmar    schedule 02.02.2011
comment
@minastaros: у вас есть контроль над исходным кодом приложения? Как вы настраиваете прослушивание этих UDP-пакетов? Сможете ли вы изменить его для использования необработанных сокетов?   -  person thkala    schedule 02.02.2011

Ответы (2)


arrow_upward
1
arrow_downward

Звучит так, как будто ваше приложение для настройки прослушивает широковещательные пакеты на всех сетевых интерфейсах и ожидает получения пакетов из чужих подсетей.

Это не должно не работать — ОС должна передавать широковещательные пакеты только из подсетей, в которых находится каждый сетевой интерфейс, а не из всех подсетей в одном и том же физическом (например, Ethernet) сегменте. Я достаточно уверен, что в противном случае нарушается поведение протокола IP.

Есть два способа справиться с этим:

  • Убедитесь, что ваш сетевой интерфейс имеет IP-адрес в целевой подсети. У вас может быть более одного IP-адреса для каждой сетевой карты, чтобы не должны мешать нормальной работе сети.

  • Настройте или измените свое приложение для использования необработанных сокетов, таких как Wireshark. Имейте в виду, однако, что это переопределяет все обычные сдержки и противовесы, и его следует избегать, поскольку это может привести к поведению, которое почти невозможно диагностировать, поэтому многие сетевые администраторы не одобряют его.

person thkala    schedule 01.02.2011
comment
ткала, большое спасибо за все ваши усилия по написанию ответов. Мы обсудим ваши идеи и проведем еще несколько тестов. Использование другого подхода, вероятно, возможно и способ подумать о будущем, однако проблема в том, что мы не можем легко изменить все уже развернутые устройства. Так что с этой точки зрения лучшим решением было придерживаться того же пути и заставить его как-то работать. Что касается вашего 1-го предложения: согласно моему последнему комментарию выше, нам нужно найти устройства из любой подсети. Таким образом, добавление интерфейса с 0.0.0.x сделает только половину работы. В любом случае - спасибо за это. - person Ingmar; 01.02.2011
comment
провел некоторые исследования: во-первых, тесты показали, что сообщения с устройства с IP 1.0.0.1 приходят. Таким образом: это не вопрос другой подсети. В главе 4 RFC922 четко указано, что возможны широковещательные рассылки на все хосты в локальной аппаратной сети, в главе 7 упоминается адрес получателя 255.255.255.255. Я пришел к выводу, что когда вы можете отправлять на все хосты, вы также должны иметь возможность получать от них. Проблема в ведущем 0.x. RFC1700, стр. 4 (b), говорит, что 0.x.x.x является указанным хостом в этой сети. Может использоваться только как исходный адрес. Это то, что мы делаем - должно быть в порядке. - person Ingmar; 02.02.2011

arrow_upward
0
arrow_downward

Можете ли вы легко добавлять новые записи таблицы маршрутизации на машины Windows? Windows должен знать, какой интерфейс использовать при маршрутизации широковещательного пакета в сеть 0.0.0.x.

Машины Unix, с которыми я знаком, имеют таблицу маршрутизации, которая сопоставляет записи сети/сетевой маски либо со шлюзами, либо с интерфейсами (если сеть является локальной сетью). Локальная сеть (192.168.0.0/16 для моей домашней сети) отправляется на интерфейс eth0. Все остальное 0.0.0.0/0 отправляется на конкретный шлюз 192.168.0.1.

Если бы моя машина отправила широковещательное сообщение UDP в сеть 0.0.0.0/24 (другими словами, широковещательная рассылка UDP была отправлена ​​в 0.0.0.255, то моя машина переслала бы пакет на шлюзовую машину (которую она может найти через arp). Коммутаторы в середине не будут этого делать. t распространять пакет на другие сетевые устройства, поскольку установлен MAC-адрес.

Если бы у моей машины была другая запись маршрутизации для 0.0.0.0/24 на локальный интерфейс, тогда моя машина отправила бы пакет по сети, используя широковещательную группу Ethernet, а коммутаторы переслали бы пакет всем соединениям. (Ура! Прямо как хабы в 90-х! :)

Итак, я полагаю, вам нужно добавить запись маршрутизации для 0.0.0.0/24 на ваши клиентские машины, чтобы они могли правильно адресовать широковещательный пакет.

person sarnold    schedule 01.02.2011
comment
Проблема не в том, что ПК не может отправлять широковещательные сообщения. Может, но не получает их. На самом деле это так, потому что Wireshark видит их прибытие, но затем приложение их не получает (и это произошло с XP). - person Ingmar; 01.02.2011