mDNS oor WireGuard: drie hekke voordat 'n eweknie antwoord
Avahi het 'n geskikte koppelvlak, 'n roete na die groep en 'n eweknie wat die bestemming besit nodig. Drie hekke, drie afsonderlike kontroles, en geen uitwaaiering nie.
Om die multicast-vlag op 'n WireGuard-toestel te stel, maak die koppelvlak geskik vir ontdekkingsagteware, en dit is die einde van wat die vlag doen. Dit sê nie vir die protokol waarheen 'n groeppakkie moet gaan nie, en op 'n toestel met verskeie eweknieë is daar geen enkele ooglopende antwoord nie. Drie afsonderlike hekke staan tussen 'n werkende daemon en 'n ontdekte diens.
Toets hulle in volgorde, want om een te slaag sê vir jou niks oor die volgende nie.
Hek een: die vlag en die daemon se beleid
'n Linux-WireGuard-toestel word geskep as 'n punt-tot-punt-skakel sonder ARP, en dit dra nie standaard die multicast-vlag nie. Die byvoeging van die vlag is 'n plaaslike koppelvlakverandering, uitgevoer deur wat ook al die toestel bestuur. Avahi het sy eie siening van die wêreld bo-op dit, en sy verstekbeleid slaan punt-tot-punt-koppelvlakke heeltemal oor. Twee onafhanklike geskiktheidstoetse geld dus voordat 'n enkele pakkie beweeg.
Die daemon het dus 'n uitdruklike besluit nodig, nie bloot 'n lopende proses nie. Sy gedokumenteerde beheermaatreëls sluit allow-interfaces, deny-interfaces en allow-point-to-point in, en die laaste een is die instelling wat mense mis.
Die kontroles hieronder rapporteer die skakelvlae, die multicast-roete en of die daemon se konfigurasie hoegenaamd ontleed:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --check'n Daemon wat suksesvol begin het, het nie noodwendig sokkels op die koppelvlak wat jou saak maak oopgemaak nie. Lees sy effektiewe konfigurasie eerder as om aan te neem dat diensstatus gelyk is aan dekking.
Hek twee: die roete na die groep
Die tweede hek is gewone roetering. 'n Pakkie gerig aan 224.0.0.251 volg die aanstuurtafel soos enigiets anders, en as die tafel dit deur die fisiese LAN-koppelvlak uitstuur, sal geen WireGuard-konfigurasie dit verander nie. Maak eers die roete reg, dan word die res van die ondersoek korter. Kyk wat die kernel vir die groepadres rapporteer voordat jy enige eweknie-sleutels aanraak.
| 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 |
Sonder 'n spesifieke roete val die kernel terug op die skakel se eie multicast-hantering, wat die rede is waarom die verstek reg lyk op 'n plat LAN en verkeerd sodra dieselfde groepsverkeer veronderstel is om deur 'n tonnel te vertrek. Die mislukking is stil vanaf die sender se kant: die navraag gaan êrens heen, en die antwoord kom nooit aan nie.
Hek drie: WireGuard kies een eweknie per pakkie
WireGuard kies 'n uitgaande eweknie deur die bestemming in die toegelate-adresstelle op te soek, en die Linux-uitstuurpad voer daardie opsoek een keer per pakkie uit. Daar is een resultaat, en die pakkie word vir daardie eweknie geënkripteer. Dieselfde groepprefiks wat in verskeie eweknieë se toegelate lyste verskyn, skep nie lidmaatskap of replisering nie; dit skep 'n dubbelsinnige opsoek wat na een van hulle oplos.
Op 'n toegewyde twee-eindpunt-skakel is dit presies wat jy wil hê, want daar is een beoogde ontvanger vir die doelbewus gedraagde groepsverkeer. Op 'n koppelvlak met vyf eweknieë is dit 'n beperking, nie 'n kenmerk nie, en die regstelling hoort in die ontwerp eerder as in die konfigurasie van enige een eweknie.
'n Uitwaaier-ontwerp het 'n uitdruklike aflos, afsonderlike skakels of 'n heeltemal ander ontdekkingsmeganisme nodig. Om 'n twee-eindpunt-resep as 'n baie-kliënt-oplossing te publiseer omdat elke kliënt die poort kan ping, is hoe dit verkeerd ontplooi word.
Inkomende rigting word anders nagegaan: die bron van 'n ontvangde pakkie moet binne die geverifieerde eweknie se toegelate lys val. Om 'n multicast-bestemming daarby te voeg vervang nie die sender se werklike bron-eienaarskap nie.
Weerkaatsing is 'n grens, nie 'n brug nie
Avahi se weerkaatser weergawe mDNS-boodskappe tussen die koppelvlakke wat dit kies, op die toepassingslaag. Dit is 'n ontdekkingsgrens tussen netwerke, nie 'n Ethernet-brug en nie 'n algemene multicast-roeteerder nie. Twee weerkaatsers wat aan dieselfde netwerke gekoppel is, sal maklik 'n lus van herhaalde aankondigings skep.
Weerkaatsing lewer ook diensname en hul metadata aan 'n ander netwerk oor, wat 'n privaatheidbesluit is net soveel as 'n roeteringsbesluit. Beperk die gekose koppelvlakke, en gebruik diensfilters waar die geïnstalleerde weergawe dit ondersteun, sodat slegs die aankondigings wat 'n gemagtigde gebruiker nodig het die grens oorsteek.
Ontdekking en gebruik bly aparte resultate. 'n Kliënt kan 'n aankondiging sien vir 'n diens waarvan die geadverteerde adres onbereikbaar is van waar die kliënt sit, of waarvan die poort deur sy toegangsbeleid geweier word. Bevestig die diensverbinding nadat die aankondiging verskyn, en as die toepassing 'n stabiele DNS-naam of 'n uitdruklike bedieneradres ondersteun, verkies dit bo die uitbreiding van skakel-plaaslike ontdekking. Die beskrywing van kriptosleutel-roetering dek die bestemmingsgebaseerde ewekniekeuse waarop dit alles berus.