Wie ändere ich das Verhalten der globalen Broadcast-Adresse (255.255.255.255) unter Windows?

Gewünschtes Verhalten

Wenn eine Anwendung ein Paket an die globale Broadcast-IP-Adresse sendet 255.255.255.255, möchte ich, dass das Paket ff:ff:ff:ff:ff:ffauf allen Schnittstellen an die globale Ethernet-Broadcast-Adresse ( ) gesendet wird.

Unter Linux und wahrscheinlich auch unter anderen Betriebssystemen scheint dies zu funktionieren. Windows XP und Windows 7 weisen diesbezüglich unterschiedliche Verhaltensweisen auf, und keines der beiden Verhaltensweisen ist für meine Situation wünschenswert.

Windows XP-Verhalten

Das Paket wird korrekt an die erste Netzwerkschnittstelle gesendet (die Schnittstellenreihenfolge ist unter "Netzwerkverbindungen / Erweiterte / Erweiterte Einstellungen" angegeben). Es wird auch an die anderen Schnittstellen gesendet.

Bisher stimmt alles. Das Problem ist, dass beim Senden an die anderen Schnittstellen die Quelladresse des Broadcast-Pakets die IP-Adresse der ersten Schnittstelle ist. Stellen Sie sich zum Beispiel diese Netzwerkkonfiguration vor (Reihenfolge ist wichtig):

Adapter 1: IP-Adresse 192.168.0.1
Adapter 2: IP-Adresse 10.0.0.1
Adapter 3: IP-Adresse 172.17.0.1

Wenn ich jetzt ein Broadcast-Paket sende, werden die folgenden Pakete gesendet (mit Quell- und Ziel-IP-Adressen):

Auf Adapter 1: 192.168.0.1=>255.255.255.255
Auf Adapter 2: 192.168.0.1=>255.255.255.255
Auf Adapter 3: 192.168.0.1=>255.255.255.255

In der Praxis funktionieren Anwendungen, die Broadcast-Pakete verwenden, nicht auf anderen Schnittstellen als Adapter 1. Meiner Meinung nach ist dies ein offensichtlicher Fehler im TCP / IP-Stack von Windows XP.

Windows 7-Verhalten

Das Ändern der Reihenfolge der Netzwerkschnittstellen scheint keine Auswirkungen auf Windows 7 zu haben. Stattdessen scheint die Übertragung von der IP-Routentabelle gesteuert zu werden.

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
===========================================================================

Sehen Sie die 255.255.255.255Routen? Ja, sie steuern Broadcast-Pakete. In dieser Situation werden Broadcast-Pakete über das gesendet, 192.168.0.3da es die niedrigere Metrik hat ... aber nicht an die anderen Schnittstellen.

Sie können die Schnittstelle ändern, über die globale Broadcast-Pakete sehr einfach gesendet werden (fügen Sie einfach eine persistente 255.255.255.255Route mit einer niedrigen Metrik hinzu). Unabhängig davon, wie sehr Sie sich bemühen, werden Broadcast-Pakete nur auf einer einzigen Schnittstelle gesendet , nicht auf allen, wie ich es gerne hätte.

Fazit

Windows 7 sendet nur Broadcast-Pakete an eine Schnittstelle. Sie können wählen, welche, aber das ist hier nicht der Punkt.
Windows XP sendet Broadcast-Pakete an alle Schnittstellen, sendet sie jedoch erwartungsgemäß nur an eine Schnittstelle, was in der Praxis dem Windows 7-Verhalten entspricht.

Das Ziel

Ich möchte diese globale IP-Broadcast-Unterstützung in Windows (vorzugsweise Windows 7) ein für alle Mal ändern. Der bessere Weg wäre natürlich eine unterstützte Konfigurationsänderung (Registry-Hack oder ähnliches), aber ich bin offen für alle Vorschläge.

Irgendwelche Ideen?

— Etienne Dechamps
quelle

Womit generieren Sie diese Sendungen? Ich kann meinen XP-Stack nur für gerichtete Sendungen verwenden. dh 10.202.255.255 in Ihrem Fall.

— Scott Lundberg

Können Sie auf einen RFC oder ein anderes Dokument verweisen, das das von Ihnen beschriebene korrekte Verhalten angibt? Obwohl ich dem gewünschten Verhalten zustimme, sollte das richtige Verhalten auf eine Spezifikation verweisen, die definiert, was korrekt ist. Könnte es sein, dass die spezifische Routing-Implementierung dem Anbieter (in diesem Fall Microsoft) überlassen bleibt?

