如何更改Windows上的全局广播地址(255.255.255.255)行为？
期望行为
当应用程序向全局广播IP地址255.255.255.255发送数据包时，我希望在所有接口上将该数据包发送到以太网全局广播地址(ff:ff:ff:ff:ff:ff)。
在Linux和其他OSes上，这似乎也是可行的。Windows和Windows 7在这方面表现出不同的行为，这两种行为都不适合我的情况。
Windows行为
数据包将正确地发送到第一个网络接口(接口顺序在“网络连接/高级/高级设置”中指定)。它也将被发送到其他接口。
到目前为止一切都是正确的。问题是，当发送到其他接口时，广播包的源地址是第一个接口的IP地址。例如，想象一下这个网络配置(订单很重要)：
- 适配器1: IP地址
192.168.0.1 - 适配器2: IP地址
10.0.0.1 - 适配器3: IP地址
172.17.0.1
现在，如果我发送广播数据包，将发送以下数据包(包含源IP地址和目标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以外的任何接口上工作。在我看来，这在Windows的TCP/IP堆栈中是一个明显的错误。
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向所有接口发送广播数据包，但只能按预期的方式发送到一个接口，这实际上等同于Windows 7行为。
目标
我想一劳永逸地改变Windows (最好是Windows 7)对全球IP广播的支持。当然，更好的方法是进行某种支持的配置更改(注册表攻击或类似的更改)，但我愿意接受所有建议。
有什么想法吗？
回答 2
Server Fault用户
发布于 2009-10-31 23:14:45
最后，我通过编程解决了这个问题。我编写了一个名为WinIPBroadcast的小型软件，负责将广播帧转发到所有接口。
它使用了一个有趣的事实:当侦听回循环地址(127.0.0.1)时，可以接收本地生成的全局广播数据包。WinIPBroadcast使用原始套接字侦听所有广播的本地地址，然后对每个广播数据包将其中继到除首选接口之外的所有接口。
更新06.12.2021:更新社区链接
Server Fault用户
发布于 2009-10-07 14:17:14
并不是说我是在为微软辩护，而是在阅读了以下试图定义广播方式的RFC之后，我认为微软并不一定违反了任何RFCs。海事组织应在应用程序一级(即定向广播，而不是全球广播)解决这一问题，这将触及路由表中的适当路线，并且只能从该IP网络的正确接口发送。
他们都说没有为广播规定标准。它还在919中提到，应该为广播选择一个特定的物理接口。对于一台多主频、多网卡产生广播的机器，我不认为它清楚地说明了应该发生什么。广播不应该由路由器从一个接口传递到另一个接口，那么Windows机器在这种情况下是否是路由器？
如果它充当路由器，则任何响应广播的主机，如果该网络的IP地址不正确(在您的示例中为Adapters 2和3)，则应将数据包发送回Adapter 2和3的以太网地址，以响应Adapter 1's IP地址，而Windows主机应将其路由到适当的接口。
听起来很困惑..。但想不出更好的表达方式
最后，RFC 919从RFC 919中明确指出
由于我们假设在数据链路层已经解决了这个问题，希望发送本地广播或有向广播的IP主机需要only指定适当的目的地地址并通常发送数据报as。任何复杂的算法只需要驻留在网关中。
阅读表明源IP地址与广播无关。
由于每个应用程序处理广播的方式似乎不同，我认为这就是责任所在。例如。nbtstat在多NICed机器上发送定向广播，而游戏可能使用全球广播.
简而言之，应用程序应该是固定的，而不是在这种情况下的操作系统.
编辑:这里有一个用于相同情况的链接，但是在Linux上。linux内核只发送一个包给默认接口(本例中为NIC A)来处理它。他们建议应用程序枚举NIC并向每个NIC发送定向广播。链接
https://serverfault.com/questions/72112
复制相似问题
腾讯云开发者
