web-dev-qa-db-ja.com

Windowsでグローバルブロードキャストアドレス(255.255.255.255)の動作を変更する方法

望ましい行動

アプリケーションがパケットをグローバルブロードキャストIPアドレス255.255.255.255に送信する場合、すべてのインターフェースで、パケットをイーサネットグローバルブロードキャストアドレス(ff:ff:ff:ff:ff:ff)に送信したいと考えています。

Linuxおよびおそらく他のOSでも、これは動作するようです。 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アドレスと宛先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ルートを追加するだけです)。しかし、どんなに頑張っても、ブロードキャストパケットはoneインターフェイスだけで送信され、私がやりたいようにそれらすべてが送信されるわけではありません。

結論

  • Windows 7は、ブロードキャストパケットを1つのインターフェイスにのみ送信します。どちらを選択してもかまいませんが、ここでは重要ではありません。
  • Windows XPはブロードキャストパケットをすべてのインターフェイスに送信しますが、期待どおりに1つのインターフェイスにのみ送信します。これは実際にはWindows 7の動作と同じです。

目標

Windows(できればWindows 7)でのこのグローバルIPブロードキャストサポートを一度に変更したいと思います。もちろん、サポートされている構成の変更(レジストリハックなど)を行うことをお勧めしますが、すべての提案を受け入れます。

何か案は?

10

最後に、プログラムで解決しました。私は WinIPBroadcast と呼ばれる非常に小さなソフトウェアを作成しました。これは、ブロードキャストフレームをすべてのインターフェイスに中継する処理を行います。

これは興味深い事実を使用して機能します。ループバックアドレス(127.0.0.1)をリッスンしているときにローカルで生成されたグローバルブロードキャストパケットを受信することが可能です。 WinIPBroadcastは、RAWソケットを使用してすべてのブロードキャストをローカルアドレスでリッスンし、ブロードキャストパケットごとに、優先パケットを除くすべてのインターフェイスに中継します。

4

私がマイクロソフトを擁護しているわけではありませんが、ブロードキャストがどのように機能するかを定義しようとする次の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ブロードキャストを送信することを推奨しています。 リンク

6
Scott Lundberg