— Jason R. Coombs

Scott Lundberg: Viele Anwendungen (insbesondere Spiele) senden globale Sendungen. Sie können einige mit netcat generieren: "nc -v -u 255.255.255.255 5000" zum Beispiel.

— Etienne Dechamps

Jason R. Coombs: Vielleicht hatte ich tatsächlich eine schlechte Wortwahl. Ich hätte "wünschenswertes Verhalten" verwenden sollen. Ich glaube nicht, dass es dafür einen RFC gibt, aber ich kann mich irren.

— Etienne Dechamps

Senden Sie ein TCP- oder UDP-Paket? Demnach ist social.msdn.microsoft.com/Forums/en/peertopeer/thread/… wichtig .

— Nissan Fan

Antworten:

Nicht, dass ich Microsoft verteidigen möchte, aber nachdem ich die folgenden RFCs gelesen habe, die versuchen zu definieren, wie Broadcasts funktionieren, glaube ich nicht, dass Microsoft notwendigerweise RFCs verletzt. IMO sollte das Problem auf Anwendungsebene behoben werden (dh gerichtete Broadcasts, nicht global), die die entsprechenden Routen in der Routing-Tabelle treffen und nur von der richtigen Schnittstelle für dieses IP-Netzwerk gesendet werden.

Beide geben an, dass für Sendungen kein Standard definiert ist. In 919 wird auch erwähnt, dass eine bestimmte physische Schnittstelle für die Sendung ausgewählt werden sollte. Im Fall einer Multi-Homed-Multi-NIC-Maschine, die die Sendung generiert, glaube ich nicht, dass klar angegeben ist, was passieren soll. Broadcasts sollten niemals von Routern von einer Schnittstelle zur anderen übertragen werden. Ist der Windows-Computer also in diesem Fall ein Router oder nicht?
Wenn es wirkt , als Router, dann ist jede Host der Sendung mit der falschen IP - Adresse reagiert für dieses Netzwerk (Adapter 2 und 3 in Ihrem Beispiel) sollte das Paket zurück an der Ethernet - Adresse des Adapters 2 und 3 in Reaktion auf Adapter senden Die IP-Adresse von 1 und der Windows-Host sollten sie an die richtige Schnittstelle weiterleiten.
Das klingt verwirrend ... aber ich kann mir keinen besseren Weg vorstellen, dies auszudrücken

Und schließlich sagt RFC 919 ausdrücklich Von RFC 919

Da wir davon ausgehen, dass das Problem bereits auf der Datenverbindungsschicht gelöst wurde, muss ein IP-Host
, der entweder eine lokale oder eine gerichtete Übertragung senden möchte, nur
die entsprechende Zieladresse angeben und das Datagramm wie
gewohnt senden . Ausgefeilte Algorithmen müssen sich nur in Gateways befinden.

Lesen, das darauf hindeutet, dass die Quell-IP-Adresse für eine Sendung irrelevant ist.

Da jede Anwendung Broadcasts anders zu behandeln scheint, liegt meiner Meinung nach hier die Verantwortung. Beispielsweise. nbtstatSendet gerichtete Broadcasts auf Computern mit mehreren Netzwerkkarten, während Spiele möglicherweise globale Broadcasts verwenden.
Kurz gesagt, die Anwendung sollte repariert sein, in diesem Fall nicht das Betriebssystem ...

EDIT: Hier ist ein Link für die gleichen Umstände, aber unter Linux. Der Linux-Kernel verarbeitet dies, indem er nur ein Paket über die Standardschnittstelle sendet (in diesem Beispiel NIC A). Sie empfehlen, dass die Anwendung die Netzwerkkarten auflistet und eine gerichtete Übertragung an jede Netzwerkkarte sendet. Verknüpfung

— Scott Lundberg
quelle

Verstehen Sie die Beziehung zwischen dem Absatz, den Sie aus RFC 919 zitieren, und der Quelladresse nicht. Mir scheint klar, dass es immer falsch ist, ein IP-Paket auf einer Schnittstelle mit der Quelladresse einer anderen Schnittstelle zu senden, unabhängig von der Broadcast- / Unicast-Natur des Pakets. Ich meine, man kann nicht vernünftigerweise sagen "die Quell-IP-Adresse ist für eine Sendung irrelevant", natürlich ist es das! Wie sollen Anwendungen sonst wissen, wer die Sendung gesendet hat?

— Etienne Dechamps

