Как изменить поведение глобального широковещательного адреса (255.255.255.255) в Windows?

Желаемое поведение

Когда приложение отправляет пакет на глобальный широковещательный IP-адрес 255.255.255.255, я хотел бы, чтобы пакет был отправлен на глобальный широковещательный адрес Ethernet ( ff:ff:ff:ff:ff:ff) на всех интерфейсах.

В Linux и, возможно, в других операционных системах это работает. Windows XP и Windows 7 демонстрируют разное поведение по этому поводу, и ни одно из них не подходит для моей ситуации.

Поведение Windows XP

Пакет будет правильно отправлен на первый сетевой интерфейс (порядок интерфейса указан в «Сетевые подключения / Дополнительные / Дополнительные параметры»). Он также будет отправлен на другие интерфейсы.

Пока все правильно. Проблема заключается в том, что при отправке на другие интерфейсы адрес источника широковещательного пакета является IP-адресом первого интерфейса. Например, представьте эту конфигурацию сети (порядок важен):

Адаптер 1: IP-адрес 192.168.0.1
Адаптер 2: IP-адрес 10.0.0.1
Адаптер 3: IP-адрес 172.17.0.1

Теперь, если я отправлю широковещательный пакет, будут отправлены следующие пакеты (с IP-адресами источника и назначения):

На адаптере 1: 192.168.0.1=>255.255.255.255
На адаптере 2: 192.168.0.1=>255.255.255.255
На адаптере 3: 192.168.0.1=>255.255.255.255

На практике приложения, использующие широковещательные пакеты, не будут работать ни на каких интерфейсах, кроме адаптера 1. На мой взгляд, это явная ошибка в стеке TCP / IP Windows XP.

Поведение Windows 7

Изменение порядка сетевого интерфейса, похоже, не оказывает никакого влияния на Windows 7. Вместо этого широковещательная рассылка, по-видимому, контролируется таблицей IP-маршрутов.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0   10.202.254.254       10.202.1.2    286
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.3     10
       10.202.0.0      255.255.0.0         On-link        10.202.1.2    286
       10.202.1.2  255.255.255.255         On-link        10.202.1.2    286
   10.202.255.255  255.255.255.255         On-link        10.202.1.2    286
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0         On-link       192.168.0.3    266
      192.168.0.3  255.255.255.255         On-link       192.168.0.3    266
    192.168.0.255  255.255.255.255         On-link       192.168.0.3    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.0.3    266
        224.0.0.0        240.0.0.0         On-link        10.202.1.2    286
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.0.3    266
  255.255.255.255  255.255.255.255         On-link        10.202.1.2    286
===========================================================================

Видишь 255.255.255.255маршруты? Да, они контролируют широковещательные пакеты. В этой ситуации широковещательные пакеты будут отправляться по той 192.168.0.3причине, что она имеет более низкий показатель ... но не на другие интерфейсы.

Вы можете изменить интерфейс, через который глобальные широковещательные пакеты будут отправляться очень легко (просто добавьте постоянный 255.255.255.255маршрут с низкой метрикой). Но как бы вы ни старались, широковещательные пакеты будут отправляться только на один интерфейс, но не на все, как мне бы хотелось.

Заключение

Windows 7 отправляет широковещательные пакеты только на один интерфейс. Вы можете выбрать, какой из них, но это не главное здесь.
Windows XP отправляет широковещательные пакеты на все интерфейсы, но отправляет их, как и ожидалось, только на один интерфейс, что на практике эквивалентно поведению Windows 7.

Цель

Я хочу раз и навсегда изменить эту глобальную поддержку IP-трансляции в Windows (предпочтительно Windows 7). Конечно, лучшим способом было бы иметь какое-то поддерживаемое изменение конфигурации (взлом реестра или подобное), но я открыт для всех предложений.

Есть идеи?

— Этьен Дечам
источник

Что вы используете для генерации этих трансляций. Я не могу заставить свой стек XP делать что-либо, кроме прямых трансляций. т.е. 10.202.255.255 в вашем случае.

— Скотт Лундберг

Можете ли вы сослаться на RFC или другой документ, в котором указано правильное поведение, которое вы описываете? Хотя я согласен, что это желаемое поведение, чтобы называть его правильным, следует ссылаться на спецификацию, которая определяет, что является правильным. Может ли быть так, что конкретная реализация маршрутизации оставлена на усмотрение поставщика (в данном случае Microsoft)?

— Джейсон Р. Кумбс

Скотт Лундберг: многие приложения (особенно игры) будут отправлять по всему миру. Вы можете сгенерировать некоторые, используя netcat: "nc -v -u 255.255.255.255 5000", например.

— Этьен Дечамс

Джейсон Р. Кумбс: действительно, возможно, у меня был плохой выбор слов. Я должен был использовать «желаемое поведение». Я не думаю, что есть RFC для этого, но я могу ошибаться.

— Этьен Дечамс

Вы отправляете пакет TCP или UDP? В соответствии с этим имеет значение social.msdn.microsoft.com/Forums/en/peertopeer/thread/… .

— Nissan Fan

Ответы:

Не то чтобы я занимался защитой Microsoft, но после прочтения следующих RFC, которые пытаются определить, как работают трансляции, я не думаю, что Microsoft обязательно нарушает какие-либо RFC. ИМО проблема должна быть решена на уровне приложения (т. Е. Направленное широковещание, а не глобальное), которое попадет на соответствующие маршруты в таблице маршрутизации и будет отправлено только с правильного интерфейса для этой IP-сети.

