Warum Multicast ein VPN ohne Plan nicht überquert

Erreichbarkeit ist Unicast. Gehen Sie die Gruppe, ihren Bereich, den Weiterleitungszustand und einen Weg von einer Quelle zu einem Empfänger durch, bevor Sie eine Bridge oder ein Relay hinzufügen.

Zwei Standorte können sich per Unicast einwandfrei erreichen und sich dennoch so verhalten, als könne einer von ihnen die Erkennungsankündigung des Druckers, den IPTV-Stream oder den Heartbeat des Clusters nicht sehen. Das ist kein kaputter Tunnel; es ist der Unterschied zwischen einem Ziel und einer Gruppe. Multicast-Zustellung braucht ein Mitgliedschaftsmodell, Weiterleitungszustand entlang des Pfades und eine Schnittstelle, die den Verkehr tragen will, und nichts davon kommt von einer Unicast-Route. Der Weg von der Gruppe der Anwendung zu einem funktionierenden Empfänger ist der kürzeste Weg zu einer Antwort.

Beginnen Sie mit der Gruppe und der Anwendung

Fragen Sie, welche Gruppenadresse die Anwendung verwendet und wofür der Verkehr gedacht ist. Ein Erkennungsprotokoll, das Dienste ankündigt, ein Streaming-Feed und die Hello-Pakete eines Routingprotokolls sind drei verschiedene Probleme mit drei verschiedenen akzeptablen Antworten. Die Gruppenadresse selbst nennt den Bereich: Adressen im lokalen Netzsteuerungsblock sind nicht dafür gedacht, von gewöhnlichem Routing über den Link hinaus weitergeleitet zu werden, und Anwendungen, die sie nutzen, gehen meist von einer einzigen Broadcast-Domäne aus. Ein Streaming-Feed auf einer Gruppe mit globalem Bereich ist ein anderes Design als ein Erkennungsprotokoll, das erwartet, dass jedes Gerät jede Abfrage hört, und nur das zweite kümmert sich um die Größe der Broadcast-Domäne.

Entscheiden Sie, ob die Anforderung der Dienst oder der Erkennungsmechanismus ist, denn diese Antworten unterscheiden sich im Aufwand um eine Größenordnung. Die eine verlangt eine Adresse, die sich nicht ändert; die andere verlangt eine über eine Weitverkehrsstrecke ausgedehnte Broadcast-Domäne mit allem, was daraus folgt.

Link-lokale Erkennung soll aufhören

Multicast-DNS, wie in RFC 6762 beschrieben, ist um einen einzigen Link herum entworfen: Abfragen gehen an eine feste Gruppe, Antworten werden an dieselbe Gruppe gesendet, und das Protokoll verlässt sich darauf, dass jeder Teilnehmer alle hört. Router leiten diesen Verkehr standardmäßig nicht weiter, und das ist eine Designentscheidung und kein Versehen. Die Grenze existiert, damit sich ein Gerät in einem Gebäude nicht beiläufig in ein anderes hinein ankündigt. Ein Tunnel, der die Erkennung scheinbar repariert, indem er die Gruppe überallhin trägt, hat diese Grenze für jede Anwendung beseitigt, nicht nur für die, die Hilfe brauchte.

Repeater und Reflektoren existieren, und sie sind echte Dienste mit echten Folgen: Jeder an einem Standort angekündigte Name wird am anderen sichtbar, einschließlich Gerätenamen, die Personen oder Ausrüstung identifizieren. Wenn die eigentliche Anforderung ist, dass ein bestimmter Dienst auffindbar ist, ist ein in DNS veröffentlichter Diensteintrag meist die kleinere Änderung, und er offenbart einen Namen statt eines Stroms davon.

Drei Dinge, die geroutetes Multicast braucht

