AdGuard Home responde a los clientes de WireGuard desde la dirección de tu LAN

El túnel está activo, el firewall permite el puerto 53, AdGuard Home está funcionando, y los nombres aún no se resuelven para el cliente de WireGuard. La consulta normalmente llega y una respuesta normalmente sale, por lo que los contadores de paquetes en el resolvedor parecen saludables y el servicio parece inocente. Lo que falla es la dirección de origen en esa respuesta: sale desde una dirección local que el cliente nunca pidió, y el resolvedor simple del cliente la descarta. Una lista en la configuración de AdGuard Home decide esto, y su valor predeterminado usual delega la decisión al kernel.

La consulta llega, la respuesta sale desde otro lugar

Un cliente configurado con 10.6.0.1 como su resolvedor envía una consulta UDP a 10.6.0.1 puerto 53. Ese paquete cruza el túnel y llega al host, y AdGuard Home lo responde. Sin embargo, en la red, la respuesta es un paquete nuevo cuya dirección de origen es elegida por la pila del host, no por la expectativa del cliente.

Cuando el resolvedor del cliente es un socket conectado, que es lo que usan systemd-resolved, dnsmasq y la mayoría de los resolvedores stub, solo acepta respuestas de la dirección exacta a la que envió la consulta. Una respuesta proveniente de 192.168.1.10 a una consulta enviada a 10.6.0.1 se descarta antes de que ocurra cualquier análisis. El resolvedor registra una respuesta exitosa, el cliente registra un tiempo de espera, y ambos están diciendo la verdad.

Así que los contadores no mienten y tampoco lo hace el cliente. La evidencia que necesitas está en tres lugares, en este orden: la dirección a la que está vinculado el oyente, la ruta que el kernel usaría de regreso al cliente, y la dirección de origen en el paquete de respuesta real.

Cómo el kernel elige la fuente de la respuesta

Un socket UDP enlazado a0.0.0.0no tiene dirección de origen propia, por lo que cada respuesta saliente desencadena una búsqueda de ruta para el destino. El kernel entonces toma la fuente de esa ruta: la dirección fijada por la ruta, o la dirección principal de la interfaz de salida. Nada sobre la dirección de destino de la consulta se recuerda.

En un host con una sola conexión a la red, esto es invisible, porque solo hay una respuesta posible. En una máquina que tiene una dirección LAN, una dirección de WireGuard y una dirección de gestión, varias respuestas son plausibles, y el ganador depende de la tabla de enrutamiento en ese momento. Agrega una ruta extra, una segunda dirección en la misma interfaz, una redirección NAT delante del resolvedor, o ejecuta AdGuard en un contenedor con su propio espacio de nombres, y la fuente elegida puede diferir de la que el cliente consultó.

ss -lunp | grep :53muestra en qué juego estás. Un oyente en0.0.0.0:53es el caso comodín; un oyente en10.6.0.1:53ya ha fijado la respuesta. Leer el socket es más rápido que leer el YAML, y refleja lo que realmente se está ejecutando en lugar de lo que se guardó por última vez.

Lo que bind_hosts realmente controla

AdGuard Home'sdns.bind_hostses la lista de direcciones locales que el listener DNS utiliza. El valor predeterminado incluido es el comodín, lo que significa aceptar en cada dirección local y dejar que el kernel elija la fuente por respuesta. Reemplazar el comodín con la dirección que consultan los clientes cambia el socket, y con él la dirección de origen en cada respuesta.

La lista puede contener más de una entrada, lo que importa en un resolvedor que sirve a dos redes. Enumerar10.6.0.1y192.168.1.10da como resultado dos sockets enlazados, y una consulta que llegue a cualquiera de ellos se responde desde la dirección por la que llegó. Ese es el comportamiento que la mayoría de las personas asume que el comodín ya proporciona.

El YAML es sencillo, y la dirección en él es la que se le indicó a sus clientes de túnel que usaran, no la dirección principal del host:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Por qué dos instalaciones de un mismo resolvedor no están de acuerdo

Administrado por un complemento, en este contexto, significa que el resolutor fue instalado y está supervisado por otro paquete: un paquete de firmware de enrutador, un paquete NAS o un complemento de automatización del hogar. Ese paquete normalmente incluye su propia copia del YAML de AdGuard Home y reinicia el proceso según su propio horario, mientras que una instancia independiente es el binario del proveedor o el contenedor que configuras tú mismo. De cualquier manera, estás viendo dos procesos independientes con archivos de configuración separados y opciones de enlace separadas, incluso cuando ambos leen la misma lista de upstream y las mismas listas de filtros. Uno puede enlazar la dirección específica del túnel mientras que el otro hereda el comodín, y la interfaz web se ve idéntica desde cualquiera de los lados.

Es por eso que "el mismo resolvedor funcionó antes de la migración" no prueba nada sobre la vinculación actual. Revisa el socket, luego revisa el archivo de configuración que el proceso en ejecución realmente cargó. Una copia obsoleta en otro directorio es una razón común por la que la edición parece no tener efecto.

Anclalo, luego prueba desde el lado del túnel

Cambiabind_hostspor la dirección del túnel, reinicia el servicio y confirma que el socket se movió:ss -lunp | grep :53ahora debería mostrar10.6.0.1:53y no una entrada comodín. Si todavía muestra0.0.0.0,el proceso en ejecución no está leyendo el archivo que editaste.

Luego prueba desde el cliente, porque ese es el único lado que importa. Una consulta condig @10.6.0.1 example.comejercita la ruta que el usuario usa, y una captura en el host contcpdump -ni wg0 udp port 53muestra la dirección de origen de la respuesta en la red. Compárala con la dirección en la configuración del resolvedor del cliente; cuando son iguales, el tiempo de espera deja de ser un misterio.

ip route get 10.6.0.2explica cualquier rareza restante, porque imprime la interfaz y la fuente que el host usaría para devolvérselo al cliente. Si esa salida nombra la interfaz LAN, el cambio de enlace no es la solución completa y la tabla de enrutamiento es lo siguiente que hay que revisar.

Lo que la configuración de enlace no puede arreglar

Fijar el oyente no repara una lista de acceso que omite la subred del túnel, una regla de firewall que permite la consulta pero no la respuesta, o una ruta faltante de vuelta al grupo de WireGuard. Esos fallan antes o después que la dirección de origen, y cada uno tiene un propietario diferente.

Tampoco cambiaa qué upstream reenvía el resolvedor, ya sea que la protección contra re-vinculación rechace una respuesta privada para un nombre privado, o cómo el cliente aplica sus propios dominios de búsqueda. Esos son controles separados. Cambie la dirección de enlace cuando la fuente de la respuesta sea incorrecta, y cambie otra cosa cuando no lo sea.