AdGuard Home răspunde clienților WireGuard de la adresa LAN a dvs.

Tunelul este activ, firewall-ul permite portul 53, AdGuard Home rulează, și numele tot nu se rezolvă pentru clientul WireGuard. Interogarea ajunge de obicei și un răspuns pleacă de obicei, astfel că contoarele de pachete de pe resolver arată sănătoase și serviciul pare nevinovat. Ceea ce merge prost este adresa sursă de pe acel răspuns: aceasta pleacă de la o adresă locală pe care clientul nu a cerut-o niciodată, iar resolverul stub al clientului o aruncă. O listă din configurarea AdGuard Home decide acest lucru, iar implicarea sa obișnuită dă decizia kernelului.

Interogarea ajunge, răspunsul pleacă din altă parte

Un client configurat cu 10.6.0.1 ca rezolvator trimite o interogare UDP către 10.6.0.1 port 53. Pachetul traversează tunelul și ajunge pe gazdă, iar AdGuard Home îi răspunde. Pe cablu, însă, răspunsul este un pachet nou a cărui adresă sursă este aleasă de stack-ul gazdei, nu de așteptarea clientului.

Când rezolvatorul clientului este un socket conectat, ceea ce folosesc systemd-resolved, dnsmasq și majoritatea rezolvatorilor stub, acesta acceptă doar răspunsuri de la adresa exactă la care a trimis. Un răspuns cu sursa 192.168.1.10 la o interogare trimisă către 10.6.0.1 este respins înainte să aibă loc orice parsare. Rezolvatorul înregistrează un răspuns reușit, clientul înregistrează un timeout, și ambele spun adevărul.

Deci contoarele nu mint și nici clientul nu mint. Dovezile de care ai nevoie se află în trei locuri, în această ordine: adresa la care este legat ascultătorul, ruta pe care kernelul ar folosi-o pentru a reveni la client și adresa sursă de pe pachetul de răspuns propriu-zis.

Cum alege kernelul sursa răspunsului

Un socket UDP legat la0.0.0.0nu are o adresă sursă proprie, așa că fiecare răspuns care pleacă declanșează o căutare a rutei către destinație. Kernelul ia apoi sursa din acea rută: adresa fixată de rută sau adresa principală a interfeței de ieșire. Nimic din adresa de destinație a interogării nu este memorat.

Pe un host cu o singură interfață acest lucru este invizibil, deoarece există doar un singur răspuns plauzibil. Pe o mașină care deține o adresă LAN, o adresă WireGuard și o adresă de management, mai multe răspunsuri sunt plauzibile, iar câștigătorul depinde de tabela de rutare în acel moment. Adăugați o rută suplimentară, o a doua adresă pe aceeași interfață, un redirect NAT în fața resolver-ului, sau rulați AdGuard într-un container cu propriul său namespace, iar sursa aleasă poate diferi de cea interogată de client.

ss -lunp | grep :53arată în ce joc sunteți. Un listener pe0.0.0.0:53este cazul wildcard; un listener pe10.6.0.1:53a fixat deja răspunsul. Citirea socket-ului este mai rapidă decât citirea YAML-ului și reflectă ceea ce rulează efectiv, nu ceea ce a fost salvat ultima dată.

Ceea ce controlează de fapt bind_hosts

AdGuard Homedns.bind_hostseste lista adreselor locale pe care le folosește ascultătorul DNS. Implicitul furnizat este wildcard-ul, ceea ce înseamnă acceptarea pe fiecare adresă locală și lăsarea nucleului să aleagă sursa pentru fiecare răspuns. Înlocuirea wildcard-ului cu adresa la care clienții fac interogări schimbă socket-ul și, odată cu el, adresa sursă pentru fiecare răspuns.

Lista poate avea mai multe intrări, ceea ce contează într-un resolver care deservește două rețele. Listarea10.6.0.1și192.168.1.10oferă două socket-uri legate, iar o interogare care ajunge la oricare dintre ele este răspunsă de pe adresa pe care a sosit. Aceasta este comportarea pe care majoritatea oamenilor o presupun că wildcard-ul o oferă deja.

YAML-ul este simplu, iar adresa din el este cea pe care clienții tunelului au fost instruiți să o folosească, nu adresa primară a gazdei:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

De ce două instalații ale aceluiași resolver nu sunt de acord

Gestionat de plugin, în acest context, înseamnă că rezolvatorul a fost instalat și este supravegheat de un alt pachet: un pachet de firmware pentru router, un pachet NAS sau un add-on de automatizare a casei. Acest pachet de obicei livrează propria sa copie a YAML-ului AdGuard Home și repornește procesul după propriul program, în timp ce o instanță independentă este binarul sau containerul furnizorului pe care îl configurezi singur. În ambele cazuri, te confrunți cu două procese independente, cu fișiere de configurare separate și alegeri de binding separate, chiar dacă ambele citesc aceeași listă upstream și aceleași liste de filtre. Unul se poate lega de o adresă de tunel specifică, în timp ce celălalt moștenește wildcard-ul, iar interfața web arată identic din ambele părți.

De aceea „același resolver a funcționat înainte de migrare” nu dovedește nimic despre legătura actuală. Verifică socket-ul, apoi verifică fișierul de configurare pe care îl încarcă efectiv procesul în execuție. O copie învechită într-un alt director este un motiv comun pentru care modificarea pare să nu aibă efect.

Fixează-l, apoi testează de pe partea tunelului

Înlocuieștebind_hostscu adresa tunelului, repornește serviciul și confirmă că socket-ul s-a mutat:ss -lunp | grep :53ar trebui acum să arate10.6.0.1:53și să nu existe intrare wildcard. Dacă încă arată0.0.0.0,procesul în execuție nu citește fișierul pe care l-ai editat.

Apoi testează de la client, deoarece aceasta este singura parte care contează. O interogare cudig @10.6.0.1 example.comtestează calea pe care o folosește utilizatorul, iar o captură pe gazdă cutcpdump -ni wg0 udp port 53arată adresa sursă a răspunsului pe cablu. Compar-o cu adresa din setarea resolverului clientului; atunci când sunt egale, timeout-ul încetează să mai fie o enigmă.

ip route get 10.6.0.2explică orice ciudățenie rămasă, deoarece afișează interfața și sursa pe care gazda le-ar folosi pentru a răspunde clientului. Dacă acea ieșire indică interfața LAN, schimbarea bind nu este întreaga soluție, iar tabelul de rutare este următorul lucru de citit.

Ce nu poate repara setarea bind

Fixarea ascultătorului nu repară o listă de acces care omite subnetul tunelului, o regulă de firewall care permite interogarea, dar nu și răspunsul, sau o rută lipsă către pool-ul WireGuard. Acestea eșuează mai devreme sau mai târziu decât adresa sursă și fiecare are un proprietar diferit.

De asemenea, nu schimbăcătre care upstream trimite resolverul interogarea, dacă protecția împotriva reatașării respinge un răspuns privat pentru un nume privat sau cum aplică clientul propriile sale domenii de căutare. Acestea sunt controale separate. Schimbați adresa de legare atunci când sursa răspunsului este greșită și schimbați altceva atunci când nu este.