AdGuard Home odgovara WireGuard klijentima sa vaše LAN adrese

Tunel je aktivan, firewall dopušta port 53, AdGuard Home radi, ali imena još uvek nisu rešena za WireGuard klijenta. Upit normalno dolazi i odgovor normalno odlazi, tako da brojači paketa na resolveru izgledaju u redu i servis deluje nevin. Ono što ne funkcioniše je izvorna adresa na tom odgovoru: odlazi sa lokalne adrese koju klijent nikada nije tražio, i stub resolver klijenta je odbacuje. Jedna lista u konfiguraciji AdGuard Home odlučuje o tome, a njen uobičajeni podrazumevani izbor prepušta odluku kernelu.

Upit dolazi, odgovor odlazi odnekud drugde

Klijent konfigurisan sa 10.6.0.1 kao svojim rezolverom šalje UDP upit na 10.6.0.1 port 53. Taj paket prelazi tunel i stiže na host, a AdGuard Home na njega odgovara. Na vezi, međutim, odgovor je novi paket čija je adresa izvora odabrana od strane hostovog staka, a ne po očekivanju klijenta.

Kada je klijentov rezolver povezani soket, što je ono što koriste systemd-resolved, dnsmasq i većina stub rezolvera, prihvata samo odgovore sa tačne adrese kojoj je poslao upit. Odgovor koji dolazi sa 192.168.1.10 na upit poslat na 10.6.0.1 odbacuje se pre nego što se izvrši bilo kakvo parsiranje. Rezolver beleži uspešan odgovor, klijent beleži isteka vremena, i oba govore istinu.

Dakle, brojila ne lažu i klijent takođe ne laže. Dokazi koji su vam potrebni nalaze se na tri mesta, u ovom redosledu: adresa na koju je slušač vezan, ruta koju bi kernel koristio da se vrati ka klijentu i adresa izvora na stvarnom paketu odgovora.

Kako kernel bira adresu izvora odgovora

UDP soket vezan za0.0.0.0nema sopstvenu adresu izvora, tako da svaki odlazni odgovor pokreće pretragu rute za odredište. Kernel tada uzima adresu izvora sa te rute: adresu koja je određena rutom ili primarnu adresu odlaznog interfejsa. Ništa u vezi sa adresom odredišta upita se ne pamti.

Na hostu sa jednom mrežnom karticom ovo je nevidljivo, jer postoji samo jedan verovatan odgovor. Na mašini koja ima LAN adresu, WireGuard adresu i adresu za upravljanje, nekoliko odgovora je moguće, i pobednik zavisi od tabele rutiranja u tom trenutku. Dodajte dodatnu rutu, drugu adresu na istom interfejsu, NAT preusmeravanje ispred resolvera, ili pokrenite AdGuard u kontejneru sa sopstvenim namespace-om, i izabrani izvor može biti drugačiji od onog na koji je klijent upitao.

ss -lunp | grep :53pokazuje u kojoj igri se nalazite. Slušalac na0.0.0.0:53je slučaj sa wildcard-om; slušalac na10.6.0.1:53je već odredio odgovor. Čitanje soketa je brže nego čitanje YAML-a i odražava ono što zapravo radi, a ne ono što je poslednje sačuvano.

Ono što bind_hosts zapravo kontroliše

AdGuard Home-adns.bind_hostsje lista lokalnih adresa koje DNS slušač koristi. Podrazumevana, uključena opcija je džoker, što znači da prihvata sve lokalne adrese i dozvoljava kernelu da izabere izvor po odgovoru. Zamena džokera adresom na koju klijenti šalju upit menja soket, a sa njim i adresu izvora na svakom odgovoru.

Lista može sadržati više unosa, što je bitno za rezolver koji služi dve mreže. Navođenje10.6.0.1i192.168.1.10daje dva vezana soketa, i upit koji stigne na bilo koji od njih se odgovara sa adrese na koju je stigao. To je ponašanje koje većina ljudi pretpostavlja da džoker već obezbeđuje.

YAML je jednostavan, i adresa u njemu je ona koju su vaši tunel klijenti dobili kao upotrebljivu, a ne primarna adresa hosta:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Zašto se dve instalacije istog rezolvera ne slažu

U ovom kontekstu, 'Plugin-managed' znači da je resolver instaliran i nadgledan od strane drugog paketa: paketa za ruter firmware, NAS paketa ili dodatka za kućnu automatizaciju. Taj paket obično dolazi sa sopstvenom kopijom AdGuard Home YAML-a i restartuje proces po svom rasporedu, dok je samostalna instanca binarni fajl proizvođača ili kontejner koji sami konfigurišete. U svakom slučaju, imate posla sa dva nezavisna procesa sa odvojenim konfiguracionim fajlovima i odvojenim izborom bind adresa, čak i kada oba čitaju istu listu izvora i iste filter liste. Jedan može da veže specifičnu adresu tunela, dok drugi nasleđuje wildcard, a web interfejs izgleda identično sa obe strane.

To je razlog zašto „isti rešilac je radio pre migracije“ ne dokazuje ništa o trenutnom vezivanju. Proverite soket, a zatim proverite konfiguracioni fajl koji je aktivni proces zapravo učitao. Zastareli primerak u drugom direktorijumu je čest razlog zbog kojeg se čini da izmena nema efekta.

Pričvrstite ga, a zatim testirajte sa strane tunela

Promenitebind_hostsu adresu tunela, restartujte servis, i potvrdite da se soket pomerio:ss -lunp | grep :53sada bi trebalo da pokaže10.6.0.1:53i da ne postoji upis sa džokerom. Ako i dalje pokazuje0.0.0.0,aktivni proces ne čita fajl koji ste izmenili.

Zatim testirajte sa klijentove strane, jer je to jedina strana koja je bitna. Upit sadig @10.6.0.1 example.comprolazi kroz putanju koju korisnik koristi, a snimak na hostu satcpdump -ni wg0 udp port 53prikazuje adresu izvora odgovora na mreži. Uporedite je sa adresom u klijentovom resolver podešavanju; kada su jednake, tajmaut prestaje da bude misterija.

ip route get 10.6.0.2objašnjava preostalu neobičnost, jer ispisuje interfejs i izvor koji bi host koristio da se vrati klijentu. Ako taj izlaz imenuje LAN interfejs, promena bind-a nije kompletno rešenje i tabela rutiranja je sledeća stvar koju treba proveriti.

Šta podešavanje bind-a ne može da popravi

Fiksiranje slušaoca ne ispravlja listu pristupa koja izostavlja tunelsku podsreću, pravilo vatrozida koje dozvoljava upit, ali ne i odgovor, ili nedostajuću rutu nazad ka WireGuard pool-u. Oni otkazuju ranije ili kasnije od adrese izvora, i svaki ima drugačijeg vlasnika.

Takođe ne menjakome resolver prosleđuje upstream, da li zaštita od ponovnog vezivanja odbacuje privatni odgovor za privatno ime, ili kako klijent primenjuje svoja sopstvena pretraživačka domena. To su odvojene kontrole. Promenite adresu vezivanja kada je izvor odgovora pogrešan, a nešto drugo promenite kada nije.