Когда приложение отправляет пакет на глобальный широковещательный IP-адрес 255.255.255.255, Я хочу, чтобы пакет был отправлен на глобальный широковещательный адрес Ethernet (ff:ff:ff:ff:ff:ff) на всех интерфейсах.
В Linux и, возможно, в других операционных системах это работает. Windows XP и Windows 7 проявляют разное поведение по этому поводу, и в моей ситуации ни то, ни другое поведение нежелательно.
Пакет будет правильно отправлен на первый сетевой интерфейс (порядок интерфейсов указан в «Сетевые подключения / Дополнительные / Дополнительные настройки»). Он также будет отправлен на другие интерфейсы.
Пока все в порядке. Проблема в том, что при отправке на другие интерфейсы адрес источника широковещательного пакета является IP-адресом первого интерфейса. Например, представьте себе такую конфигурацию сети (важен порядок):
192.168.0.110.0.0.1172.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. Вместо этого кажется, что широковещательная рассылка контролируется таблицей 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 маршрут с низкой метрикой). Но как бы вы ни старались, широковещательные пакеты будут отправляться только на один интерфейс, не все из них, как я бы хотел.
Я хочу раз и навсегда изменить эту глобальную поддержку IP-трансляции в Windows (желательно Windows 7). Конечно, лучше было бы иметь какое-то поддерживаемое изменение конфигурации (взлом реестра или подобное), но я открыт для всех предложений.
Любые идеи?
Не то чтобы я занимался защитой 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 в этом примере). Они рекомендуют приложению перечислить сетевые адаптеры и отправить направленный транслировать каждую сетевую карту. Ссылка на сайт
Наконец, я решил это программно. Я написал очень маленькую программу под названием WinIPBroadcast который заботится о ретрансляции широковещательных кадров на все интерфейсы.
Это работает с использованием интересного факта: можно принимать локально сгенерированные глобальные широковещательные пакеты при прослушивании адреса обратной связи (127.0.0.1). WinIPBroadcast прослушивает локальный адрес для всей широковещательной рассылки с использованием сокетов RAW, затем для каждого широковещательного пакета он ретранслирует его на все интерфейсы, кроме предпочтительного.