AdGuard Home Responde aos Clientes WireGuard a Partir do Seu Endereço LAN

O túnel está ativo, o firewall permite a porta 53, o AdGuard Home está em execução, e os nomes ainda não são resolvidos para o cliente WireGuard. A consulta normalmente chega e uma resposta normalmente sai, então os contadores de pacotes no resolvedor parecem saudáveis e o serviço parece inocente. O que dá errado é o endereço de origem nessa resposta: ela sai de um endereço local que o cliente nunca solicitou, e o resolvedor stub do cliente descarta. Uma lista na configuração do AdGuard Home decide isso, e seu padrão usual delega a decisão ao kernel.

A consulta chega, a resposta sai de outro lugar

Um cliente configurado com 10.6.0.1 como seu resolvedor envia uma consulta UDP para 10.6.0.1 porta 53. Esse pacote atravessa o túnel e chega ao host, e o AdGuard Home responde a ele. Na rede, no entanto, a resposta é um novo pacote cujo endereço de origem é escolhido pela pilha do host, e não pela expectativa do cliente.

Quando o resolvedor do cliente é um socket conectado, que é o que o systemd-resolved, dnsmasq e a maioria dos resolvedores stub usam, ele aceita apenas respostas do endereço exato para o qual foi enviado. Uma resposta originada de 192.168.1.10 para uma consulta enviada a 10.6.0.1 é descartada antes que qualquer análise aconteça. O resolvedor registra uma resposta bem-sucedida, o cliente registra um tempo limite, e ambos estão dizendo a verdade.

Portanto, os contadores não estão mentindo e o cliente também não. A evidência de que você precisa está em três lugares, nesta ordem: no endereço ao qual o ouvinte está ligado, na rota que o kernel usaria de volta para o cliente e no endereço de origem do pacote de resposta real.

Como o kernel escolhe a origem da resposta

Um socket UDP ligado a0.0.0.0não possui endereço de origem próprio, então cada resposta de saída aciona uma busca de rota para o destino. O kernel então pega a origem dessa rota: o endereço fixado pela rota ou o endereço principal da interface de saída. Nada sobre o endereço de destino da consulta é lembrado.

Em um host com apenas uma interface, isso é invisível, porque existe apenas uma resposta plausível. Em uma máquina com um endereço LAN, um endereço WireGuard e um endereço de gerenciamento, várias respostas são plausíveis, e o vencedor depende da tabela de roteamento naquele momento. Adicione uma rota extra, um segundo endereço na mesma interface, um redirecionamento NAT na frente do resolvedor, ou execute o AdGuard em um contêiner com seu próprio namespace, e a fonte escolhida pode diferir daquela que o cliente consultou.

ss -lunp | grep :53mostra em qual jogo você está. Um listener em0.0.0.0:53é o caso curinga; um listener em10.6.0.1:53já fixou a resposta. Ler o socket é mais rápido do que ler o YAML, e reflete o que realmente está rodando em vez do que foi salvo por último.

O que bind_hosts realmente controla

AdGuard Homedns.bind_hostsé a lista de endereços locais que o ouvinte DNS utiliza. O padrão fornecido é o curinga, o que significa aceitar em todos os endereços locais e deixar o kernel escolher a origem por resposta. Substituir o curinga pelo endereço consultado pelos clientes altera o soquete e, com ele, o endereço de origem em cada resposta.

A lista pode ter mais de uma entrada, o que é importante em um resolvedor que atende duas redes. Listar10.6.0.1e192.168.1.10fornece dois soquetes vinculados, e uma consulta que chega em qualquer um deles é respondida a partir do endereço em que chegou. Esse é o comportamento que a maioria das pessoas assume que o curinga já fornece.

O YAML é simples, e o endereço nele é o que seus clientes de túnel foram instruídos a usar, não o endereço principal do host:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Por que duas instalações de um resolvedor discordam

Gerenciado por plugin, neste contexto, significa que o resolvedor foi instalado e é supervisionado por outro pacote: um pacote de firmware de roteador, um pacote de NAS ou um complemento de automação residencial. Esse pacote geralmente envia sua própria cópia do YAML do AdGuard Home e reinicia o processo em sua própria programação, enquanto uma instância independente é o binário ou contêiner do fornecedor que você configura por conta própria. De qualquer forma, você está lidando com dois processos independentes com arquivos de configuração separados e escolhas de ligação separadas, mesmo quando ambos lêem a mesma lista upstream e as mesmas listas de filtro. Um pode vincular o endereço específico do túnel enquanto o outro herda o curinga, e a interface web parece idêntica de qualquer lado.

É por isso que "o mesmo resolvedor funcionava antes da migração" não prova nada sobre a vinculação atual. Verifique o socket, depois verifique o arquivo de configuração que o processo em execução realmente carregou. Uma cópia desatualizada em outro diretório é uma razão comum para a edição parecer não ter efeito.

Fixe isso, depois teste do lado do túnel

Alterebind_hostspara o endereço do túnel, reinicie o serviço e confirme que o socket se moveu:ss -lunp | grep :53agora deve mostrar10.6.0.1:53e nenhuma entrada curinga. Se ainda mostrar0.0.0.0,o processo em execução não está lendo o arquivo que você editou.

Em seguida, teste do lado do cliente, porque esse é o único lado que importa. Uma consulta comdig @10.6.0.1 example.comutiliza o caminho que o usuário utiliza, e uma captura no host comtcpdump -ni wg0 udp port 53mostra o endereço de origem da resposta na rede. Compare-o com o endereço na configuração do resolvedor do cliente; quando eles são iguais, o tempo limite deixa de ser um mistério.

ip route get 10.6.0.2explica qualquer oddidade restante, porque imprime a interface e a origem que o host usaria de volta para o cliente. Se essa saída indicar a interface LAN, a alteração do bind não é a correção completa e a tabela de roteamento é a próxima coisa a ser lida.

O que a configuração de bind não pode corrigir

Fixar o listener não corrige uma lista de acesso que omite a sub-rede do túnel, uma regra de firewall que permite a consulta mas não a resposta, ou uma rota ausente de volta ao pool do WireGuard. Estes falham antes ou depois do endereço de origem, e cada um tem um responsável diferente.

Também não alterapara qual upstream o resolvedor encaminha, se a proteção contra reatribuição rejeita uma resposta privada para um nome privado, ou como o cliente aplica seus próprios domínios de pesquisa. Esses são controles separados. Altere o endereço de link quando a fonte da resposta estiver errada, e altere outra coisa quando não estiver.