アプリケーションがパケットをグローバルブロードキャストIPアドレス255.255.255.255
に送信する場合、すべてのインターフェースで、パケットをイーサネットグローバルブロードキャストアドレス(ff:ff:ff:ff:ff:ff
)に送信したいと考えています。
Linuxおよびおそらく他のOSでも、これは動作するようです。 Windows XPとWindows 7はこれに関して異なる動作を示し、どちらの動作も私の状況には望ましくありません。
パケットは最初のネットワークインターフェイスに正しく送信されます(インターフェイスの順序は「ネットワーク接続/詳細設定/詳細設定」で指定されています)。他のインターフェースにも送信されます。
これまでのところすべてが正常です。問題は、他のインターフェイスに送信する場合、ブロードキャストパケットの送信元アドレスが最初のインターフェイスのIPアドレスであることです。たとえば、次のネットワーク構成を想像してください(順序は重要です)。
192.168.0.1
10.0.0.1
172.17.0.1
ブロードキャストパケットを送信すると、次のパケットが送信されます(送信元IPアドレスと宛先IPアドレスが含まれます)。
192.168.0.1
=> 255.255.255.255
192.168.0.1
=> 255.255.255.255
アダプター3の場合:192.168.0.1
=> 255.255.255.255
実際には、ブロードキャストパケットを使用するアプリケーションは、アダプター1以外のインターフェイスでは動作しません。私の意見では、これはWindows XPのTCP/IPスタックの明らかなバグです。
ネットワークインターフェイスの順序を変更しても、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
ルートを追加するだけです)。しかし、どんなに頑張っても、ブロードキャストパケットはoneインターフェイスだけで送信され、私がやりたいようにそれらすべてが送信されるわけではありません。
Windows(できればWindows 7)でのこのグローバルIPブロードキャストサポートを一度に変更したいと思います。もちろん、サポートされている構成の変更(レジストリハックなど)を行うことをお勧めしますが、すべての提案を受け入れます。
何か案は?
最後に、プログラムで解決しました。私は WinIPBroadcast と呼ばれる非常に小さなソフトウェアを作成しました。これは、ブロードキャストフレームをすべてのインターフェイスに中継する処理を行います。
これは興味深い事実を使用して機能します。ループバックアドレス(127.0.0.1)をリッスンしているときにローカルで生成されたグローバルブロードキャストパケットを受信することが可能です。 WinIPBroadcastは、RAWソケットを使用してすべてのブロードキャストをローカルアドレスでリッスンし、ブロードキャストパケットごとに、優先パケットを除くすべてのインターフェイスに中継します。
私がマイクロソフトを擁護しているわけではありませんが、ブロードキャストがどのように機能するかを定義しようとする次のRFCを読んだ後、マイクロソフトが必ずしもRFCに違反しているとは思いません。 IMO問題はアプリケーションレベルで修正する必要があります(つまり、グローバルではなく、ダイレクトブロードキャスト)。ルーティングテーブルの適切なルートにヒットし、そのIPネットワークの正しいインターフェイスからのみ送信されます。
彼らは両方とも放送のために定義された標準がないと述べています。また、919では、ブロードキャスト用に特定の物理インターフェイスを選択する必要があると述べています。ブロードキャストを生成するマルチホームのマルチNICマシンの場合、どうなるか明確に述べられていないと思います。ブロードキャストは、ルーターによって1つのインターフェイスから別のインターフェイスに渡されることはありません。この場合、Windowsマシンはルーターなのか、そうでないのですか?
ルーターとしてactingの場合、そのネットワーク(例ではアダプター2と3)の不正なIPアドレスでブロードキャストに応答するホストは、アダプタ1のIPアドレスに応じて、パケットをアダプタ2および3のイーサネットアドレスに送り返します。Windowsホストは、パケットを適切なインターフェースにルーティングする必要があります。
それは混乱するように聞こえます...しかし、これを表現するより良い方法を考えることができません
そして最後に、RFC 919は具体的にRFC 919より
問題はデータリンク層ですでに解決されていると想定しているため、IPホストは
ローカルブロードキャストまたはダイレクトブロードキャストのいずれかのみを送信する
適切な宛先アドレスを指定し、データグラムを次のように送信します
通常。高度なアルゴリズムは、ゲートウェイにのみ存在する必要があります。
これを読むと、ソースIPアドレスはブロードキャストには無関係であることを示唆しています。
各アプリケーションはブロードキャストを別々に処理するように見えるので、それが責任があると私は思います。例えば。 nbtstat
は、マルチNICマシンでダイレクトブロードキャストを送信しますが、ゲームはグローバルブロードキャストを使用する場合があります。
つまり、この場合はOSではなく、アプリケーションを修正する必要があります...
編集:これは link が同じ状況ですが、Linuxの場合です。 Linuxカーネルは、デフォルトのインターフェース(この例ではNIC A)から1つのパケットを送信するだけでそれを処理します。彼らは、アプリケーションがNICを列挙し、各NICからdirectedブロードキャストを送信することを推奨しています。 リンク