AdGuard Home respondas al WireGuard-klientoj el via LAN-adreso

La tunelo estas aktiva, la fajroŝirmilo permesas pordon 53, AdGuard Home funkcias, kaj la nomoj tamen ne solviĝas por la WireGuard-kliento. La demando kutime alvenas kaj respondo kutime foriras, do la pakaĵnombriloj de la solvilo aspektas sanaj kaj la servo ŝajnas senkulpa. Kio misfunkcias, estas la fonta adreso de tiu respondo: ĝi foriras el loka adreso, kiun la kliento neniam demandis, kaj la stub-solvilo de la kliento ĵetas ĝin for. Unu listo en la agordo de AdGuard Home decidas tion, kaj ĝia kutima defaŭlto transdonas la decidon al la kerno.

La demando alvenas, la respondo foriras de aliloke

Kliento agordita kun 10.6.0.1 kiel sia solvilo sendas UDP-demandon al 10.6.0.1 pordon 53. Tiu pakaĵo trapasas la tunelon kaj surteriĝas ĉe la gastiganto, kaj AdGuard Home respondas ĝin. Sur la drato, tamen, la respondo estas nova pakaĵo, kies fontan adreson elektas la stako de la gastiganto, ne la atendado de la kliento.

Kiam la solvilo de la kliento estas konektita ingo, kion uzas systemd-resolved, dnsmasq kaj plej multaj stub-solviloj, ĝi akceptas nur respondojn de la ĝusta adreso, al kiu ĝi sendis. Respondo fontanta el 192.168.1.10 al demando sendita al 10.6.0.1 estas forĵetata antaŭ ol okazas ajna analizado. La solvilo registras sukcesan respondon, la kliento registras tempolimon, kaj ambaŭ diras la veron.

Do la nombriloj ne mensogas, kaj nek la kliento. La pruvojn vi bezonas en tri lokoj, en ĉi tiu ordo: la adreso, al kiu la aŭskultanto estas bindita, la itinero, kiun la kerno uzus reen al la kliento, kaj la fonta adreso sur la reala responda pakaĵo.

Kiel la kerno elektas la respondan fonton

UDP-ingo bindita al 0.0.0.0 mem ne havas fontan adreson, do ĉiu eliranta respondo kaŭzas serĉon de itinero al la celo. La kerno tiam prenas la fonton el tiu itinero: la adreson fiksitan de la itinero, aŭ la ĉefan adreson de la elira interfaco. Nenio pri la cela adreso de la demando estas memorata.

Sur unuhejma gastiganto tio estas nevidebla, ĉar estas nur unu kredebla respondo. Sur maŝino havanta LAN-adreson, WireGuard-adreson kaj administran adreson, pluraj respondoj estas kredeblaj, kaj la venkinto dependas de la itinera tabelo en tiu momento. Aldonu plian itineron, duan adreson sur la sama interfaco, NAT-redirektadon antaŭ la solvilo, aŭ rulu AdGuard en ujo kun propra nomspaco, kaj la elektita fonto povas diferenci de tiu, kiun la kliento demandis.

ss -lunp | grep :53 montras, en kiu ludo vi estas. Aŭskultanto sur 0.0.0.0:53 estas la ĵokera kazo; aŭskultanto sur 10.6.0.1:53 jam fiksis la respondon. Legi la ingon estas pli rapide ol legi la YAML, kaj ĝi montras tion, kio efektive funkcias, anstataŭ tion, kio laste estis konservita.

Kion bind_hosts efektive regas

La dns.bind_hosts de AdGuard Home estas la listo de lokaj adresoj, kiujn la DNS-aŭskultanto uzas. La liverita defaŭlto estas la ĵokero, kio signifas akcepti sur ĉiu loka adreso kaj lasi al la kerno elekti la fonton por ĉiu respondo. Anstataŭigi la ĵokeron per la adreso, kiun demandas la klientoj, ŝanĝas la ingon kaj kun ĝi la fontan adreson de ĉiu respondo.

