mDNS su WireGuard: tre cancelli prima che un peer risponda

Impostare il flag multicast su un dispositivo WireGuard rende l'interfaccia idonea al software di scoperta, e il flag non fa altro. Non dice al protocollo dove deve andare un pacchetto di gruppo, e su un dispositivo con più peer non esiste un'unica risposta ovvia. Tre cancelli separati si frappongono tra un demone in esecuzione e un servizio scoperto.

Provateli in ordine, perché superarne uno non dice nulla sul successivo.

Primo cancello: il flag e la politica del demone

Un dispositivo WireGuard su Linux viene creato come collegamento punto-punto senza ARP, e non porta il flag multicast per impostazione predefinita. Aggiungere il flag è una modifica locale dell'interfaccia, eseguita da qualunque cosa gestisca il dispositivo. Avahi ha la propria visione del mondo sopra tutto ciò, e la sua politica predefinita salta completamente le interfacce punto-punto. Si applicano quindi due test di idoneità indipendenti prima che si muova un solo pacchetto.

Il demone ha quindi bisogno di una decisione esplicita, non solo di un processo in esecuzione. I suoi controlli documentati includono allow-interfaces, deny-interfaces e allow-point-to-point, e l'ultimo è l'impostazione che la gente trascura.

Le verifiche seguenti riportano i flag del collegamento, la rotta multicast e se la configurazione del demone viene analizzata:

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

Un demone avviato con successo non ha necessariamente aperto socket sull'interfaccia che vi interessa. Leggete la sua configurazione effettiva invece di supporre che lo stato del servizio equivalga alla copertura.

Secondo cancello: la rotta verso il gruppo

Il secondo cancello è l'instradamento ordinario. Un pacchetto indirizzato a 224.0.0.251 segue la tabella di inoltro come qualsiasi altra cosa, e se la tabella lo manda fuori dall'interfaccia LAN fisica, nessuna configurazione WireGuard lo cambierà. Sistemate prima la rotta e il resto dell'indagine si accorcia. Guardate cosa riporta il kernel per l'indirizzo di gruppo prima di toccare qualsiasi chiave dei peer.

Senza una rotta specifica, il kernel ricade sulla gestione multicast del collegamento stesso, ed è per questo che il comportamento predefinito sembra corretto su una LAN piatta e sbagliato non appena lo stesso traffico di gruppo deve uscire da un tunnel. Il guasto è silenzioso dal lato del mittente: la query va da qualche parte e la risposta non arriva mai.

Terzo cancello: WireGuard sceglie un peer per pacchetto

WireGuard seleziona un peer in uscita cercando la destinazione negli insiemi di indirizzi consentiti, e il percorso di trasmissione Linux esegue quella ricerca una volta per pacchetto. Il risultato è uno, e il pacchetto viene cifrato per quel peer. Lo stesso prefisso di gruppo presente nelle liste consentite di più peer non crea appartenenza né replica; crea una ricerca ambigua che si risolve su uno di essi.

Su un collegamento dedicato a due estremità questo è esattamente ciò che volete, perché c'è un solo destinatario previsto per il traffico di gruppo trasportato deliberatamente. Su un'interfaccia con cinque peer è una limitazione, non una funzionalità, e la correzione appartiene al progetto e non alla configurazione di un singolo peer.

Un progetto a distribuzione necessita di un relè esplicito, collegamenti separati o un meccanismo di scoperta completamente diverso. Pubblicare una ricetta a due estremità come soluzione multi-client perché ogni client può fare ping al gateway è il modo in cui questo viene distribuito male.

La direzione in ingresso si verifica diversamente: l'origine di un pacchetto ricevuto deve cadere nella lista consentita del peer autenticato. Aggiungervi una destinazione multicast non sostituisce la reale proprietà dell'origine del mittente.

La riflessione è un confine, non un ponte

Il riflettore di Avahi riproduce i messaggi mDNS tra le interfacce che seleziona, a livello applicativo. È un confine di scoperta tra reti, non un ponte Ethernet e non un router multicast generico. Due riflettori collegati alle stesse reti creeranno volentieri un ciclo di annunci ripetuti.

La riflessione consegna anche nomi di servizio e i loro metadati a un'altra rete, il che è una decisione sulla privacy oltre che sull'instradamento. Limitate le interfacce selezionate e usate i filtri di servizio dove la versione installata li supporta, così che solo gli annunci necessari a un utente autorizzato attraversino il confine.

Scoperta e utilizzo restano risultati separati. Un client può vedere l'annuncio di un servizio il cui indirizzo annunciato è irraggiungibile da dove si trova il client, o la cui porta è rifiutata dalla sua politica di accesso. Confermate la connessione al servizio dopo che l'annuncio è apparso, e se l'applicazione supporta un nome DNS stabile o un indirizzo server esplicito, preferitelo all'estensione della scoperta locale del collegamento. La descrizione dell'instradamento a chiave crittografica copre la selezione del peer basata sulla destinazione da cui tutto questo dipende.