"In 919 wird auch erwähnt, dass eine bestimmte physische Schnittstelle für die Sendung ausgewählt werden sollte." Wo? "Die Adresse 255.255.255.255 bezeichnet eine Sendung in einem lokalen Hardwarenetzwerk" (RFC919 7.)? In diesem Fall bin ich respektvoll anderer Meinung. Wir diskutieren, was mit Broadcasts auf Hostebene und nicht auf Netzwerkebene zu tun ist. Außerdem wird direkt darunter gesagt, dass ein Host "mit 255.255.255.255 an alle seine unmittelbaren Nachbarn senden kann". Alle seine unmittelbaren Nachbarn. Nicht "alle Nachbarn einer bestimmten Netzwerkschnittstelle".

— Etienne Dechamps

"Anwendungen kümmern sich nicht darum, welche Schnittstelle die Sendung gesendet hat. Sie müssen nur darauf antworten." Huh ... sie müssen auch Sendungen senden und nicht nur auf sie antworten. Betrachten Sie den Fall eines LAN-Gameserver-Browsers. Es sendet Broadcast-Pakete, um Spieleserver im Netzwerk zu erkennen. Wenn die Broadcast-Pakete nicht an alle Schnittstellen gesendet werden, zeigt der Gameserver-Browser keine Spieleserver an, die über diese Schnittstellen erreichbar sind. Mit anderen Worten, episch scheitern.

— Etienne Dechamps

"Ich bin nicht sicher, aber ich denke, dass das Betriebssystem eine 255.255.255.255-Anfrage sieht und sagt, dass es diese an alle Schnittstellen senden muss (um alle unmittelbaren Nachbarn zu finden), aber es wurde von einer bestimmten Anwendung angefordert, die an a gebunden ist spezifische IP (möglicherweise standardmäßig basierend auf der Metrik). " Genau. Das heißt nicht, dass es das Richtige ist. Meiner Meinung nach verstößt es völlig gegen das Prinzip der geringsten Überraschung aus Sicht des Anwendungsentwicklers, der nur erwartet, dass das Paket an alle Schnittstellen an alle gesendet wird.

— Etienne Dechamps

Ich bin mir nicht sicher, was du mit dupliziert meinst. Die RFCs verbieten ausdrücklich die Weiterleitung von Broadcast-Paketen. Es sollte nur ein Paket gesendet werden, was meiner Meinung nach der Kern unserer Diskussion ist. Wenn das Betriebssystem das tun würde, was Sie sagen, müsste es tatsächlich 9 Gesamtpakete generieren (3 für jede Schnittstelle), da die IP-Schicht drei Pakete mit separaten Quell-IPs generieren müsste (eines für jede Netzwerkkarte auf Schicht 3) und dann Jede Netzwerkkarte müsste diese über das Ethernet (Schicht 2) senden. Wenn es Routen zwischen Netzwerken gab, erhalten Sie 3 Antworten zurück! Welcher ist richtig?

— Scott Lundberg

Schließlich habe ich es programmatisch gelöst. Ich habe eine sehr kleine Software namens WinIPBroadcast geschrieben, die sich um die Weiterleitung der Broadcast-Frames an alle Schnittstellen kümmert.

Es funktioniert mit einer interessanten Tatsache: Es ist möglich, lokal generierte globale Broadcast-Pakete zu empfangen, wenn die Loopback-Adresse (127.0.0.1) abgehört wird. WinIPBroadcast überwacht die lokale Adresse für alle Broadcasts mit RAW-Sockets und leitet sie dann für jedes Broadcast-Paket an alle Schnittstellen mit Ausnahme der bevorzugten weiter.

— Etienne Dechamps
quelle

Da der Windows-Stack eine Abzweigung des BSD-Stacks ist, bin ich gespannt, ob BSD das gleiche Verhalten aufweist.

— x0n

Ihre Software funktioniert nicht. The program can't start becuase api-ms-win-core-rtlsupport-l1-2-0.dll is missing from your computer.. Viel Glück beim Finden .dllbei Google.

— Alex G

@AlexG: Das ist komisch, ich dachte, ich hätte dieses Problem durch github.com/dechamps/WinIPBroadcast/commit/… behoben . Sind Sie sicher, dass Sie die letzte Version (1.6) ausführen? Fühlen Sie sich frei, einen Fehler unter github.com/dechamps/WinIPBroadcast/issues einzureichen, und ich werde einen Blick darauf werfen.

— Etienne Dechamps