mDNS över WireGuard: tre portar innan en peer svarar
Avahi behöver ett lämpligt gränssnitt, en rutt till gruppen och en peer som äger destinationen. Tre portar, tre separata kontroller och ingen fan-out.
Att sätta multicast-flaggan på en WireGuard-enhet gör gränssnittet lämpligt för upptäcktsprogramvara, och det är allt flaggan gör. Den talar inte om för protokollet vart ett gruppaket ska ta vägen, och på en enhet med flera peers finns inget enda självklart svar. Tre separata portar står mellan en körande daemon och en upptäckt tjänst.
Testa dem i ordning, för att klara en säger ingenting om nästa.
Port ett: flaggan och daemonens policy
En Linux WireGuard-enhet skapas som en punkt-till-punkt-länk utan ARP, och den bär inte multicast-flaggan som standard. Att lägga till flaggan är en lokal gränssnittsändring, utförd av det som än hanterar enheten. Avahi har sin egen världsbild ovanpå detta, och dess standardpolicy hoppar helt över punkt-till-punkt-gränssnitt. Därför gäller två oberoende lämplighetstester innan ett enda paket rör sig.
Daemonen behöver alltså ett uttryckligt beslut, inte bara en körande process. Dess dokumenterade kontroller omfattar allow-interfaces, deny-interfaces och allow-point-to-point, och den sista är inställningen folk missar.
Kontrollerna nedan rapporterar länkens flaggor, multicast-rutten och huruvida daemonens konfiguration alls kan parsas:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkEn daemon som startade framgångsrikt har inte nödvändigtvis öppnat sockets på det gränssnitt du bryr dig om. Läs dess effektiva konfiguration i stället för att anta att tjänstestatus är lika med täckning.
Port två: rutten till gruppen
Den andra porten är vanlig routing. Ett paket adresserat till 224.0.0.251 följer vidarebefordringstabellen som allt annat, och om tabellen skickar ut det via det fysiska LAN-gränssnittet ändrar ingen WireGuard-konfiguration det. Reparera rutten först så blir resten av utredningen kortare. Titta på vad kärnan rapporterar för gruppadressen innan du rör några peer-nycklar.
| 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 |
Utan en specifik rutt faller kärnan tillbaka på länkens egen multicast-hantering, vilket är varför standarden ser rätt ut på ett platt LAN och fel så snart samma grupptrafik ska lämna via en tunnel. Felet är tyst från avsändarens sida: frågan går någonstans, och svaret kommer aldrig fram.
Port tre: WireGuard väljer en peer per paket
WireGuard väljer en utgående peer genom att slå upp destinationen i de tillåtna adressmängderna, och Linux sändningsväg utför den uppslagningen en gång per paket. Det finns ett resultat, och paketet krypteras för den peeren. Samma grupprefix i flera peers tillåtna listor skapar inte medlemskap eller replikering; det skapar en tvetydig uppslagning som löses till en av dem.
På en dedikerad länk med två ändpunkter är detta precis vad du vill ha, eftersom det finns en enda avsedd mottagare för den medvetet burna grupptrafiken. På ett gränssnitt med fem peers är det en begränsning, inte en funktion, och rättelsen hör hemma i designen och inte i konfigurationen av någon enskild peer.
En fan-out-design behöver en uttrycklig relay, separata länkar eller en helt annan upptäcktsmekanism. Att publicera ett recept för två ändpunkter som en lösning för många klienter eftersom varje klient kan pinga gatewayen är hur detta rullas ut fel.
Den inkommande riktningen kontrolleras annorlunda: källan till ett mottaget paket måste ligga inom den autentiserade peerns tillåtna lista. Att lägga till en multicast-destination där ersätter inte avsändarens verkliga källägande.
Reflektion är en gräns, inte en bro
Avahis reflektor återger mDNS-meddelanden mellan de gränssnitt den väljer, på applikationsnivå. Det är en upptäcktsgräns mellan nätverk, inte en Ethernet-brygga och inte en allmän multicast-router. Två reflektorer kopplade till samma nätverk skapar gärna en slinga av upprepade annonseringar.
Reflektion lämnar också över tjänstenamn och deras metadata till ett annat nätverk, vilket är ett integritetsbeslut lika mycket som ett routingbeslut. Begränsa de valda gränssnitten, och använd tjänstefilter där den installerade versionen stöder dem, så att bara de annonseringar en behörig användare behöver korsar gränsen.
Upptäckt och användning förblir separata resultat. En klient kan se en annonsering för en tjänst vars annonserade adress är onåbar från där klienten befinner sig, eller vars port nekas av dess åtkomstpolicy. Bekräfta tjänsteanslutningen efter att annonseringen dyker upp, och om programmet stöder ett stabilt DNS-namn eller en uttrycklig serveradress, föredra det framför att utöka link-lokal upptäckt. Beskrivningen av kryptonyckelrouting täcker det destinationsbaserade peer-valet som allt detta vilar på.