mDNS over WireGuard: tre portar før ein peer svarar

Å setje multicast-flaggja på eit WireGuard-apparat gjer grensesnittet eigna for oppdagingsprogramvare, og det er alt flaggja gjer. Ho fortel ikkje protokollen kvar ein gruppepakke skal gå, og på eit apparat med fleire peer finst det ikkje eitt openbert svar. Tre separate portar står mellom ein køyrande daemon og ei oppdaga teneste.

Test dei i rekkjefølgje, fordi å klare éin seier ingenting om den neste.

Port éin: flaggja og policyen til daemonen

Eit Linux WireGuard-apparat vert oppretta som ei punkt-til-punkt-lenke utan ARP, og ho ber ikkje multicast-flaggja som standard. Å leggje til flaggja er ei lokal grensesnittendring, utført av det som styrer apparatet. Avahi har si eiga verdssyn oppå dette, og standardpolicyen hoppar heilt over punkt-til-punkt-grensesnitt. Derfor gjeld to uavhengige eigna-testar før éin einaste pakke rører seg.

Daemonen treng altså ei uttrykkeleg avgjerd, ikkje berre ein køyrande prosess. Dei dokumenterte kontrollane omfattar allow-interfaces, deny-interfaces og allow-point-to-point, og den siste er innstillinga folk overser.

Kontrollane nedanfor rapporterer lenkeflagga, multicast-ruta og om konfigurasjonen til daemonen i det heile kan parsast:

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

Ein daemon som starta vellukka, har ikkje nødvendigvis opna sockets på grensesnittet du bryr deg om. Les den effektive konfigurasjonen i staden for å anta at tenestestatus er lik dekning.

Port to: ruta til gruppa

Den andre porten er vanleg ruting. Ein pakke adressert til 224.0.0.251 følgjer vidaresendingstabellen som alt anna, og om tabellen sender han ut gjennom det fysiske LAN-grensesnittet, endrar ingen WireGuard-konfigurasjon det. Reparer ruta først, så vert resten av undersøkinga kortare. Sjå kva kjernen rapporterer for gruppeadressa før du rører nokon peer-nøklar.

Utan ei bestemd rute fell kjernen tilbake på lenkja si eiga multicast-handtering, og derfor ser standarden rett ut på eit flatt LAN og feil så snart den same gruppetrafikken skal ut gjennom ein tunnel. Feilen er stille frå sendaren si side: spørjinga går ein stad, og svaret kjem aldri.

Port tre: WireGuard vel éin peer per pakke

WireGuard vel ein utgåande peer ved å slå opp destinasjonen i dei tillatne adressesetta, og Linux sin sendebane utfører det oppslaget éin gong per pakke. Det er eitt resultat, og pakken vert kryptert for den peeren. Det same gruppeprefikset som dukkar opp i dei tillatne listene til fleire peer, skaper ikkje medlemskap eller replikering; det skaper eit tvitydig oppslag som løyser seg til ein av dei.

På ei dedikert lenke med to endepunkt er dette akkurat det du vil ha, fordi det er éin tiltenkt mottakar for den medvite frakta gruppetrafikken. På eit grensesnitt med fem peer er det ei avgrensing, ikkje ein funksjon, og rettinga høyrer i designet og ikkje i konfigurasjonen til ein einaste peer.

Eit fan-out-design treng eit uttrykkeleg relay, separate lenker eller ein heilt annan oppdagingsmekanisme. Å publisere ei oppskrift for to endepunkt som ei fleirklientsløysing fordi kvar klient kan pinge gatewayen, er korleis dette vert rulle ut feil.

Den inngåande retninga vert kontrollert annleis: kjelda til ein motteken pakke må liggje innanfor den tillatne lista til den autentiserte peeren. Å leggje til ein multicast-destinasjon der erstattar ikkje det reelle kjeldeeigarskapet til sendaren.

Refleksjon er ei grense, ikkje ei bru

Reflektoren til Avahi gjev att mDNS-meldingar mellom grensesnitta han vel, på applikasjonslaget. Det er ei oppdagingsgrense mellom nettverk, ikkje ei Ethernet-bru og ikkje ein generell multicast-rutar. To reflektorer knytte til dei same nettverka lagar gjerne ei løkke av gjentekne kunngjeringar.

Refleksjon overleverer også tenestenamn og metadataa deira til eit anna nettverk, noko som er ei personvernavgjerd like mykje som ei ruteavgjerd. Avgrens dei valde grensesnitta, og bruk tenestefilter der den installerte versjonen støttar dei, slik at berre kunngjeringane ein autorisert brukar treng, kryssar grensa.

Oppdaging og bruk vert verande separate resultat. Ein klient kan sjå ei kunngjering for ei teneste der den annonserte adressa er uoppnåeleg frå der klienten er, eller der porten vert avvist av tilgangspolicyen hans. Stadfest tenestetilkoplinga etter at kunngjeringa dukkar opp, og om applikasjonen støttar eit stabilt DNS-namn eller ei uttrykkeleg tenaradresse, føretrekk det framfor å utvide link-lokal oppdaging. Skildringa av kryptonøkkelruting dekkjer det destinasjonsbaserte peervalet som alt dette er avhengig av.