AdGuard Home responde aos clientes de WireGuard desde a dirección da súa LAN

O túnel está aberto, o firewall permite o porto 53, AdGuard Home está a funcionar, e os nomes aínda non se resolven para o cliente de WireGuard. A consulta normalmente chega e unha resposta normalmente sae, así que os contadores de paquetes no resolvedor parecen saudables e o servizo parece inocente. O que falla é a dirección de orixe desa resposta: sae desde unha dirección local que o cliente nunca solicitou, e o resolvedor provisional do cliente descárgaa. Unha lista na configuración de AdGuard Home decide isto, e o seu valor predeterminado habitual entrega a decisión ao núcleo.

A consulta chega, a resposta sae dende outro lugar

Un cliente configurado con 10.6.0.1 como o seu resolvedor envía unha consulta UDP a 10.6.0.1 porto 53. Ese paquete atravesa o túnel e chega ao host, e AdGuard Home respóndelle. Na rede, con todo, a resposta é un novo paquete cuxa dirección de orixe é escollida pola pila do host, non pola expectativa do cliente.

Cando o resolvedor do cliente é un socket conectado, que é o que usan systemd-resolved, dnsmasq e a maioría de resolvedores stub, só acepta respostas da dirección exacta á que enviou. Unha resposta procedente de 192.168.1.10 a unha consulta enviada a 10.6.0.1 é descartada antes de que se produza calquera análise. O resolvedor rexistra unha resposta exitosa, o cliente rexistra un tempo de espera, e ambos están dicindo a verdade.

Entón os contadores non están a mentir e tampouco o cliente. A evidencia que necesitas está en tres lugares, nesta orde: a dirección á que está ligado o receptor, a ruta que o núcleo usaría para volver ao cliente, e a dirección de orixe no paquete de resposta real.

Como o núcleo elixe a orixe da resposta

Un socket UDP enlazado a0.0.0.0non ten unha dirección de orixe propia, polo que cada resposta saínte provoca unha busca de ruta para o destino. O núcleo logo toma a orixe desa ruta: a dirección marcada pola ruta, ou a dirección principal da interface de saída. Non se lembra nada sobre a dirección de destino da consulta.

Nun host cunha soa conexión isto é invisible, porque só hai unha resposta plausible. Nunha máquina que teña unha dirección LAN, unha dirección WireGuard e unha dirección de xestión, varias respostas son plausibles, e o gañador depende da táboa de enrutamento nese momento. Engade unha ruta extra, unha segunda dirección na mesma interface, un redirixir NAT diante do resolvedor, ou executa AdGuard nun contedor co seu propio espazo de nomes, e a fonte escollida pode diferir da que o cliente consultou.

ss -lunp | grep :53mostra en que xogo estás. Un oínte en0.0.0.0:53é o caso comodín; un oínte en10.6.0.1:53xa pinzou a resposta. Ler o socket é máis rápido que ler o YAML, e reflicte o que realmente está en execución en lugar de o que se gardou por última vez.

O que bind_hosts controla realmente

AdGuard Home'sdns.bind_hostsé a lista de enderezos locais que o ouvinte DNS usa. O valor predeterminado enviado é o comodín, o que significa aceptar en cada enderezo local e deixar que o núcleo elixa a fonte por resposta. Reemplazar o comodín co enderezo que consultan os clientes cambia o socket, e con el o enderezo de orixe en cada resposta.

A lista acepta máis dunha entrada, o que importa nun resolutor que serve a dúas redes. Listar10.6.0.1e192.168.1.10fornece dous sockets ligados, e unha consulta que chega a calquera deles recibe resposta do enderezo no que chegou. Ese é o comportamento que a maioría das persoas supón que o comodín xa proporciona.

O YAML é sinxelo, e o enderezo nel é o que se indicou aos teus clientes de túnel que usaran, non o enderezo principal do host:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Por que dúas instalacións dun resolutor non están de acordo

Xestionado por un plugin, neste contexto, significa que o resolvedor foi instalado e é supervisado por outro paquete: un paquete de firmware de router, un paquete NAS ou un complemento de automatización do fogar. Ese paquete normalmente inclúe a súa propia copia do YAML de AdGuard Home e reinicia o proceso segundo o seu propio horario, mentres que unha instancia independente é o binario ou contedor do provedor que configuras ti mesmo. De calquera forma, estás a mirar dous procesos independentes con arquivos de configuración separados e opcións de enlace separadas, mesmo cando ambos leen a mesma lista de orixe e as mesmas listas de filtros. Un pode enlazar a dirección específica do túnel mentres que o outro herda o comodín, e a interface web parece idéntica desde calquera lado.

É por iso que “o mesmo resolutor funcionaba antes da migración” non demostra nada sobre a vinculación actual. Comproba o socket, logo comproba o ficheiro de configuración que o proceso en funcionamento realmente cargou. Unha copia obsoleta noutro directorio é unha razón común pola que a edición parece non ter efecto.

Abrícea, logo proba desde o lado do túnel

Cambiabind_hostsá dirección do túnel, reinicia o servizo e confirma que o socket se moveu:ss -lunp | grep :53debería agora mostrar10.6.0.1:53e ningunha entrada comodín. Se aínda mostra0.0.0.0,o proceso en funcionamento non está lendo o ficheiro que editou.

Logo proba desde o cliente, porque ese é o único lado que importa. Unha consulta condig @10.6.0.1 example.comexercita o camiño que o usuario exerce, e unha captura no host contcpdump -ni wg0 udp port 53mostra o enderezo de orixe da resposta na rede. Compáreo co enderezo na configuración do resolvedor do cliente; cando son iguais, o tempo de espera deixa de ser un misterio.

ip route get 10.6.0.2explica calquera rareza restante, porque imprime a interface e a fonte que o host usaría de volta ao cliente. Se esa saída nomea a interface LAN, o cambio de enlace non é a solución completa e a táboa de enrutamento é o próximo a ler.

O que a configuración de enlace non pode arranxar

Pinchar o escoitador non repara unha lista de acceso que omite a subrede do túnel, unha regra de cortalumes que permite a consulta pero non a resposta, ou unha ruta faltante de volta á piscina WireGuard. Eses fallan antes ou despois que o enderezo de orixe, e cada un ten un propietario diferente.

Tamén non cambiaa cal upstream o resolvedor reenvía, se a protección contra re-vinculación rexeita unha resposta privada para un nome privado, ou como o cliente aplica os seus propios dominios de busca. Eses son controis separados. Cambia a dirección de vinculación cando a fonte da resposta é incorrecta, e cambia outra cousa cando non o é.