Sinasagot ng AdGuard Home ang mga kliyenteng WireGuard mula sa iyong LAN na address

Bukas ang tunnel, pinapayagan ng firewall ang port 53, tumatakbo ang AdGuard Home, at hindi pa rin na-reresolba ang mga pangalan para sa WireGuard client. Normal na dumarating ang query at normal na umaalis ang sagot, kaya mukhang maayos ang packet counters sa resolver at mukhang walang sala ang serbisyo. Ang mali lang ay ang source address sa sagot na iyon: umaalis ito mula sa lokal na address na hindi kailanman hiniling ng client, at itinapon ito ng stub resolver ng client. Isang listahan sa configuration ng AdGuard Home ang nagdedesisyon nito, at ang karaniwang default nito ay ipinagkakatiwala ang desisyon sa kernel.

Dumadating ang query, ang sagot ay umaalis mula sa ibang lugar

Ang isang kliyente na naka-configure na may 10.6.0.1 bilang kanyang resolver ay nagpapadala ng UDP query sa 10.6.0.1 port 53. Ang pakete na iyon ay tumatawid sa tunnel at dumadating sa host, at sinasagot ito ng AdGuard Home. Sa wire, gayunpaman, ang tugon ay isang bagong pakete na ang pinagmulan na address ay pinili ng stack ng host, hindi ng inaasahan ng kliyente.

Kapag ang resolver ng kliyente ay isang connected socket, na siyang ginagamit ng systemd-resolved, dnsmasq, at karamihan sa mga stub resolver, tinatanggap lamang nito ang mga tugon mula sa eksaktong address na pinadalhan nito. Ang isang tugon na nagmula sa 192.168.1.10 sa isang query na ipinadala sa 10.6.0.1 ay itinatapon bago pa man magkaroon ng parsing. Nagrerehistro ang resolver ng isang matagumpay na sagot, ang kliyente ay nagre-rehistro ng timeout, at pareho silang nagsasabi ng katotohanan.

Kaya ang mga counter ay hindi nagsisinungaling at ganoon din ang kliyente. Ang ebidensiya na kailangan mo ay nasa tatlong lugar, sa ganitong pagkakasunod: ang address na nakatali sa tagapakinig, ang ruta na gagamitin ng kernel pabalik sa kliyente, at ang source address sa aktwal na reply na packet.

Kung paano pinipili ng kernel ang reply source

Isang UDP socket na nakatali sa0.0.0.0ay walang sariling source address, kaya bawat outgoing reply ay nagti-trigger ng route lookup para sa destinasyon. Kukunin ng kernel ang source mula sa rutang iyon: ang address na nakapirmi sa ruta, o ang pangunahing address ng outgoing interface. Wala anumang naaalala tungkol sa destination address ng query.

Sa isang single-homed na host, ito ay hindi nakikita, dahil isa lamang ang posibleng sagot. Sa isang makina na may hawak na LAN address, isang WireGuard address at isang management address, maraming sagot ang posibleng tama, at ang mananalo ay depende sa routing table sa oras na iyon. Magdagdag ng karagdagang ruta, isang pangalawang address sa parehong interface, isang NAT redirect sa harap ng resolver, o patakbuhin ang AdGuard sa isang container na may sariling namespace, at ang napiling source ay maaaring iba sa tinanong ng client.

ss -lunp | grep :53Ipinapakita kung anong laro ang nilalaro mo. Ang isang listener sa0.0.0.0:53ay ang wildcard na kaso; ang listener sa10.6.0.1:53ay naka-pin na ang sagot. Mas mabilis basahin ang socket kaysa sa YAML, at ipinapakita nito kung ano talaga ang tumatakbo sa halip na ang huling na-save.

Ano talaga ang kinokontrol ng bind_hosts

AdGuard Home'sdns.bind_hostsay ang listahan ng mga lokal na address na ginagamit ng DNS listener. Ang default na kasama sa package ay ang wildcard, na nangangahulugang tanggapin sa bawat lokal na address at hayaan ang kernel na piliin ang pinagmulan para sa bawat sagot. Ang pagpapalit ng wildcard sa address na tina-target ng mga kliyente ay nagbabago sa socket, at kasama nito ang pinagmulan na address sa bawat sagot.

