mDNS over WireGuard: drie poorten voordat een peer antwoordt
Avahi heeft een geschikte interface, een route naar de groep en een peer die de bestemming bezit nodig. Drie poorten, drie aparte controles en geen fan-out.
De multicast-vlag op een WireGuard-apparaat zetten maakt de interface geschikt voor ontdekkingssoftware, en dat is alles wat de vlag doet. Hij vertelt het protocol niet waar een groeppakket heen moet, en op een apparaat met meerdere peers is er geen eenduidig antwoord. Tussen een draaiende daemon en een ontdekte dienst staan drie aparte poorten.
Test ze op volgorde, want het halen van één zegt niets over de volgende.
Poort één: de vlag en het beleid van de daemon
Een Linux WireGuard-apparaat wordt aangemaakt als een punt-tot-punt-verbinding zonder ARP, en het draagt standaard niet de multicast-vlag. De vlag toevoegen is een lokale interfacewijziging, uitgevoerd door wat het apparaat ook beheert. Avahi heeft daar bovenop zijn eigen wereldbeeld, en zijn standaardbeleid slaat punt-tot-punt-interfaces volledig over. Er gelden dus twee onafhankelijke geschiktheidstests voordat één pakket beweegt.
De daemon heeft dus een uitdrukkelijke beslissing nodig, niet alleen een draaiend proces. Zijn gedocumenteerde bedieningselementen omvatten allow-interfaces, deny-interfaces en allow-point-to-point, en de laatste is de instelling die mensen missen.
De onderstaande controles rapporteren de linkvlaggen, de multicast-route en of de configuratie van de daemon überhaupt wordt geparseerd:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkEen daemon die met succes is gestart, heeft niet noodzakelijk sockets geopend op de interface die u interesseert. Lees de effectieve configuratie in plaats van aan te nemen dat de dienststatus gelijk is aan dekking.
Poort twee: de route naar de groep
De tweede poort is gewone routering. Een pakket gericht aan 224.0.0.251 volgt de doorstuurtabel zoals alles, en als de tabel het via de fysieke LAN-interface naar buiten stuurt, verandert geen enkele WireGuard-configuratie dat. Repareer eerst de route en de rest van het onderzoek wordt korter. Kijk wat de kernel voor het groepsadres rapporteert voordat u peer-sleutels aanraakt.
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
Zonder specifieke route valt de kernel terug op de eigen multicast-afhandeling van de link, waardoor de standaard er goed uitziet op een plat LAN en fout zodra hetzelfde groepsverkeer via een tunnel naar buiten moet. De fout is stil vanaf de verzender: de query gaat ergens heen, en het antwoord komt nooit aan.
Poort drie: WireGuard kiest één peer per pakket
WireGuard kiest een uitgaande peer door de bestemming op te zoeken in de toegestane adressensets, en het Linux-transmitpad doet die zoekopdracht één keer per pakket. Er is één resultaat, en het pakket wordt voor die peer versleuteld. Dezelfde groepsprefix in de toegestane lijsten van meerdere peers creëert geen lidmaatschap of replicatie; hij creëert een dubbelzinnige opzoeking die op één van hen uitkomt.
Op een speciale verbinding met twee eindpunten is dit precies wat u wilt, omdat er één bedoelde ontvanger is voor het bewust gedragen groepsverkeer. Op een interface met vijf peers is het een beperking, geen functie, en de oplossing hoort in het ontwerp en niet in de configuratie van één peer.
Een fan-out-ontwerp heeft een expliciete relay, aparte verbindingen of een heel ander ontdekkingsmechanisme nodig. Een recept voor twee eindpunten publiceren als oplossing voor veel clients omdat elke client de gateway kan pingen, is hoe dit verkeerd wordt uitgerold.
De inkomende richting wordt anders gecontroleerd: de bron van een ontvangen pakket moet binnen de toegestane lijst van de geauthenticeerde peer vallen. Daar een multicast-bestemming toevoegen vervangt niet het werkelijke bronbezit van de verzender.
Reflectie is een grens, geen brug
De reflector van Avahi reproduceert mDNS-berichten tussen de interfaces die hij selecteert, op de applicatielaag. Het is een ontdekkingsgrens tussen netwerken, geen Ethernet-brug en geen algemene multicast-router. Twee reflectors die op dezelfde netwerken zijn aangesloten, maken met plezier een lus van herhaalde aankondigingen.
Reflectie levert ook dienstnamen en hun metadata af aan een ander netwerk, wat een privacybeslissing is evenzeer als een routeringsbeslissing. Beperk de geselecteerde interfaces, en gebruik dienstfilters waar de geïnstalleerde versie ze ondersteunt, zodat alleen de aankondigingen die een geautoriseerde gebruiker nodig heeft de grens oversteken.
Ontdekking en gebruik blijven aparte resultaten. Een client kan een aankondiging zien voor een dienst waarvan het geadverteerde adres onbereikbaar is vanaf waar de client zit, of waarvan de poort door zijn toegangsbeleid wordt geweigerd. Bevestig de dienstverbinding nadat de aankondiging verschijnt, en als de applicatie een stabiele DNS-naam of een expliciet serveradres ondersteunt, geef daar de voorkeur aan boven het uitbreiden van link-lokale ontdekking. De beschrijving van cryptosleutelroutering behandelt de bestemmingsgebaseerde peerselectie waar dit alles op berust.