La listo akceptas pli ol unu eron, kio gravas ĉe solvilo servanta du retojn. Listigi 10.6.0.1 kaj 192.168.1.10 donas du binditajn ingojn, kaj demando alvenanta sur iu ajn el ili estas respondata el la adreso, sur kiun ĝi alvenis. Tion plej multaj homoj supozas, ke la ĵokero jam provizas.

La YAML estas simpla, kaj la adreso en ĝi estas tiu, kiun oni diris al viaj tunelaj klientoj uzi, ne la ĉefa adreso de la gastiganto:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Kial du instalaĵoj de unu solvilo malkonsentas

Plugin-managed, tio estas administrata de kromprogramo, en ĉi tiu kunteksto signifas, ke la solvilon instalis kaj kontrolas alia pakaĵo: enkursiga firmvara pakaĵo, NAS-pakaĵo aŭ hejmaŭtomatiga aldonaĵo. Tiu pakaĵo kutime liveras sian propran kopion de la YAML de AdGuard Home kaj restartigas la procezon laŭ sia propra horaro, dum memstara instanco estas la vendista binaraĵo aŭ ujo, kiun vi mem agordas. Ĉiel ajn, vi rigardas du sendependajn procezojn kun apartaj agordaj dosieroj kaj apartaj bind-elektoj, eĉ kiam ambaŭ legas la saman upstream-liston kaj la samajn filtrolistojn. Unu povas bindigi la specifan tunelan adreson, dum la alia heredas la ĵokeron, kaj la reta interfaco aspektas identa de ambaŭ flankoj.

Tial «la sama solvilo funkciis antaŭ la migrado» pruvas nenion pri la nuna bindado. Kontrolu la ingon, poste kontrolu la agordan dosieron, kiun la kuranta procezo efektive ŝargis. Malaktuala kopio en alia dosierujo estas ofta kialo, kial la redakto ŝajnas havi neniun efikon.

Fiksu ĝin, poste testu de la tunela flanko

Ŝanĝu bind_hosts al la tunela adreso, restartigu la servon kaj konfirmu, ke la ingo moviĝis: ss -lunp | grep :53 nun montru 10.6.0.1:53 kaj neniun ĵokeran eron. Se ĝi ankoraŭ montras 0.0.0.0, la kuranta procezo ne legas la dosieron, kiun vi redaktis.

Poste testu de la kliento, ĉar tio estas la sola flanko, kiu gravas. Demando per dig @10.6.0.1 example.com trairas la vojon, kiun trairas la uzanto, kaj kaptaĵo sur la gastiganto per tcpdump -ni wg0 udp port 53 montras la fontan adreson de la respondo sur la drato. Komparu ĝin kun la adreso en la solvila agordo de la kliento; kiam ili egalas, la tempolimo ĉesas esti mistero.

ip route get 10.6.0.2 klarigas ĉiun restantan strangecon, ĉar ĝi presas la interfacon kaj la fonton, kiujn la gastiganto uzus reen al la kliento. Se tiu eligo nomas la LAN-interfacon, la bind-ŝanĝo ne estas la tuta ripareo kaj la itinera tabelo estas la sekva legotaĵo.

Kion la bind-agordo ne povas ripari

Fiksi la aŭskultanton ne riparas alirliston, kiu preterlasas la tunelan subreton, fajroŝirmilan regulon, kiu permesas la demandon sed ne la respondon, aŭ mankantan itineron reen al la WireGuard-baseno. Tiuj malsukcesas pli frue aŭ pli malfrue ol la fonta adreso, kaj ĉiu havas alian posedanton.

Ĝi ankaŭ ne ŝanĝas al kiu upstream la solvilo plusendas, ĉu reprotektado de rebindado malakceptas privatan respondon por privata nomo, aŭ kiel la kliento aplikas siajn proprajn serĉajn domajnojn. Tiuj estas apartaj regiloj. Ŝanĝu la bind-adreson, kiam la responda fonto malĝustas, kaj ŝanĝu ion alian, kiam ĝi ne malĝustas.