如何更改 Windows 上的全域廣播地址 (255.255.255.255) 行為？
期望的行為
當應用程序向全域廣播 IP 地址發送數據包時
255.255.255.255，我希望將數據包發送到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 以外的任何介面上都無法工作。在我看來，這是 Windows XP 的 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 XP 將廣播數據包發送到所有介面，但它只將它們按預期發送到一個介面，這實際上相當於 Windows 7 的行為。
目標
我想一勞永逸地更改 Windows（最好是 Windows 7）中的這種全球 IP 廣播支持。當然，更好的方法是進行某種受支持的配置更改（系統資料庫黑客或類似），但我願意接受所有建議。
有任何想法嗎？
最後，我以程式方式解決了它。我編寫了一個名為WinIPBroadcast的小軟體，它負責將廣播幀中繼到所有介面。
它使用一個有趣的事實：在偵聽環回地址 (127.0.0.1) 時，可以接收本地生成的全域廣播數據包。WinIPBroadcast 使用 RAW 套接字偵聽所有廣播的本地地址，然後對於每個廣播數據包，它將其中繼到除首選介面之外的所有介面。
2021 年 12 月 6 日更新：更新了社區連結
並不是說我在為微軟辯護，而是在閱讀了以下試圖定義廣播如何工作的 RFC 之後，我認為微軟不一定違反任何 RFC。IMO 問題應該在應用程序級別解決（即定向廣播，而不是全域），這將命中路由表中的適當路由，並且僅從該 IP 網路的正確介面發送。
他們都表示沒有為廣播定義標準。它還在 919 中提到應該為廣播選擇特定的物理介面。在生成廣播的多宿主、多 NIC 機器的情況下，我認為它沒有明確說明應該發生什麼。廣播不應該由路由器從一個介面傳遞到另一個介面，那麼在這種情況下，Windows 機器是否是路由器？
如果它充當路由器，則任何使用該網路的錯誤 IP 地址響應廣播的主機（在您的範例中為適配器 2 和 3）應將數據包發送回適配器 2 和 3 的乙太網地址以響應適配器1 的 IP 地址和 Windows 主機應將其路由到正確的介面。
這聽起來令人困惑……但想不出更好的表達方式
最後，RFC 919 明確表示 From RFC 919
由於我們假設問題已經在數據鏈路層得到解決，所以希望
發送本地廣播或定向廣播的 IP 主機只需要
指定適當的目標地址並
照常發送數據報即可。任何復雜的算法只需要駐留在網關中。
閱讀這表明源 IP 地址與廣播無關。
由於每個應用程序似乎處理廣播的方式不同，我認為這就是責任所在。例如。
nbtstat在多 NIC 的機器上發送定向廣播，而遊戲可能使用全域廣播。簡而言之，應該修復應用程序，而不是這種情況下的作業系統……
編輯：這是相同情況下的連結，但在 Linux 上。linux 核心只通過預設介面（本例中的 NIC A）發送一個數據包來處理它。他們建議應用程序列舉 NIC 並向每個 NIC 發送定向廣播。 關聯