mDNS oer WireGuard: trije poarten foar't in peer antwurdet
Avahi hat in geskikt ynterface, in rûte nei de groep en in peer nedich dy't de bestimming besit. Trije poarten, trije aparte kontrôles en gjin fersprieding.
It setten fan de multicast-flagge op in WireGuard-apparaat makket it ynterface geskikt foar ûntdekkingssoftware, en dat is alles wat de flagge docht. It fertelt it protokol net wêr't in groeppakket hinne moat, en op in apparaat mei ferskate peers is der gjin ien foar de hân lizzend antwurd. Trije aparte poarten steane tusken in rinnende daemon en in ûntdutsen tsjinst.
Test se yn folchoarder, want it heljen fan ien seit neat oer de folgjende.
Poarte ien: de flagge en it belied fan de daemon
In Linux WireGuard-apparaat wurdt makke as in punt-nei-punt-ferbining sûnder ARP, en it draacht de multicast-flagge net standert. It tafoegjen fan de flagge is in lokale ynterfacewiziging, útfierd troch wat it apparaat ek beheart. Avahi hat dêrboppe syn eigen byld fan de wrâld, en syn standertbelied slacht punt-nei-punt-ynterfaces folslein oer. Twa ûnôfhinklike geskiktheidstests jilde dus foar't ien pakket beweget.
De daemon hat dus in útdruklik beslút nedich, net allinnich in rinnend proses. Syn dokumintearre kontrôles omfetsje allow-interfaces, deny-interfaces en allow-point-to-point, en de lêste is de ynstelling dy't minsken misse.
De kontrôles hjirûnder rapportearje de flaggen fan 'e keppeling, de multicast-rûte en oft de konfiguraasje fan 'e daemon hielendal parse wurdt:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkIn daemon dy't suksesfol start is, hat net needsaaklikerwize sockets iepene op it ynterface dat jo oanbelanget. Lês syn effektive konfiguraasje ynstee fan oan te nimmen dat tsjinststatus gelyk is oan dekking.
Poarte twa: de rûte nei de groep
De twadde poarte is gewoane routing. In pakket rjochte op 224.0.0.251 folget de trochstjoertabel lykas al it oare, en as de tabel it troch it fysike LAN-ynterface útstjoert, sil gjin WireGuard-konfiguraasje dat feroarje. Reparearje earst de rûte en de rest fan it ûndersyk wurdt koarter. Sjoch wat de kernel foar it groepadres rapportearret foar't jo peer-kaaien oanreitsje.
| 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 |
Sûnder in spesifike rûte falt de kernel werom op de eigen multicast-ôfhanneling fan 'e keppeling, wêrom't de standert goed liket op in plat LAN en ferkeard sa gau't deselde groepferkear troch in tunnel fuort moat. De flater is stil fan 'e kant fan 'e stjoerder: de fraach giet earne hinne, en it antwurd komt nea.
Poarte trije: WireGuard kiest ien peer per pakket
WireGuard kiest in útgeande peer troch de bestimming yn 'e tastiene adressets te sykjen, en it Linux-stjoerpaad docht dat sykjen ien kear per pakket. Der is ien resultaat, en it pakket wurdt foar dy peer fersifere. Deselde groepsprefiks yn 'e tastiene listen fan ferskate peers makket gjin lidmaatskip of replikaasje; it makket in dûbelsinnige syktocht dy't op ien fan har útkomt.
Op in tawijde keppeling mei twa einpunten is dit krekt wat jo wolle, want der is ien bedoelde ûntfanger foar it bewust droegen groepferkear. Op in ynterface mei fiif peers is it in beheining, gjin eigenskip, en de oplossing heart yn it ûntwerp en net yn 'e konfiguraasje fan ien inkele peer.
In ûntwerp mei fersprieding hat in útdruklike relay, aparte keppelings of in hiel oar ûntdekkingsmeganisme nedich. In resept foar twa einpunten publisearje as oplossing foar in soad kliïnten om't elke kliïnt de gateway pingje kin, is hoe't dit ferkeard útrôle wurdt.
De yngongrjochting wurdt oars kontrolearre: de boarne fan in ûntfongen pakket moat binnen de tastiene list fan 'e autentisearre peer falle. Dêr in multicast-bestimming tafoegje ferfangt net it echte boarnejilderskip fan 'e stjoerder.
Wjerspegeling is in grins, gjin brêge
De wjerspegelder fan Avahi werhellet mDNS-berjochten tusken de ynterfaces dy't it kiest, op 'e applikaasjelaach. It is in ûntdekkingsgrins tusken netwurken, gjin Ethernet-brêge en gjin algemiene multicast-router. Twa wjerspegelers ferbûn oan deselde netwurken meitsje wol in lus fan werhelle oankundigings.
Wjerspegeling jout ek tsjinstnammen en har metadata oan in oar netwurk oer, wat in privacybeslút is likefolle as in routingbeslút. Behein de keazen ynterfaces, en brûk tsjinstfilters wêr't de ynstallearre ferzje se stipet, sadat allinnich de oankundigings dy't in autorisearre brûker nedich hat de grins oerstekke.
Ûntdekking en gebrûk bliuwe aparte resultaten. In kliïnt kin in oankundiging sjen foar in tsjinst wêrfan't it oankundige adres net berikber is fan wêr't de kliïnt sit, of wêrfan't de poarte troch syn tagongsbelied wegere wurdt. Befêstigje de tsjinstferbining neidat de oankundiging ferskynt, en as de applikaasje in stabile DNS-namme of in útdruklik serveradres stipet, ferkies dat boppe it útwreidzjen fan link-lokale ûntdekking. De beskriuwing fan kryptokaaierouting beslacht de bestimming-basearre peerkar dêr't dit allegear fan ôfhinklik is.