SSM über OpenVPN: eine Quelle und eine Gruppe von Anfang bis Ende verfolgen

Wählen Sie einen Stream und einen Empfänger und verfolgen Sie dieses Paar durch jeden Hop, statt Multicast als Kategorie zu testen. Ein quellenspezifisches Design scheitert an genau einer von vier Stellen: Der Empfänger ist nie beigetreten, der Router hat das Paket auf seinem Rückweg verworfen, der Kernel hat keinen Zustand, oder der Tunnel hat nie eine Kopie zugestellt. In dieser Reihenfolge zu arbeiten kostet Minuten pro Hop und sagt Ihnen, welche der vier Sie tatsächlich haben.

Zuerst Quelle, Gruppe und Empfänger festnageln

Notieren Sie drei Werte, bevor Sie irgendein Gerät anfassen: die Quelladresse, die senden wird, die Gruppenadresse, der der Empfänger beitreten wird, und das Subnetz, in dem der Empfänger lebt. Für einen beispielhaften IPv4-Stream ist eine Quelle 10.50.0.10 und eine Gruppe 232.20.30.40 die Art Paar, die zu einem quellenspezifischen Design passt. Alles Unschärfere als diese drei Werte lässt sich nicht testen.

Der Bereich 232/8 ist für quellenspezifisches Multicast reserviert, und das Modell ist beschrieben in RFC 4607. Wenn Ihre Gruppe außerhalb dieses Bereichs liegt, während Sie glauben, SSM zu betreiben, halten Sie an und bestätigen Sie, was die Bereitstellung tatsächlich beabsichtigt, denn der Beitritt des Empfängers und die Weiterleitungsentscheidung des Routers hängen beide davon ab, dass das Modell konsistent ist.

Prüfen Sie, ob der Empfänger der Quelle beigetreten ist

Ein Mitgliedschaftsbericht nur für die Gruppe ist kein quellenspezifischer Beitritt. Fragen Sie den Empfänger, welche Quelle er angefordert hat, und sehen Sie auf dem First-Hop-Router im Gruppenzustand nach, ob eine Quellenliste auftaucht. Trägt der Bericht keine Quelle, behandelt der Router ihn als Beitritt zu beliebiger Quelle, und das ganze Design degradiert still zu etwas, das Sie nicht geplant haben.

Prüfen Sie auf einem Linux-Empfänger, worauf der Socket tatsächlich abonniert hat und was der Kernel festgehalten hat. Die Konfigurationsdatei der Anwendung ist kein Beweis; die Mitgliedschaftstabelle ist einer. Lesen Sie sie, während der Empfänger tatsächlich läuft, denn ein Eintrag kann kurz nachhängen, nachdem der Prozess, der ihn erzeugt hat, beendet ist. Ein veralteter Eintrag aus einem früheren Test ist eine verlässliche Quelle falscher Sicherheit.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

Ist der Beitritt mit der erwarteten Quelle vorhanden, gehen Sie zu den Routern. Fehlt er, hilft keine Tunnelkonfiguration, denn es gibt nichts weiterzuleiten.

Prüfen Sie den Rückweg, bevor Sie auf den Tunnel schauen

Multicast-Routing führt eine Rückwegprüfung durch, und ein Paket, das auf einer anderen Schnittstelle ankommt als der, auf die die Unicast-Route zeigt, wird verworfen. Das ist der häufigste Grund, warum ein Stream, der offensichtlich gesendet wird, den nächsten Hop nie erreicht, und es entsteht überhaupt kein brauchbarer Fehler auf Anwendungsebene.

Vergleichen Sie auf dem Router zur Quelle hin die Route zur Quelle mit der Schnittstelle, auf der die Pakete tatsächlich ankommen. Tun Sie auf dem Router zum Empfänger hin dasselbe für das eigene Subnetz des Empfängers und bestätigen Sie, dass die Liste der ausgehenden Schnittstellen den Link dorthin enthält. Eine Abweichung in irgendeine Richtung ist ein RPF-Fehler, kein Mitgliedschaftsfehler.

Bestätigen Sie dann, dass die TTL der Quelle groß genug ist, um die geplanten gerouteten Hops zu überstehen. Ein Stream, der auf dem ersten Router funktioniert und auf dem zweiten stirbt, ist oft eine TTL-Frage und keine Policy-Frage.

Lesen Sie den Multicast-Zustand des Kernels statt der Konfiguration

Die Konfiguration sagt Ihnen, was Sie angefordert haben; der Kernel sagt Ihnen, was geschieht. Lesen Sie auf jedem Linux-Hop die Multicast-Routing-Einträge und bestätigen Sie, dass für das exakte Paar aus Quelle und Gruppe eine Liste eingehender und ausgehender Schnittstellen existiert. Ein Eintrag für die Gruppe mit Platzhalterquelle ist ein anderes Objekt und erklärt keinen quellenspezifischen Fluss.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Routing-Daemons halten ihre eigene Sicht über diesem Zustand, und der Befehl, der sie ausgibt, hängt davon ab, welche Implementierung installiert ist. Das Prinzip ist konstant: Fragen Sie den Daemon nach seinem Upstream-Eintrag für das Paar und dann den Kernel, ob ein Weiterleitungseintrag existiert. Ein Daemon, der zu weiterleiten glaubt, während der Kernel keinen Eintrag hat, ist ein Konfigurationsumfangsproblem auf diesem Host.

Wenn die beiden nicht übereinstimmen, reparieren Sie den Host und nicht das VPN. Nichts weiter unten kann einen Hop ausgleichen, der den Fluss nicht weiterleitet, nach dem Sie gefragt haben. Notieren Sie das Paar, die eingehende Schnittstelle und die ausgehende Liste für jeden Hop, solange der Stream läuft. Diese Aufzeichnung macht den nächsten Fehler zu einem Vergleich statt zu einer neuen Untersuchung.

Entscheiden Sie, wie der Tunnel tatsächlich repliziert

Hier hört Multicast über ein VPN auf, Routine zu sein. Ein Punkt-zu-Punkt-Tunnel stellt ein Paket dem einzigen Peer am anderen Ende zu, eine Kopie erreicht also genau einen Client. Ein gebrücktes Segment verhält sich eher wie eine gemeinsame Strecke, weil der Tunnel den Frame trägt und die Bridge entscheidet, was geflutet wird. Das sind unterschiedliche Zustellmodelle, und ein Design, das das zweite annimmt, während es das erste betreibt, wird für einen Empfänger zu funktionieren scheinen und für den nächsten scheitern.

Für mehr als einen Empfänger über einen Multipoint-Server muss die Replikation ausdrücklich entworfen werden. Eine Multicast-Route auf dem Gateway zu installieren lehrt den VPN-Server nicht, welche Peers eine Kopie erhalten sollen, und keine clientseitige Route trifft diese Entscheidung für ihn. Wo die Anforderung viele Empfänger sind, nutzen Sie unterstützte Replikation oder eine bewusst gewählte Alternative und schreiben Sie auf, welche Sie gewählt haben.

Prüfen Sie schließlich am Empfänger unter enger Beobachtung: die exakte Quelle, Gruppe und den Port auf der erwarteten Schnittstelle, während ein autorisierter Empfänger beigetreten ist. SSM wählt einen Sender, und die Auswahl ist weder eine Authentifizierung dieses Senders noch eine Erlaubnis für anderen Multicast-Verkehr, dieselbe Policy zu durchqueren.