mDNS prin WireGuard: trei porți înainte ca un peer să răspundă

Setarea fanionului multicast pe un dispozitiv WireGuard face interfața eligibilă pentru software-ul de descoperire, și atât face fanionul. Nu îi spune protocolului unde trebuie să meargă un pachet de grup, iar pe un dispozitiv cu mai mulți peers nu există un singur răspuns evident. Trei porți separate stau între un daemon care rulează și un serviciu descoperit.

Testați-le în ordine, pentru că trecerea uneia nu spune nimic despre următoarea.

Prima poartă: fanionul și politica daemonului

Un dispozitiv WireGuard din Linux este creat ca o legătură punct-la-punct fără ARP și nu poartă fanionul multicast în mod implicit. Adăugarea fanionului este o modificare locală a interfeței, executată de orice gestionează dispozitivul. Avahi are propria viziune asupra lumii deasupra acestui lucru, iar politica sa implicită omite complet interfețele punct-la-punct. Prin urmare, se aplică două teste de eligibilitate independente înainte ca un singur pachet să se miște.

Deci daemonul are nevoie de o decizie explicită, nu doar de un proces care rulează. Controalele sale documentate includ allow-interfaces, deny-interfaces și allow-point-to-point, iar ultimul este setarea pe care oamenii o ratează.

Verificările de mai jos raportează fanioanele legăturii, ruta multicast și dacă configurația daemonului este analizată deloc:

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

Un daemon care a pornit cu succes nu a deschis neapărat socketuri pe interfața care vă interesează. Citiți configurația sa efectivă în loc să presupuneți că starea serviciului echivalează cu acoperirea.

A doua poartă: ruta către grup

A doua poartă este rutarea obișnuită. Un pachet adresat către 224.0.0.251 urmează tabela de forwarding ca orice altceva, iar dacă tabela îl trimite afară prin interfața LAN fizică, nicio configurație WireGuard nu va schimba asta. Reparați mai întâi ruta și restul investigației devine mai scurt. Uitați-vă ce raportează kernelul pentru adresa de grup înainte de a atinge vreo cheie de peer.

Fără o rută specifică, kernelul revine la propria tratare multicast a legăturii, motiv pentru care comportamentul implicit pare corect într-o LAN plată și greșit de îndată ce același trafic de grup trebuie să iasă printr-un tunel. Eșecul este silențios din partea expeditorului: interogarea merge undeva, iar răspunsul nu sosește niciodată.

A treia poartă: WireGuard alege un peer pe pachet

WireGuard selectează un peer de ieșire căutând destinația în seturile de adrese permise, iar calea de transmisie Linux face acea căutare o dată pe pachet. Există un singur rezultat, iar pachetul este criptat pentru acel peer. Același prefix de grup care apare în listele permise ale mai multor peers nu creează apartenență sau replicare; creează o căutare ambiguă care se rezolvă la unul dintre ei.

Pe o legătură dedicată cu două capete acesta este exact ce doriți, pentru că există un singur destinatar preconizat pentru traficul de grup transportat deliberat. Pe o interfață cu cinci peers este o limitare, nu o caracteristică, iar remedierea aparține proiectării și nu configurației vreunui peer anume.

Un proiect cu distribuire are nevoie de un releu explicit, legături separate sau un mecanism de descoperire complet diferit. Publicarea unei rețete cu două capete ca soluție pentru mulți clienți pentru că fiecare client poate face ping la gateway este felul în care acest lucru este implementat greșit.

Direcția de intrare este verificată altfel: sursa unui pachet primit trebuie să cadă în lista permisă a peerului autentificat. Adăugarea acolo a unei destinații multicast nu înlocuiește proprietatea reală a sursei expeditorului.

Reflexia este o frontieră, nu un pod

Reflectorul Avahi reproduce mesajele mDNS între interfețele pe care le selectează, la nivelul aplicației. Este o frontieră de descoperire între rețele, nu un pod Ethernet și nu un router multicast general. Două reflectoare conectate la aceleași rețele vor crea bucuros o buclă de anunțuri repetate.

Reflexia predă, de asemenea, numele serviciilor și metadatele lor unei alte rețele, ceea ce este o decizie de confidențialitate tot atât cât una de rutare. Restrângeți interfețele selectate și folosiți filtre de serviciu acolo unde versiunea instalată le acceptă, astfel încât doar anunțurile de care are nevoie un utilizator autorizat să treacă frontiera.

Descoperirea și utilizarea rămân rezultate separate. Un client poate vedea anunțul unui serviciu a cărui adresă anunțată este inaccesibilă din locul unde se află clientul, sau al cărui port este refuzat de politica sa de acces. Confirmați conexiunea la serviciu după ce anunțul apare, iar dacă aplicația acceptă un nume DNS stabil sau o adresă explicită de server, preferați aceasta în locul extinderii descoperirii locale a legăturii. Descrierea rutării cu cheie criptografică acoperă selecția peerului bazată pe destinație de care depinde totul.