mDNS over WireGuard: tre porter før en peer svarer
Avahi trenger et egnet grensesnitt, en rute til gruppen og en peer som eier destinasjonen. Tre porter, tre separate kontroller og ingen fan-out.
Å sette multicast-flagget på en WireGuard-enhet gjør grensesnittet egnet for oppdagelsesprogramvare, og det er alt flagget gjør. Det forteller ikke protokollen hvor en gruppepakke skal gå, og på en enhet med flere peers finnes det ikke ett åpenbart svar. Tre separate porter står mellom en kjørende daemon og en oppdaget tjeneste.
Test dem i rekkefølge, fordi å bestå én sier ingenting om den neste.
Port én: flagget og daemonens policy
En Linux WireGuard-enhet opprettes som en punkt-til-punkt-lenke uten ARP, og den bærer ikke multicast-flagget som standard. Å legge til flagget er en lokal grensesnittendring, utført av det som administrerer enheten. Avahi har sitt eget verdensbilde oppå dette, og standardpolicyen hopper helt over punkt-til-punkt-grensesnitt. Derfor gjelder to uavhengige egnethetstester før én eneste pakke beveger seg.
Daemonen trenger altså en uttrykkelig beslutning, ikke bare en kjørende prosess. De dokumenterte kontrollene inkluderer allow-interfaces, deny-interfaces og allow-point-to-point, og den siste er innstillingen folk overser.
Kontrollene nedenfor rapporterer lenkeflaggene, multicast-ruten og hvorvidt daemonens konfigurasjon i det hele tatt kan parses:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkEn daemon som startet vellykket, har ikke nødvendigvis åpnet sockets på grensesnittet du bryr deg om. Les den effektive konfigurasjonen i stedet for å anta at tjenestestatus er lik dekning.
Port to: ruten til gruppen
Den andre porten er vanlig ruting. En pakke adressert til 224.0.0.251 følger videresendingstabellen som alt annet, og hvis tabellen sender den ut gjennom det fysiske LAN-grensesnittet, endrer ingen WireGuard-konfigurasjon det. Reparer ruten først, så blir resten av undersøkelsen kortere. Se hva kjernen rapporterer for gruppeadressen før du rører noen peer-nøkler.
| 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 |
Uten en bestemt rute faller kjernen tilbake på lenkens egen multicast-behandling, og derfor ser standarden riktig ut på et flatt LAN og feil så snart den samme gruppetrafikken skal forlate via en tunnel. Feilen er stille fra avsenders side: spørringen går et sted, og svaret kommer aldri.
Port tre: WireGuard velger én peer per pakke
WireGuard velger en utgående peer ved å slå opp destinasjonen i de tillatte adressesettene, og Linux' sendebane utfører det oppslaget én gang per pakke. Det er ett resultat, og pakken krypteres for den peeren. Det samme gruppeprefikset som dukker opp i flere peers tillatte lister, skaper ikke medlemskap eller replikering; det skaper et tvetydig oppslag som løses til en av dem.
På en dedikert lenke med to endepunkter er dette akkurat det du vil ha, fordi det er én tiltenkt mottaker for den bevisst fraktede gruppetrafikken. På et grensesnitt med fem peers er det en begrensning, ikke en funksjon, og rettelsen hører i designet og ikke i konfigurasjonen til en enkelt peer.
Et fan-out-design trenger et uttrykkelig relay, separate lenker eller en helt annen oppdagelsesmekanisme. Å publisere en oppskrift for to endepunkter som en flerklientløsning fordi hver klient kan pinge gatewayen, er hvordan dette rulles ut feil.
Den inngående retningen kontrolleres annerledes: kilden til en mottatt pakke må ligge innenfor den autentiserte peerens tillatte liste. Å legge til en multicast-destinasjon der erstatter ikke avsenderens reelle kildeeierskap.
Refleksjon er en grense, ikke en bro
Avahis reflektor gjengir mDNS-meldinger mellom grensesnittene den velger, på applikasjonslaget. Det er en oppdagelsesgrense mellom nettverk, ikke en Ethernet-bro og ikke en generell multicast-ruter. To reflektorer koblet til de samme nettverkene lager gjerne en løkke av gjentatte kunngjøringer.
Refleksjon overleverer også tjenestenavn og metadataene deres til et annet nettverk, noe som er en personvernbeslutning like mye som en rutebeslutning. Begrens de valgte grensesnittene, og bruk tjenestefiltre der den installerte versjonen støtter dem, slik at bare kunngjøringene en autorisert bruker trenger, krysser grensen.
Oppdagelse og bruk forblir separate resultater. En klient kan se en kunngjøring for en tjeneste der den annonserte adressen er uoppnåelig fra der klienten er, eller der porten avvises av dens tilgangspolicy. Bekreft tjenestetilkoblingen etter at kunngjøringen vises, og hvis applikasjonen støtter et stabilt DNS-navn eller en uttrykkelig serveradresse, foretrekk det framfor å utvide link-lokal oppdagelse. Beskrivelsen av kryptonøkkelruting dekker den destinasjonsbaserte peervalget som alt dette avhenger av.