Maaaring magkaroon ng higit sa isang entry sa listahan, na mahalaga sa isang resolver na naglilingkod sa dalawang network. Ang paglista ng10.6.0.1at192.168.1.10ay nagbibigay ng dalawang bound na socket, at ang query na dumarating sa alinman sa dalawang ito ay sinasagot mula sa address kung saan ito dumating. Ito ang asal na inaasahan ng karamihan ng tao na ibinibigay na ng wildcard.

Ang YAML ay simple, at ang address dito ay yung sinabi sa iyong mga tunnel client na gamitin, hindi ang pangunahing address ng host:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Bakit hindi nagkakasundo ang dalawang pag-install ng isang resolver

Ang ibig sabihin ng plugin-managed sa kontekstong ito ay ang resolver ay ini-install at pinangangalagaan ng ibang package: isang router firmware package, isang NAS package, o isang home-automation add-on. Karaniwan, ang package na iyon ay may sariling kopya ng YAML ng AdGuard Home at nire-restart ang proseso ayon sa sariling iskedyul, samantalang ang standalone instance ay ang vendor binary o container na ikaw mismo ang nagko-configure. Sa anumang paraan, tinitingnan mo ang dalawang magkakahiwalay na proseso na may sarili nilang configuration files at sariling pagpipilian sa bind, kahit na pareho silang nagbabasa ng parehong upstream list at parehong filter lists. Maaaring i-bind ng isa ang partikular na tunnel address habang ang isa naman ay namamana ang wildcard, at magkapareho ang hitsura ng web interface mula sa alin mang panig.

Iyon ang dahilan kung bakit ang "parehong resolver ay gumana bago ang migration" ay hindi nagpapatunay ng anuman tungkol sa kasalukuyang binding. Suriin ang socket, pagkatapos ay suriin ang configuration file na aktwal na na-load ng tumatakbong proseso. Ang isang luma o stale na kopya sa ibang direktoryo ay isang karaniwang dahilan kung bakit tila walang epekto ang pag-edit.

I-pin ito, pagkatapos subukan mula sa tunnel na bahagi

Palitanbind_hostsng tunnel address, i-restart ang serbisyo, at kumpirmahin na nailipat ang socket:ss -lunp | grep :53dapat na ngayong ipakita ang10.6.0.1:53at walang wildcard entry. Kung nagpapakita pa rin ng0.0.0.0,hindi binabasa ng tumatakbong proseso ang file na iyong inedit.

Pagkatapos subukan mula sa client, dahil iyon lamang ang bahagi na mahalaga. Ang isang query gamit angdig @10.6.0.1 example.comay gumagamit ng path na ginagamit ng user, at ang capture sa host gamit angtcpdump -ni wg0 udp port 53ipinapakita ang source address ng sagot sa network. Ihambing ito sa address sa resolver setting ng client; kapag magkapareho sila, ang timeout ay hindi na misteryo.

ip route get 10.6.0.2ipinaliliwanag ang anumang natitirang kakaiba, dahil ipinapakita nito ang interface at source na gagamitin ng host pabalik sa client. Kung ang output na iyon ay nagbabanggit ng LAN interface, ang pagbabago ng bind ay hindi ang buong solusyon at ang routing table ang susunod na dapat tingnan.

Ano ang hindi kayang ayusin ng bind setting

Ang pag-pin ng listener ay hindi nag-aayos ng access list na hindi kasama ang tunnel subnet, ng firewall rule na nagpapahintulot sa query pero hindi sa sagot, o ng nawawalang ruta pabalik sa WireGuard pool. Ang mga ito ay pumapalya bago o pagkatapos ng source address, at bawat isa ay may ibang may-ari.

Hindi rin nito binabagokung aling upstream ang pinapasa ng resolver, kung tinatanggihan ba ng proteksyon sa rebinding ang isang pribadong sagot para sa isang pribadong pangalan, o kung paano inilalapat ng kliyente ang sarili nitong mga domain ng paghahanap. Magkaibang mga kontrol iyon. Palitan ang bind address kapag mali ang source ng sagot, at palitan ang iba kapag hindi.