AdGuard Home odgovara WireGuard klijentima s vaše LAN adrese

Tunel je uspostavljen, vatrozid dopušta port 53, AdGuard Home radi, a imena se i dalje ne razrješavaju za WireGuard klijenta. Upit obično dolazi, a odgovor obično odlazi, tako da brojači paketa na resolveru izgledaju zdravi i servis izgleda nevin. Ono što ne valja je izvorišna adresa tog odgovora: odlazi s lokalne adrese koju klijent nikada nije tražio, i klijentov stub resolver ga odbacuje. Jedna lista u konfiguraciji AdGuard Home-a odlučuje o tome, a njezina uobičajena zadana postavka prepušta odluku kernelu.

Upit dolazi, odgovor odlazi s drugog mjesta

Klijent konfiguriran s 10.6.0.1 kao svojim resolverom šalje UDP upit na 10.6.0.1 port 53. Taj paket prolazi kroz tunel i dolazi do hosta, a AdGuard Home odgovara na njega. Na mreži, međutim, odgovor je novi paket čija je izvorišna adresa odabrana od strane hostovog stacka, a ne prema očekivanju klijenta.

Kada je resolver klijenta povezani socket, što koriste systemd-resolved, dnsmasq i većina stub resolvera, prihvaća samo odgovore s točne adrese na koju je poslao upit. Odgovor koji dolazi s 192.168.1.10 na upit poslan na 10.6.0.1 odbacuje se prije nego što se bilo što parsira. Resolver bilježi uspješan odgovor, klijent bilježi timeout i oboje govore istinu.

Dakle, brojila ne lažu, a ni klijent. Dokazi koji su vam potrebni nalaze se na tri mjesta, redom: adresa na koju je slušatelj vezan, ruta koju bi kernel koristio natrag do klijenta i izvorna adresa na stvarnom paketu odgovora.

Kako kernel bira izvor odgovora

UDP soket vezan za0.0.0.0nema vlastitu izvoru adresu, pa svaki odlazni odgovor pokreće pretraživanje rute za odredište. Kernel tada uzima izvor s te rute: adresu koju ruta označava ili primarnu adresu odlaznog sučelja. Ništa o odredišnoj adresi upita se ne pamti.

Na jednom hostu s jednom mrežnom karticom ovo je nevidljivo, jer postoji samo jedan vjerodostojan odgovor. Na stroju koji ima LAN adresu, WireGuard adresu i adresu za upravljanje, nekoliko odgovora je vjerodostojno, a pobjednik ovisi o tablici ruta u tom trenutku. Dodajte dodatnu rutu, drugu adresu na istom sučelju, NAT preusmjeravanje ispred resolvera, ili pokrenite AdGuard u kontejneru s vlastitim prostorom imena, i izabrani izvor može se razlikovati od onoga kojeg je klijent upitao.

ss -lunp | grep :53pokazuje u kojoj ste igri. Slušatelj na0.0.0.0:53je slučaj s jokerom; slušatelj na10.6.0.1:53je već fiksirao odgovor. Čitanje socketa je brže od čitanja YAML-a, i odražava ono što zapravo radi, a ne ono što je posljednje spremljeno.

Ono što bind_hosts zapravo kontrolira

AdGuard Homedns.bind_hostsje popis lokalnih adresa koje DNS slušač koristi. Zadani isporučeni je univerzalni znak, što znači prihvaćanje na svakoj lokalnoj adresi i dopuštanje jezgru da odabere izvor po odgovoru. Zamjena univerzalnog znaka adresom na koju klijenti upućuju upit mijenja socket, i s njim izvorna adresa u svakom odgovoru.

Popis 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, a upit koji stigne na bilo koji od njih odgovara se s adrese na koju je upit stigao. To je ponašanje za koje većina ljudi pretpostavlja da ga univerzalni znak već pruža.

YAML je jednostavan, a adresa u njemu je ona koju su vaši tunelski klijenti dobili za korištenje, a ne primarna adresa hosta:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

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

U ovom kontekstu, „upravlja pluginom“ znači da je resolver instaliran i nadziran od strane drugog paketa: paketa firmwarea rutera, NAS paketa ili dodatka za kućnu automatizaciju. Taj paket obično dolazi sa svojom kopijom AdGuard Home YAML konfiguracije i ponovno pokreće proces prema vlastitom rasporedu, dok je samostalna instanca binarka proizvođača ili kontejner koji sami konfigurirate. U svakom slučaju, radi se o dva neovisna procesa s odvojenim konfiguracijskim datotekama i odvojenim odabirima bind adresa, čak i kad oba čitaju isti popis upstream servera i iste filter liste. Jedan se može vezati na specifičnu adresu tunela, dok drugi nasljeđuje wildcard, a web sučelje izgleda identično s obje strane.

Zato 'isti rješavač radio je prije migracije' ne dokazuje ništa o trenutnom povezivanju. Provjerite utičnicu, zatim provjerite konfiguracijsku datoteku koju je stvarno učitao aktivni proces. Zastarjela kopija u drugom direktoriju često je razlog zbog kojeg uređivanje izgleda da nema učinka.

Pripnite ga, zatim testirajte s tunelske strane

Promijenitebind_hostsu adresu tunela, ponovno pokrenite uslugu i potvrdite da se utičnica premjestila:ss -lunp | grep :53sada bi trebala prikazati10.6.0.1:53i bez unosa sa zamjenskim znakovima. Ako još uvijek prikazuje0.0.0.0,aktivni proces ne čita datoteku koju ste uredili.

Zatim testirajte s klijentske strane, jer je to jedina strana koja je bitna. Upit sdig @10.6.0.1 example.comprolazi kroz put kojim korisnik prolazi, a snimka na računalu stcpdump -ni wg0 udp port 53prikazuje izvornu adresu odgovora na mreži. Usporedite je s adresom u postavkama razlučivača klijenta; kada su jednake, prekid vremena čekanja prestaje biti misterij.

ip route get 10.6.0.2objašnjava svaku preostalu neobičnost, jer ispisuje sučelje i izvor koji bi domaćin koristio da se vrati klijentu. Ako taj ispis navodi LAN sučelje, promjena povezivanja nije potpuno rješenje i sljedeća stvar za provjeru je tablica usmjeravanja.

Što postavka povezivanja ne može popraviti

Zaključavanje slušača ne popravlja popis pristupa koji izostavlja tunelsku podsustav, pravilo vatrozida koje dopušta upit, ali ne i odgovor, ili nedostajući put natrag do WireGuard bazena. Oni zakažu ranije ili kasnije od izvorne adrese, a svaki ima svog vlasnika.

Također ne mijenjana koji se uzvodni razlučivač prosljeđuje, hoće li zaštita od ponovnog povezivanja odbiti privatni odgovor za privatno ime, ili kako klijent primjenjuje vlastite domene pretraživanja. To su odvojene kontrole. Promijenite adresu za povezivanje kada je izvorišna adresa odgovora pogrešna, a nešto drugo promijenite kada nije.