Predor je vzpostavljen, požarni zid dovoljuje vrata 53, AdGuard Home deluje, ime pa se za WireGuard odjemalca še vedno ne razrešuje. Poizvedba običajno prispe in odgovor običajno odide, zato števci paketov na resolverju izgledajo zdravo in storitev se zdi neškodljiva. Kar gre narobe, je izvorni naslov tega odgovora: odhaja z lokalnega naslova, ki ga odjemalec nikoli ni zahteval, in odjemalčev stub resolver ga zavrže. En seznam v konfiguraciji AdGuard Home odloča o tem, in njegova običajna privzeta nastavitev prepusti odločitev jedru.

Poizvedba prispe, odgovor odide od drugod

Odjemalec, konfiguriran z naslovom 10.6.0.1 kot svojim razreševalcem, pošlje UDP poizvedbo na 10.6.0.1, vrata 53. Ta paket prečka tunel in pristane na gostitelju, AdGuard Home pa nanj odgovori. Vendar pa je na liniji odgovor nov paket, katerega izvorni naslov izbere sklad gostitelja, ne pa pričakovanje odjemalca.

Ko je razreševalec odjemalca povezan soket, kar uporabljata systemd-resolved, dnsmasq in večina vmesnih razreševalcev, sprejema le odgovore iz točno naslova, na katerega je poslal. Odgovor, ki prihaja z naslova 192.168.1.10 na poizvedbo, poslano na 10.6.0.1, je zavrnjen pred kakršnim koli razčlenjevanjem. Razreševalec zabeleži uspešen odgovor, odjemalec zabeleži časovno omejitev, in oba govorita resnico.

Torej števec ne laže in tudi stranka ne. Dokazi, ki jih potrebujete, so na treh mestih, v tem vrstnem redu: naslov, na katerega je vezan poslušalec, pot, ki bi jo jedro uporabilo nazaj do odjemalca, in naslov izvora na dejanski odgovorjeni paket.

Kako jedro izbere izvor odgovora

UDP vmesnik vezan na0.0.0.0nima svojega naslova izvora, zato vsak odhodni odgovor sproži iskanje poti do cilja. Jedro nato uporabi izvor iz te poti: naslov, določeno s poti, ali primarni naslov odhodnega vmesnika. Ničesar o ciljnem naslovu poizvedbe se ne shrani.

Na gostitelju z enim omrežjem je to nevidno, ker obstaja samo en verjeten odgovor. Na računalniku z naslovom LAN, naslovom WireGuard in naslovom za upravljanje je več odgovorov verjetnih, in zmagovalec je odvisen od tistega trenutnega usmerjevalnega seznama. Dodajte dodatno pot, drugi naslov na istem vmesniku, NAT preusmeritev pred razrejevalnikom ali zaženite AdGuard v kontejnerju s svojim lastnim imenskim prostorom, in izbrani vir se lahko razlikuje od tistega, ki ga je poizpraševal stranka.

ss -lunp | grep :53prikazuje, v kateri igri ste. Poslušalec na0.0.0.0:53je primer z zvezdico; poslušalec na10.6.0.1:53je že določil odgovor. Branje priključka je hitrejše kot branje YAML in odraža, kaj dejansko teče, namesto kaj je bilo nazadnje shranjeno.

Kaj bind_hosts dejansko nadzoruje

AdGuard Home-adns.bind_hostsje seznam lokalnih naslovov, ki jih uporablja DNS poslušalec. Privzeto, kar je priloženo, je nadomestni znak (*), kar pomeni, da sprejema na vsak lokalni naslov in pusti jedru, da izbere izvor za vsak odgovor. Zamenjava nadomestnega znaka z naslovom, na katerega se kličejo odjemalci, spremeni vtičnico in s tem izvorni naslov pri vsakem odgovoru.

Seznam lahko vsebuje več kot en vnos, kar je pomembno pri reševanju za dve omrežji. Navedba10.6.0.1in192.168.1.10dajeta dve vezani vtičnici, in poizvedba, ki prispe na katero koli, je odgovorjena z naslova, na katerega je prispela. To je vedenje, ki ga večina ljudi predvideva, da nadomestni znak že omogoča.

YAML je preprost, naslov v njem pa je tisti, ki so ga vaši tunelski odjemalci dobili za uporabo, ne primarni naslov gostitelja:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Zakaj se dve namestitvi enega razreševalnika ne strinjata

V tem kontekstu upravljano z vtičniki pomeni, da je rešilec nameščen in nadzorovan s strani drugega paketa: paketa z usmerjevalno programsko opremo, paketa NAS ali dodatka za avtomatizacijo doma. Ta paket običajno vsebuje svojo kopijo YAML datoteke AdGuard Home in ponovno zažene proces po svojem urniku, medtem ko je samostojna instanca binarna datoteka ali kontejner, ki ga konfigurirate sami. Tako ali tako gre za dva neodvisna procesa z ločenimi konfiguracijskimi datotekami in ločenimi izbirami vezave, tudi ko oba bereta isti zgornji seznam in iste filtre. Eden lahko veže specifičen naslov tunela, medtem ko drugi podeduje nadomestni znak, spletni vmesnik pa je identičen z obeh strani.

Zato ''isti razreševalnik je deloval pred migracijo'' ne dokazuje ničesar o trenutni vezavi. Preverite vtičnico, nato preverite konfiguracijsko datoteko, ki jo je dejansko naložil tekoči proces. Zastarela kopija v drugem imeniku je pogost razlog, da se sprememba ne zdi učinkovita.

Pripnite jo in nato testirajte z ameriške strani tunela

Zamenjajtebind_hostsz naslovom tunela, znova zaženite storitev in potrdite, da se je vtičnica premaknila:ss -lunp | grep :53bi zdaj morala prikazovati10.6.0.1:53in brez wildcard vnosa. Če še vedno prikazuje0.0.0.0,tekoči proces ne bere datoteke, ki ste jo uredili.

Nato testirajte s strani odjemalca, ker je to edina stran, ki je pomembna. Poizvedba zdig @10.6.0.1 example.comuporablja pot, ki jo uporablja uporabnik, in zajem na gostitelju stcpdump -ni wg0 udp port 53prikaže naslov izvora odgovora na omrežju. Primerjajte ga z naslovom v nastavitvi reševalca na odjemalcu; ko sta enaka, preneha biti časovna omejitev skrivnost.

ip route get 10.6.0.2razloži preostale nenavadnosti, saj izpiše vmesnik in izvor, ki bi ju gostitelj uporabil nazaj do odjemalca. Če ta izpis navaja LAN vmesnik, sprememba vezave ni celotna rešitev in naslednja stvar za pregled je usmerjevalna tabela.

Kaj nastavitve vezave ne morejo popraviti

Pripenjanje poslušalca ne popravi seznama za dostop, ki izpušča tunelsko podsplo, pravila požarnega zidu, ki dovoljujejo poizvedbo, a ne odgovora, ali manjkajoče poti nazaj do WireGuard bazena. Te odpovedi se zgodijo prej ali pozneje kot naslov izvora, in vsaka ima drugega lastnika.

Prav tako ne spremenikateremu zgornjemu strežniku reševalec posreduje, ali zaščita pred ponovnim vezanjem zavrne zaseben odgovor za zasebno ime, ali pa kako odjemalec uporablja lastne iskalne domene. To so ločeni nadzorni mehanizmi. Spremenite naslov vezave, ko je vir odgovora napačen, in spremenite nekaj drugega, ko ni.

Sorodni članki