Они оба заявляют, что не существует стандарта, определенного для трансляций. В 919 также упоминается, что для вещания должен быть выбран конкретный физический интерфейс. В случае машины с несколькими сетевыми сетями, генерирующей трансляцию, я не думаю, что четко указано, что должно произойти. Вещания никогда не должны передаваться маршрутизаторами с одного интерфейса на другой, поэтому машина Windows - это маршрутизатор или нет в этом случае?
Если он действует как маршрутизатор, то любой хост, отвечающий на широковещательную рассылку с неверным IP-адресом для этой сети (адаптеры 2 и 3 в вашем примере), должен отправить пакет обратно на адрес Ethernet адаптеров 2 и 3 в ответ на адаптер. IP-адрес 1 и хост Windows должны направить его на соответствующий интерфейс.
Это звучит странно ... но я не могу придумать лучшего способа выразить это

И, наконец, RFC 919, в частности, говорит От RFC 919

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

Чтение, которое предполагает, что IP-адрес источника не имеет значения для трансляции.

Поскольку каждое приложение по-разному обрабатывает трансляции, я думаю, что именно в этом и заключается ответственность. Например. nbtstatотправляет прямые трансляции на машины с несколькими сетевыми платами, в то время как игры могут использовать глобальные трансляции.
Короче, приложение должно быть исправлено, а не ОС в этом случае ...

РЕДАКТИРОВАТЬ: Вот ссылка на те же обстоятельства, но на Linux. Ядро linux обрабатывает его, отправляя только один пакет из интерфейса по умолчанию (NIC A в этом примере). Они рекомендуют приложению перечислять сетевые карты и отправлять направленную широковещательную рассылку на каждую сетевую карту. Ссылка

— Скотт Лундберг
источник

Я не понимаю связи между абзацем, который вы цитируете из RFC 919, и адресом источника. Мне кажется очевидным, что всегда неправильно отправлять IP-пакет на интерфейсе с адресом источника другого интерфейса, независимо от широковещательного / одноадресного характера пакета. Я имею в виду, что вы не можете разумно сказать, «IP-адрес источника не имеет значения для трансляции», конечно, это так! Как еще приложения должны знать, кто отправил трансляцию?

— Этьен Дечамс

«В 919 также упоминается, что для трансляции должен быть выбран конкретный физический интерфейс». Где? «Адрес 255.255.255.255 обозначает вещание в локальной аппаратной сети» (RFC919 7.)? В этом случае я с уважением не согласен. Мы обсуждаем, что делать с трансляциями на уровне хоста, а не на уровне сети. Кроме того, чуть ниже говорится, что хост может «вещать всем своим непосредственным соседям, используя 255.255.255.255». Все его ближайшие соседи. Не «все соседи по определенному сетевому интерфейсу».

— Этьен Дечамс

«Приложениям не важно, какой интерфейс отправил трансляцию. Им просто нужно ответить». Хм ... им тоже нужно отправлять трансляции, а не только отвечать на них. Рассмотрим случай с браузером сетевого игрового сервера. Он отправляет широковещательные пакеты для обнаружения игровых серверов в сети. Если широковещательные пакеты не отправляются на все интерфейсы, браузер игрового сервера не покажет игровые серверы, доступные через эти интерфейсы. Другими словами, эпический провал.

— Этьен Дечамс

«Я не уверен, но я думаю, что ОС видит запрос 255.255.255.255 и говорит, что ему необходимо отправить его на все интерфейсы (чтобы найти всех непосредственных соседей), но он был запрошен из конкретного приложения, привязанного к конкретный IP (может быть по умолчанию на основе метрики). " Я согласен. Это не значит, что это правильно. На мой взгляд, это полностью нарушает принцип наименьшего удивления с точки зрения разработчика приложения, который просто ожидает, что пакет будет разослан всем на всех интерфейсах.

— Этьен Дечамс

Не уверен, что вы имеете в виду под дубликатом. RFC специально запрещают пересылку широковещательных пакетов. Должен быть отправлен только один пакет, который, как мне кажется, и является сутью нашего обсуждения. Если бы ОС делала, как вы говорите, она фактически должна была бы сгенерировать всего 9 пакетов (по 3 на каждый интерфейс), потому что уровень IP должен был бы сгенерировать три пакета с отдельными исходными IP-адресами (по одному для каждого сетевого адаптера на уровне 3), а затем каждый сетевой адаптер должен был бы отправлять их по Ethernet (уровень 2). Если между сетями были маршруты, вы получите 3 ответа! Какой из них прав?

— Скотт Лундберг

Наконец, я решил это программно. Я написал очень маленькое программное обеспечение под названием WinIPBroadcast, которое заботится о ретрансляции кадров вещания на все интерфейсы.

Это работает с использованием интересного факта: возможно получать локально сгенерированные глобальные широковещательные пакеты при прослушивании по адресу обратной связи (127.0.0.1). WinIPBroadcast прослушивает локальный адрес для всех широковещательных сообщений с использованием сокетов RAW, затем для каждого широковещательного пакета передает его на все интерфейсы, кроме предпочтительного.

— Этьен Дечам
источник

Поскольку стек Windows является форком стека BSD, мне любопытно узнать, демонстрирует ли BSD такое же поведение.

— x0n

Ваше программное обеспечение не работает. The program can't start becuase api-ms-win-core-rtlsupport-l1-2-0.dll is missing from your computer., Удачи в поиске .dllв Google

— Alex G

@AlexG: это странно, я думал, что решил эту проблему через github.com/dechamps/WinIPBroadcast/commit/… . Вы уверены, что используете последнюю версию (1.6)? Не стесняйтесь подавать сообщение об ошибке на github.com/dechamps/WinIPBroadcast/issues, и я посмотрю.

— Этьен