AdGuard Home respon als clients WireGuard des de l'adreça LAN

El túnel està actiu, el tallafoc permet el port 53, AdGuard Home està funcionant i els noms encara no es resolen per al client de WireGuard. La consulta normalment arriba i una resposta normalment surt, per la qual cosa els comptadors de paquets al resolutor semblen saludables i el servei sembla innocent. El que falla és l'adreça d'origen d'aquesta resposta: surt d'una adreça local que el client mai va demanar, i el resolutor intermedi del client l'envia a la paperera. Una llista a la configuració d'AdGuard Home decideix això, i el seu valor predeterminat habitual passa la decisió al nucli.

La consulta arriba, la resposta surt des d'un altre lloc

Un client configurat amb 10.6.0.1 com a resolutor envia una consulta UDP a 10.6.0.1 port 53. Aquest paquet travessa el túnel i arriba a l'amfitrió, i AdGuard Home hi respon. Al cable, però, la resposta és un paquet nou la direcció d'origen del qual és escollida per la pila de l'amfitrió, no per l'expectativa del client.

Quan el resolutor del client és un socket connectat, que és el que utilitzen systemd-resolved, dnsmasq i la majoria de resolutors stub, només accepta respostes de l'adreça exacta a la qual va enviar. Una resposta que té com a origen 192.168.1.10 per a una consulta enviada a 10.6.0.1 es descarta abans que passi qualsevol anàlisi. El resolutor registra una resposta satisfactòria, el client registra un temps d'espera, i tots dos diuen la veritat.

Així que els comptadors no menteixen i tampoc el client. Les proves que necessites estan en tres llocs, en aquest ordre: l'adreça a la qual està vinculat l'oient, la ruta que el nucli utilitzaria de tornada al client, i l'adreça d'origen en el paquet de resposta real.

Com escull el nucli l'origen de la resposta

Un socket UDP vinculat a0.0.0.0no té una adreça d'origen pròpia, així que cada resposta sortint desencadena una cerca de ruta cap a la destinació. El nucli després agafa l'origen d'aquesta ruta: l'adreça fixada per la ruta, o l'adreça principal de la interfície de sortida. Res de l'adreça de destinació de la consulta no es recorda.

En un host amb una sola connexió, això és invisible, perquè només hi ha una resposta plausible. En una màquina que té una adreça LAN, una adreça WireGuard i una adreça de gestió, diverses respostes són plausibles, i el guanyador depèn de la taula de rutes en aquest moment. Afegeix una ruta extra, una segona adreça a la mateixa interfície, un redireccionament NAT davant del resolutor o executa AdGuard en un contenidor amb el seu propi espai de noms, i la font escollida pot diferir de la que va consultar el client.

ss -lunp | grep :53mostra en quin joc estàs. Un oient en0.0.0.0:53és el cas comodí; un oient en10.6.0.1:53ja ha fixat la resposta. Llegir el socket és més ràpid que llegir el YAML, i reflecteix el que realment s'està executant en comptes del que es va guardar l'última vegada.

El que realment controla bind_hosts

AdGuard Home'sdns.bind_hostsés la llista d'adreces locals que utilitza l'escoltador DNS. El valor predeterminat enviat és el comodí, que significa acceptar en totes les adreces locals i deixar que el nucli triï la font per cada resposta. Substituir el comodí per l'adreça que consulten els clients canvia el socket, i amb ell l'adreça de la font en cada resposta.

La llista pot contenir més d'una entrada, cosa que és important en un resolutor que serveix a dues xarxes. Llistar10.6.0.1i192.168.1.10dóna dos sockets vinculats, i una consulta que arribi a qualsevol d'ells rep resposta des de l'adreça per la qual va arribar. Aquest és el comportament que la majoria de la gent presumeix que el comodí ja proporciona.

El YAML és senzill, i l'adreça que hi ha és la que se'ls ha indicat d'utilitzar als clients del túnel, no l'adreça principal de l'amfitrió:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Per què dues instal·lacions d'un resolutor no coincideixen

Gestionat per un complement, en aquest context, significa que el resolutor va ser instal·lat i està supervisat per un altre paquet: un paquet de firmware de router, un paquet de NAS o un complement d’automatització de la llar. Aquest paquet normalment envia la seva pròpia còpia del YAML d’AdGuard Home i reinicia el procés segons el seu propi horari, mentre que una instància independent és el binari o contenidor del proveïdor que configureu vosaltres mateixos. De qualsevol manera, es tracta de dos processos independents amb fitxers de configuració separats i opcions de vinculació separades, encara que ambdós llegeixin la mateixa llista de servidor amunt i les mateixes llistes de filtres. Un pot vincular l’adreça específica del túnel mentre que l’altre hereta el comodí, i la interfície web sembla idèntica des de qualsevol dels costats.

Per això, "el mateix resolutor funcionava abans de la migració" no demostra res sobre l'enllaç actual. Comprova el socket i després comprova el fitxer de configuració que el procés en execució realment ha carregat. Una còpia obsoleta en un altre directori és una raó comuna per la qual l'edició sembla no tenir efecte.

Fixeu-lo, després proveu des del costat del túnel

Canvieubind_hostsper l'adreça del túnel, reinicieu el servei i confirmeu que el socket s'ha mogut:ss -lunp | grep :53hauria de mostrar ara10.6.0.1:53i cap entrada wildcard. Si encara mostra0.0.0.0,el procés en execució no està llegint el fitxer que heu editat.

Llavors proveu des del client, perquè aquest és l'únic costat que importa. Una consulta ambdig @10.6.0.1 example.comutilitza el camí que l'usuari utilitza, i una captura a l'amfitrió ambtcpdump -ni wg0 udp port 53mostra l'adreça d'origen de la resposta al cable. Compara-la amb l'adreça a la configuració del resolutor del client; quan són iguals, el temps d'espera deixa de ser misteriós.

ip route get 10.6.0.2explica qualsevol estranyesa restant, perquè imprimeix la interfície i l'origen que l'amfitrió faria servir de tornada al client. Si aquesta sortida mostra la interfície de LAN, el canvi de lligam no és la solució completa i la taula de rutes és el següent que cal llegir.

El que la configuració de lligam no pot arreglar

Ficar el listener no repara una llista d'accés que omet la subxarxa del túnel, una regla de tallafocs que permet la consulta però no la resposta, o una ruta perdida de tornada al pool de WireGuard. Aquests fallen abans o després que l'adreça d'origen, i cadascun té un propietari diferent.

Tampoc no canviaa quin upstream el resolutor reenvia, ja sigui si la protecció contra la reassignació rebutja una resposta privada per a un nom privat, o com el client aplica els seus propis dominis de cerca. Aquests són controls separats. Canvia l'adreça de vinculació quan la font de la resposta sigui incorrecta, i canvia alguna altra cosa quan no ho sigui.