mDNS sobre WireGuard: três portões antes de um par responder

Definir o sinalizador multicast num dispositivo WireGuard torna a interface elegível para software de descoberta, e é isso que o sinalizador faz. Não diz ao protocolo para onde deve ir um pacote de grupo, e num dispositivo com vários pares não há uma única resposta óbvia. Três portões separados ficam entre um daemon em execução e um serviço descoberto.

Teste-os por ordem, porque passar um não diz nada sobre o seguinte.

Primeiro portão: o sinalizador e a política do daemon

Um dispositivo WireGuard no Linux é criado como uma ligação ponto a ponto sem ARP, e não traz o sinalizador multicast por predefinição. Adicionar o sinalizador é uma alteração local da interface, feita por aquilo que gere o dispositivo. O Avahi tem a sua própria visão do mundo por cima disso, e a sua política predefinida ignora completamente as interfaces ponto a ponto. Aplicam-se, portanto, dois testes de elegibilidade independentes antes de um único pacote se mexer.

Portanto, o daemon precisa de uma decisão explícita, não apenas de um processo em execução. Os seus controlos documentados incluem allow-interfaces, deny-interfaces e allow-point-to-point, e o último é a definição que as pessoas deixam passar.

As verificações abaixo reportam os sinalizadores da ligação, a rota multicast e se a configuração do daemon é sequer analisada:

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

Um daemon que arrancou com sucesso não abriu necessariamente sockets na interface que lhe interessa. Leia a configuração efetiva em vez de assumir que o estado do serviço equivale à cobertura.

Segundo portão: a rota para o grupo

O segundo portão é o encaminhamento comum. Um pacote endereçado a 224.0.0.251 segue a tabela de encaminhamento como tudo o resto, e se a tabela o enviar pela interface LAN física, nenhuma configuração de WireGuard o mudará. Corrija primeiro a rota e o resto da investigação encurta. Veja o que o kernel reporta para o endereço de grupo antes de tocar em quaisquer chaves de par.

Sem uma rota específica, o kernel recorre ao próprio tratamento multicast da ligação, e é por isso que o comportamento predefinido parece correto numa LAN plana e errado assim que o mesmo tráfego de grupo tem de sair por um túnel. A falha é silenciosa do lado do emissor: a consulta vai para algum lado, e a resposta nunca chega.

Terceiro portão: o WireGuard escolhe um par por pacote

O WireGuard seleciona um par de saída procurando o destino nos conjuntos de endereços permitidos, e o caminho de transmissão do Linux faz essa procura uma vez por pacote. Há um só resultado, e o pacote é cifrado para esse par. O mesmo prefixo de grupo presente nas listas permitidas de vários pares não cria pertença nem replicação; cria uma procura ambígua que se resolve num deles.

Numa ligação dedicada de dois extremos isto é exatamente o que quer, porque há um único destinatário previsto para o tráfego de grupo transportado deliberadamente. Numa interface com cinco pares é uma limitação, não uma funcionalidade, e a correção pertence ao desenho e não à configuração de um par qualquer.

Um desenho em leque precisa de um relé explícito, ligações separadas ou um mecanismo de descoberta completamente diferente. Publicar uma receita de dois extremos como solução para muitos clientes porque cada cliente consegue fazer ping à gateway é a forma como isto é implantado mal.

A direção de entrada é verificada de outro modo: a origem de um pacote recebido tem de cair dentro da lista permitida do par autenticado. Acrescentar ali um destino multicast não substitui a propriedade real da origem do emissor.

A reflexão é uma fronteira, não uma ponte

O refletor do Avahi reproduz mensagens mDNS entre as interfaces que seleciona, na camada de aplicação. É uma fronteira de descoberta entre redes, não uma ponte Ethernet e não um router multicast geral. Dois refletores ligados às mesmas redes criam facilmente um ciclo de anúncios repetidos.

A reflexão também entrega nomes de serviço e os seus metadados a outra rede, o que é uma decisão de privacidade tanto como de encaminhamento. Restrinja as interfaces selecionadas e use filtros de serviço onde a versão instalada os suportar, para que só os anúncios de que um utilizador autorizado precisa atravessem a fronteira.

Descoberta e utilização continuam a ser resultados separados. Um cliente pode ver o anúncio de um serviço cujo endereço anunciado é inalcançável a partir de onde o cliente está, ou cuja porta a sua política de acesso recusa. Confirme a ligação ao serviço depois de o anúncio aparecer, e se a aplicação suportar um nome DNS estável ou um endereço de servidor explícito, prefira isso a estender a descoberta local da ligação. A descrição do encaminhamento por chave criptográfica cobre a seleção de par baseada no destino da qual tudo isto depende.