Geroutetes Multicast braucht drei Dinge, die zusammenwirken: Empfänger, die der Gruppe beitreten, Router, die dafür Weiterleitungszustand führen, und einen Tunnel, der die Gruppenadressen als zu tragenden Verkehr behandelt. Ein Tunnel mit einer Richtlinie, die nur Unicast-Subnetze auflistet, verwirft den Verkehr der Gruppe an der Verschlüsselungsgrenze, weshalb das erste Symptom oft Stille statt eines Fehlers ist. Eine routenbasierte Schnittstelle wie ein GRE- oder VTI-Tunnel trägt, was die Routing-Tabelle hineinschickt, was die Gruppe erreichbar macht, sobald der Multicast-Zustand existiert.

Die Erreichbarkeit der Quelle ist die zweite Hälfte. Multicast-Routingprotokolle wie PIM bauen Verteilbäume auf, indem sie prüfen, ob der Pfad zurück zur Quelle der erwartete ist, sodass eine Unicast-Route, die woandershin zeigt, den Baum bricht, selbst wenn die Gruppenmitgliedschaft korrekt ist. Eine Route für den Empfänger zu installieren, tut für diese Prüfung nichts, und das ist der Fehler, der ein funktionierendes Ping und einen scheiternden Stream ergibt. Prüfen Sie zuerst den Rückweg der Quelle, fügen Sie dann die Mitgliedschaft hinzu und schauen Sie erst danach auf die Anwendung.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

Die ersten beiden Zeilen zeigen, welcher Gruppe der Host beigetreten ist und was der Kernel weiterleitet, die dritte zeigt die Mitgliedschaft der Anwendung selbst, und die letzte den Unicast-Pfad, den die Reverse-Path-Prüfung verwenden wird. Zusammen gelesen unterscheiden sie eine Anwendung, die nie beigetreten ist, von einem Netz, das nie weitergeleitet hat.

Beweisen Sie es mit einer Quelle und einem Empfänger

Bevor Sie eine Konfiguration anfassen, bestätigen Sie, dass die Anwendung in einem einzelnen Segment funktioniert. Scheitert sie lokal, ist Multicast-Routing nicht das Problem, und keine Tunneländerung wird helfen. Wiederholen Sie dann mit einem Empfänger über den Tunnel und beobachten Sie die Pakete auf beiden Seiten der Verschlüsselungsgrenze.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

Pakete, die innerhalb des Tunnels sichtbar sind, außerhalb aber fehlen, deuten auf Kapselung oder Richtlinie hin; Pakete, die auf beiden Seiten sichtbar sind, ohne Fortschritt in der Anwendung, deuten auf die Mitgliedschaft des Empfängers oder die Bindung der Anwendung hin. Halten Sie Mitschnitte kurz und gefiltert, denn ein breiter Multicast-Mitschnitt auf einem ausgelasteten Segment ist überwiegend Rauschen.

Bevorzugen Sie eine Dienstadresse, wenn Sie nur den Dienst brauchen

Erkennung existiert, um etwas zu finden, das sich bewegt. Ein Server mit stabilem Namen braucht keine Erkennung, und eine dokumentierte Adresse im privaten DNS beantwortet die eigentliche Frage des Nutzers, ohne eine Broadcast-Domäne über eine Weitverkehrsstrecke auszudehnen. Dieselbe Überlegung gilt für Drucker, Geräte und interne Webdienste. Ein Name in DNS ist von jedem Standort erreichbar, der ihn braucht, kündigt den Standorten, die ihn nicht brauchen, nichts an und funktioniert weiter, wenn das Gerät durch eines mit einer anderen Adresse ersetzt wird.

Wenn ein Protokoll wirklich Multicast erfordert, begrenzen Sie es auf die Gruppe und die Standorte, die es brauchen, dokumentieren Sie warum, und überprüfen Sie die Entscheidung, wenn sich die Anwendung ändert. Erkennung überall auszudehnen ist einmal leicht getan und nach einem Jahr von Geräten, die still davon abhängen, schwer zurückzunehmen.

Ähnliche Artikel