mDNS über WireGuard: drei Hürden, bevor ein Peer antwortet

Das Setzen des Multicast-Flags auf einem WireGuard-Gerät macht die Schnittstelle für Discovery-Software geeignet, und mehr bewirkt das Flag nicht. Es sagt dem Protokoll nicht, wohin ein Gruppenpaket gehen soll, und auf einem Gerät mit mehreren Peers gibt es keine einzige offensichtliche Antwort. Zwischen einem laufenden Daemon und einem entdeckten Dienst stehen drei getrennte Hürden.

Prüfen Sie sie der Reihe nach, denn das Bestehen einer Hürde sagt nichts über die nächste aus.

Erste Hürde: das Flag und die Richtlinie des Daemons

Ein Linux-WireGuard-Gerät wird als Punkt-zu-Punkt-Verbindung ohne ARP angelegt und trägt das Multicast-Flag standardmäßig nicht. Das Hinzufügen des Flags ist eine lokale Schnittstellenänderung, die von dem ausgeführt wird, was das Gerät verwaltet. Avahi hat darüber hinaus seine eigene Sicht auf die Welt, und seine Standardrichtlinie überspringt Punkt-zu-Punkt-Schnittstellen vollständig. Es gelten also zwei unabhängige Eignungstests, bevor sich ein einziges Paket bewegt.

Der Daemon braucht also eine ausdrückliche Entscheidung, nicht bloß einen laufenden Prozess. Zu seinen dokumentierten Steuerungsmöglichkeiten gehören allow-interfaces, deny-interfaces und allow-point-to-point, und die letzte ist die Einstellung, die Leute übersehen.

Die folgenden Prüfungen melden die Link-Flags, die Multicast-Route und ob die Konfiguration des Daemons überhaupt geparst wird:

ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --check

Ein erfolgreich gestarteter Daemon hat nicht unbedingt Sockets auf der Schnittstelle geöffnet, die Sie interessiert. Lesen Sie seine effektive Konfiguration, statt anzunehmen, dass der Dienststatus der Abdeckung entspricht.

Zweite Hürde: die Route zur Gruppe

Die zweite Hürde ist gewöhnliches Routing. Ein an 224.0.0.251 adressiertes Paket folgt der Weiterleitungstabelle wie alles andere, und wenn die Tabelle es über die physische LAN-Schnittstelle hinausschickt, ändert keine WireGuard-Konfiguration daran etwas. Reparieren Sie zuerst die Route, dann wird der Rest der Untersuchung kürzer. Sehen Sie nach, was der Kernel für die Gruppenadresse meldet, bevor Sie irgendwelche Peer-Schlüssel anfassen.

Ohne eine bestimmte Route fällt der Kernel auf die eigene Multicast-Behandlung der Verbindung zurück, weshalb der Standard in einem flachen LAN richtig und falsch aussieht, sobald derselbe Gruppenverkehr über einen Tunnel hinausgehen soll. Der Fehler ist von der Senderseite aus still: Die Abfrage geht irgendwohin, und die Antwort kommt nie an.

Dritte Hürde: WireGuard wählt einen Peer pro Paket

WireGuard wählt einen ausgehenden Peer, indem es das Ziel in den erlaubten Adresssätzen nachschlägt, und der Linux-Sendeweg führt dieses Nachschlagen einmal pro Paket aus. Es gibt ein Ergebnis, und das Paket wird für diesen Peer verschlüsselt. Derselbe Gruppenpräfix in den erlaubten Listen mehrerer Peers erzeugt keine Mitgliedschaft und keine Replikation; er erzeugt ein mehrdeutiges Nachschlagen, das sich auf einen von ihnen auflöst.

Auf einer dedizierten Verbindung mit zwei Endpunkten ist das genau das, was Sie wollen, denn es gibt einen vorgesehenen Empfänger für den bewusst übertragenen Gruppenverkehr. Auf einer Schnittstelle mit fünf Peers ist es eine Einschränkung, kein Merkmal, und die Korrektur gehört ins Design und nicht in die Konfiguration eines einzelnen Peers.

Ein Fan-out-Design braucht ein ausdrückliches Relay, getrennte Verbindungen oder einen ganz anderen Discovery-Mechanismus. Ein Zwei-Endpunkt-Rezept als Mehrclient-Lösung zu veröffentlichen, weil jeder Client das Gateway anpingen kann, ist der Weg, wie das falsch ausgerollt wird.

Die eingehende Richtung wird anders geprüft: Die Quelle eines empfangenen Pakets muss in der erlaubten Liste des authentifizierten Peers liegen. Ein Multicast-Ziel dort hinzuzufügen ersetzt nicht die tatsächliche Quellenzugehörigkeit des Senders.

Reflexion ist eine Grenze, keine Brücke

Der Reflektor von Avahi gibt mDNS-Nachrichten zwischen den von ihm ausgewählten Schnittstellen auf Anwendungsebene wieder. Er ist eine Discovery-Grenze zwischen Netzen, keine Ethernet-Brücke und kein allgemeiner Multicast-Router. Zwei Reflektoren, die an dieselben Netze angebunden sind, erzeugen munter eine Schleife wiederholter Ankündigungen.

Die Reflexion übergibt außerdem Dienstnamen und ihre Metadaten an ein anderes Netz, was ebenso eine Datenschutzentscheidung ist wie eine Routingentscheidung. Beschränken Sie die ausgewählten Schnittstellen und nutzen Sie Dienstfilter, wo die installierte Version sie unterstützt, damit nur die Ankündigungen die Grenze überschreiten, die ein autorisierter Nutzer benötigt.

Erkennung und Nutzung bleiben getrennte Ergebnisse. Ein Client kann eine Ankündigung für einen Dienst sehen, dessen angekündigte Adresse von seinem Standort aus nicht erreichbar ist oder dessen Port seine Zugriffsrichtlinie ablehnt. Bestätigen Sie die Dienstverbindung, nachdem die Ankündigung erscheint, und wenn die Anwendung einen stabilen DNS-Namen oder eine ausdrückliche Serveradresse unterstützt, ziehen Sie das der Erweiterung der Link-Local-Erkennung vor. Die Beschreibung des Kryptoschlüssel-Routings deckt die zielbasierte Peer-Auswahl ab, auf der all dies beruht.