mDNS over WireGuard: tre porte, før en peer svarer
Avahi kræver en egnet grænseflade, en rute til gruppen og en peer, der ejer destinationen. Tre porte, tre separate kontroller og ingen fan-out.
Når multicast-flaget sættes på en WireGuard-enhed, bliver grænsefladen egnet til opdagelsessoftware, og det er alt, flaget gør. Det fortæller ikke protokollen, hvor en gruppepakke skal hen, og på en enhed med flere peers findes der ikke ét oplagt svar. Tre separate porte står mellem en kørende daemon og en opdaget tjeneste.
Test dem i rækkefølge, fordi at bestå én ikke siger noget om den næste.
Port et: flaget og daemonens politik
En Linux WireGuard-enhed oprettes som et punkt-til-punkt-link uden ARP, og den bærer ikke multicast-flaget som standard. At tilføje flaget er en lokal grænsefladeændring, som udføres af det, der administrerer enheden. Avahi har sit eget verdensbillede ovenpå, og dens standardpolitik springer punkt-til-punkt-grænseflader helt over. Derfor gælder to uafhængige egnethedstests, før en enkelt pakke bevæger sig.
Daemonen har altså brug for en udtrykkelig beslutning, ikke blot en kørende proces. Dens dokumenterede kontroller omfatter allow-interfaces, deny-interfaces og allow-point-to-point, og den sidste er den indstilling, folk overser.
Kontrollerne nedenfor rapporterer linkets flag, multicast-ruten og hvorvidt daemonens konfiguration overhovedet kan parses:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkEn daemon, der er startet med succes, har ikke nødvendigvis åbnet sockets på den grænseflade, du bekymrer dig om. Læs dens effektive konfiguration i stedet for at antage, at tjenestestatus er lig med dækning.
Port to: ruten til gruppen
Den anden port er almindelig routing. En pakke adresseret til 224.0.0.251 følger videresendelsestabellen som alt andet, og hvis tabellen sender den ud gennem den fysiske LAN-grænseflade, ændrer ingen WireGuard-konfiguration det. Ret ruten først, så bliver resten af undersøgelsen kortere. Se, hvad kernen rapporterer for gruppeadressen, før du rører ved nogen peer-nøgler.
| 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 |
Uden en bestemt rute falder kernen tilbage på linkets egen multicast-håndtering, og derfor ser standarden rigtig ud på et fladt LAN og forkert, så snart den samme gruppetrafik skal forlade netværket via en tunnel. Fejlen er tavs fra afsenderens side: forespørgslen går et sted hen, og svaret kommer aldrig.
Port tre: WireGuard vælger én peer pr. pakke
WireGuard vælger en udgående peer ved at slå destinationen op i de tilladte adressesæt, og Linux' sendesti udfører det opslag én gang pr. pakke. Der er ét resultat, og pakken krypteres til den peer. Det samme gruppeprefiks, der optræder på flere peers' tilladte lister, skaber ikke medlemskab eller replikering; det skaber et tvetydigt opslag, der afgøres til en af dem.
På et dedikeret link med to endepunkter er det præcis, hvad du vil have, fordi der er én tilsigtet modtager af den bevidst transporterede gruppetrafik. På en grænseflade med fem peers er det en begrænsning, ikke en funktion, og rettelsen hører i designet frem for i konfigurationen af nogen enkelt peer.
Et fan-out-design kræver et udtrykkeligt relay, separate links eller en helt anden opdagelsesmekanisme. At udgive en opskrift til to endepunkter som en flerklientløsning, fordi hver klient kan pinge gatewayen, er hvordan dette udrulles forkert.
Den indgående retning kontrolleres anderledes: kilden til en modtaget pakke skal ligge inden for den godkendte peers tilladte liste. At tilføje en multicast-destination der erstatter ikke afsenderens reelle kildeejerskab.
Refleksion er en grænse, ikke en bro
Avahis reflektor gengiver mDNS-beskeder mellem de grænseflader, den vælger, på applikationslaget. Det er en opdagelsesgrænse mellem netværk, ikke en Ethernet-bro og ikke en generel multicast-router. To reflektorer forbundet til de samme netværk skaber gerne en løkke af gentagne annonceringer.
Refleksion overleverer også tjenestenavne og deres metadata til et andet netværk, hvilket er en privatlivsbeslutning lige såvel som en routingbeslutning. Begræns de valgte grænseflader, og brug tjenestefiltre, hvor den installerede version understøtter dem, så kun de annonceringer, en autoriseret bruger har brug for, krydser grænsen.
Opdagelse og brug forbliver separate resultater. En klient kan se en annoncering for en tjeneste, hvis annoncerede adresse ikke kan nås fra der, hvor klienten er, eller hvis port klientens adgangspolitik afviser. Bekræft tjenesteforbindelsen, efter annonceringen vises, og hvis applikationen understøtter et stabilt DNS-navn eller en udtrykkelig serveradresse, foretræk det frem for at udvide link-local opdagelse. Beskrivelsen af kryptonøgle-routing dækker den destinationsbaserede peer-valg, som alt dette afhænger af.