AdGuard Home odgovara WireGuard klijentima s vaše LAN adrese

Tunel je uspostavljen, firewall dopušta port 53, AdGuard Home radi, a imena se i dalje ne rješavaju za WireGuard klijenta. Upit obično stigne i odgovor obično ode, pa brojači paketa na resolveru izgledaju zdravo i servis izgleda nevin. Ono što ne valja je izvorna adresa u tom odgovoru: odlazi s lokalne adrese koju klijent nikada nije tražio, i stub resolver klijenta ga odbacuje. Jedna lista u konfiguraciji AdGuard Home odlučuje o tome, a njen uobičajeni zadani izbor prepušta odluku kernelu.

Upit stigne, odgovor odlazi s negdje drugdje

Klijent konfigurisan sa 10.6.0.1 kao svojom resolver adresom šalje UDP upit na 10.6.0.1 port 53. Taj paket prolazi kroz tunel i stiže na host, a AdGuard Home odgovara na njega. Na mreži, međutim, odgovor je novi paket čija izvorna adresa je odabrana od strane hostovog sistema, a ne prema očekivanju klijenta.

Kada je klijentov resolver povezani soket, što je ono što koriste systemd-resolved, dnsmasq i većina stub resolver-a, on prihvata samo odgovore sa tačno adrese na koju je poslao upit. Odgovor sa adrese 192.168.1.10 upućen na upit poslan na 10.6.0.1 odbacuje se prije nego što se izvrši bilo kakvo parsiranje. Resolver zabilježi uspješan odgovor, klijent zabilježi istekao vremenski period čekanja, i oba govore istinu.

Dakle, brojači ne lažu, niti klijent laže. Dokazi koji su vam potrebni nalaze se na tri mjesta, u ovom redoslijedu: adresa na koju je slušalac vezan, ruta koju bi kernel koristio natrag do klijenta i izvorna adresa na stvarnom odgovarajućem paketu.

Kako kernel bira izvor za odgovor

UDP soket vezan za0.0.0.0nema vlastitu izvornu adresu, pa svaki odlazni odgovor pokreće pretragu rute za odredište. Kernel tada uzima izvor iz te rute: adresu koja je postavljena rutom, ili primarnu adresu izlaznog interfejsa. Ništa vezano za adresu odredišta upita nije zapamćeno.

Na hostu sa jednom mrežnom karticom ovo je nevidljivo, jer postoji samo jedan vjerovatan odgovor. Na mašini koja drži LAN adresu, WireGuard adresu i adresu za upravljanje, nekoliko odgovora je vjerovatno, i pobjednik zavisi od tabele ruta u tom trenutku. Dodajte dodatnu rutu, drugu adresu na istom interfejsu, NAT preusmjeravanje ispred resolvera, ili pokrenite AdGuard u kontejneru sa vlastitim namespace-om, i odabrani izvor može se razlikovati od onog koji je klijent upitao.

ss -lunp | grep :53pokazuje u kojoj ste igri. Slušač na0.0.0.0:53je slučaj sa džokerom; slušač na10.6.0.1:53je već fiksirao odgovor. Čitanje soketa je brže nego čitanje YAML-a, i odražava ono što je stvarno aktivno umjesto onoga što je posljednje sačuvano.

Ono što bind_hosts zapravo kontroliše

AdGuard Home-adns.bind_hostsje lista lokalnih adresa koje DNS slušač koristi. Zadani isporučeni izbor je univerzalna adresa (wildcard), što znači da prihvata na svakoj lokalnoj adresi i dozvoljava kernelu da odabere izvor za svaki odgovor. Zamjena univerzalne adrese sa adresom na koju klijenti šalju upit mijenja socket, a s njim i izvornu adresu na svakom odgovoru.

Lista može sadržavati više od jednog unosa, što je važno za resolver koji služi dvije mreže. Navođenje10.6.0.1i192.168.1.10daje dva vezana socketa, i upit koji stigne na bilo koji od njih se odgovara sa adrese na koju je stigao. To je ponašanje za koje većina ljudi pretpostavlja da ga univerzalna adresa već pruža.

YAML je jednostavan, a adresa u njemu je ona koju su vašim tunnel klijentima rekli da koriste, a ne primarna adresa hosta:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Zašto se dvije instalacije jednog resolvera ne slažu

Plugin-upravljano, u ovom kontekstu, znači da je resolver instaliran i nadgledan od strane drugog paketa: paketa firmvera rutera, NAS paketa ili dodatka za kućnu automatizaciju. Taj paket obično dolazi sa svojom kopijom AdGuard Home-ovog YAML-a i samostalno restartuje proces prema svom rasporedu, dok je samostalna instanca binarni fajl ili kontejner dobavljača koji sami konfigurirate. U svakom slučaju, imate dva nezavisna procesa sa odvojenim konfiguracionim fajlovima i odvojenim odabirima bind-a, čak i kada oba čitaju istu listu upstream servera i iste filter liste. Jedan može vezati specifičnu adresu tunela dok drugi nasljeđuje wildcard, a web interfejs izgleda identično sa obje strane.

Zato "isti resolver je radio prije migracije" ne dokazuje ništa o trenutnom povezivanju. Provjerite soket, zatim provjerite konfiguracijsku datoteku koju je zapravo učitao aktivni proces. Zastarjela kopija u drugom direktoriju je čest razlog zašto izmjena izgleda da nema efekta.

Pinujte je, zatim testirajte sa strane tunela

Promijenitebind_hostsna adresu tunela, restartujte servis i potvrdite da se soket pomjerio:ss -lunp | grep :53sada bi trebao prikazati10.6.0.1:53i bez unosa sa wildcard-om. Ako još uvijek prikazuje0.0.0.0,tada aktivni proces ne čita datoteku koju ste uredili.

Zatim testirajte sa klijentske strane, jer je to jedina strana koja je bitna. Upit sadig @10.6.0.1 example.comaktivira put kojim korisnik prolazi, a snimak na hostu satcpdump -ni wg0 udp port 53prikazuje izvor adresu odgovora na mreži. Uporedite je sa adresom u postavkama klijentskog resolvera; kada su jednake, vremensko ograničenje prestaje da bude misterija.

ip route get 10.6.0.2objašnjava preostalu neobičnost, jer ispisuje interfejs i izvor koji bi host koristio pri povratku klijentu. Ako taj izlaz imenuje LAN interfejs, promjena bind-a nije kompletno rješenje i sljedeća stvar koju treba provjeriti je tabela rutiranja.

Šta bind postavka ne može popraviti

Zaključavanje slušača ne popravlja listu pristupa koja preskače tunelsku podmrežu, pravilo firewall-a koje dozvoljava upit, ali ne i odgovor, ili nedostajuću rutu natrag do WireGuard pool-a. Oni ne uspijevaju ranije ili kasnije od izvorne adrese, i svaki ima različitog vlasnika.

Takođe ne mijenjakojem upstream-u resolver prosleđuje, da li zaštita od ponovnog povezivanja odbija privatni odgovor za privatno ime, ili kako klijent primjenjuje vlastite domene pretrage. To su odvojene kontrole. Promijenite bind adresu kada je izvor odgovora netačan, i promijenite nešto drugo kada nije.