AdGuard Home atsako WireGuard klientams iš jūsų LAN adreso

Tunneletas veikia, ugniasienė leidžia 53 prievadą, AdGuard Home veikia, tačiau vardai vis tiek neišsprendžiami WireGuard klientui. Užklausą paprastai gauna ir atsakymą paprastai siunčia, todėl paketo skaitikliai resolveryje atrodo normaliai, o paslauga atrodo nekalta. Kas vyksta negerai, tai atsakymo šaltinio adresas: jis palieka vietinį adresą, kurio klientas niekada neprašė, ir kliento stub resolveris jį atmeta. Vienas sąrašas AdGuard Home konfigūracijoje tai sprendžia, o numatytoji dažna nuostata perleidžia sprendimą branduoliui.

Užklausa atvyksta, atsakymas išeina iš kitos vietos

Klientas, sukonfigūruotas naudoti 10.6.0.1 kaip savo rezolverį, siunčia UDP užklausą į 10.6.0.1 prievadą 53. Šis paketas pereina per tunelį ir pasiekia kompiuterį, ir AdGuard Home į jį atsako. Tačiau tinkle atsakymas yra naujas paketas, kurio šaltinio adresą pasirenka kompiuterio tinklo sluoksnis, o ne kliento lūkestis.

Kai kliento rezolveris yra sujungtas lizdas, kaip tai daro systemd-resolved, dnsmasq ir dauguma stub rezolerių, jis priima tik atsakymus iš to paties adreso, į kurį buvo išsiųsta užklausa. Atsakymas, atsiųstas iš 192.168.1.10 į užklausą, išsiųstą į 10.6.0.1, yra atmestas dar neprasidėjus analizavimui. Rezolveris įrašo sėkmingą atsakymą, klientas įrašo laiką pasibaigusį laukimo terminą, ir abu yra teisingi.

Taigi skaitikliai nemeluoja, ir klientas nemeluoja. Reikalingi įrodymai yra trijose vietose, šiuo tvarka: adrese, prie kurio prisegtas klausytojas, maršrute, kurį branduolys naudotų grįžimui pas klientą, ir šaltinio adrese tikrame atsakymo pakete.

Kaip branduolys pasirenka atsakymo šaltinį

UDP lizdas, pririštas prie0.0.0.0neturi savo šaltinio adreso, todėl kiekvienas išeinantis atsakymas sukelia tiekimą maršruto paieškai iki paskirties vietos. Tada branduolys paima šaltinį iš to maršruto: adresą, pririštą prie maršruto, arba pagrindinį išeinančio tinklo sąsajos adresą. Niekas apie užklausos paskirties adresą nėra įsimenama.

Viename kompiuteryje, turinčiame tik vieną tinklo sąsają, tai yra nematoma, nes egzistuoja tik vienas įmanomas atsakymas. Mašinoje, turinčioje LAN adresą, WireGuard adresą ir valdymo adresą, keli atsakymai yra įmanomi, o laimėtojas priklauso nuo tuo metu esančios maršrutizavimo lentelės. Pridėkite papildomą maršrutą, antrą adresą toje pačioje sąsajoje, NAT peradresavimą prieš resolverį arba paleiskite AdGuard konteineryje su savo vardų erdve, ir pasirinktas šaltinis gali skirtis nuo to, kurį užklausė klientas.

ss -lunp | grep :53rodo, kuriais žaidėjais esate. Klausytojas ant0.0.0.0:53yra universali situacija; klausytojas ant10.6.0.1:53jau nustatė atsakymą. Socket skaitymas yra greitesnis nei YAML skaitymas ir atspindi tai, kas iš tikrųjų veikia, o ne tai, kas buvo paskutinį kartą išsaugota.

Ką iš tikrųjų valdo bind_hosts

AdGuard Home'sdns.bind_hostsyra vietinių adresų sąrašas, kurį naudoja DNS klausytojas. Numatytoji versija, pateikta su programa, yra universalus žymeklis, reiškiantis, kad priimama kiekviename vietiniame adrese ir leidžiama branduoliui pasirinkti siuntėjo adresą pagal atsakymą. Pakeitus universalų žymeklį į adresą, kurį užklausinėjo klientai, keičiasi lizdas ir kartu su juo kiekvieno atsakymo siuntėjo adresas.

Sąrašas gali turėti daugiau nei vieną įrašą, o tai svarbu, kai sprendėjas aptarnauja dvi tinklo grupes. Išvardijus10.6.0.1ir192.168.1.10gaunamos dvi pririštos lizdų, ir užklausa, atėjusi į bet kurį iš jų, gauna atsakymą iš adreso, į kurį ji atėjo. Tai yra elgsena, kurią dauguma žmonių mano, kad universalus žymeklis jau teikia.

YAML yra paprastas, o adresas jame yra tas, kurį jūsų tunelio klientai buvo nurodyti naudoti, o ne pirminis kompiuterio adresas:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Kodėl du to paties sprendėjo diegimai nesutaria

Šiuo kontekstu „valdomas per papildinį“ reiškia, kad rezoliucija buvo įdiegta ir prižiūrima kito paketo: maršrutizatoriaus programinės įrangos paketo, NAS paketo arba namų automatizavimo papildinio. Tas paketas dažniausiai pateikia savo AdGuard Home YAML kopiją ir automatiškai paleidžia procesą pagal savo tvarkaraštį, tuo tarpu atskira instancija yra tiekėjo binarinė programa arba konteineris, kurį konfigūruojate patys. Bet kuriuo atveju žiūrite į du nepriklausomus procesus su atskiromis konfigūracijos bylomis ir atskiromis susiejimo parinktimis, net jei abu skaito tą patį aukštesnio lygio sąrašą ir tas pačias filtro sąrašus. Vienas gali susieti konkretaus tunelio adresą, o kitas paveldi universaliąją žvaigždutę, ir žiniatinklio sąsaja atrodo identiškai iš bet kurios pusės.

Todėl „tas pats rezoliucijos procesorius veikė prieš migraciją“ nieko neįrodo apie dabartinį susiejimą. Patikrinkite lizdą, tada patikrinkite konfigūracijos bylą, kurią iš tikrųjų įkėlė veikiantis procesas. Senstelėjusi kopija kitoje direktorijoje yra dažna priežastis, kodėl redagavimas neatrodo turintis poveikio.

Pririškite ją, tada išbandykite tunelio pusėje

Pakeiskitebind_hostsį tunelio adresą, paleiskite paslaugą iš naujo ir patikrinkite, ar lizdas persikėlė:ss -lunp | grep :53dabar turėtų parodyti10.6.0.1:53ir be bendro ženklo įrašo. Jei vis dar rodo0.0.0.0,veikiantis procesas neskaito bylos, kurią redagavote.

Tada išbandykite iš kliento pusės, nes tai yra vienintelė svarbi pusė. Užklausa sudig @10.6.0.1 example.comišbando kelio, kurį naudoja vartotojas, ir paketų fiksavimas šeimininko kompiuteryje sutcpdump -ni wg0 udp port 53parodo atsakymo šaltinio adresą tinkle. Palyginkite jį su adresu kliento rezolverio nustatyme; kai jie sutampa, laiko limitas nebebus paslaptis.

ip route get 10.6.0.2paaiškina likusią keistenybę, nes jis spausdina sąsają ir šaltinį, kurį serveris naudotų siųsdamas atgal klientui. Jei tas išvesties rezultatas nurodo LAN sąsają, bind pakeitimas nėra viso pataisymo dalis, ir kitą dalyką reikia patikrinti yra maršrutų lentelė.

Ką bind nustatymas negali pataisyti

Pririšus klausytoją nepataisoma prieigos sąrašas, kuris praleidžia tunelio potinklį, ugniasienės taisyklė, leidžianti užklausą, bet ne atsakymą, arba trūkstamas maršrutas atgal į WireGuard baseiną. Šios problemos pasireiškia anksčiau arba vėliau nei šaltinio adresas, ir kiekviena turi skirtingą savininką.

Tai taip pat nekeičiaį kurį aukštesnįjį serverį rezolveris persiunčia, ar perkrovimo apsauga atmeta privačią atsakymą į privatų vardą, ar kaip klientas taiko savo paieškos sritis. Tai yra atskira kontrolė. Pakeiskite sujungimo adresą, kai atsakymo šaltinis yra neteisingas, ir pakeiskite ką nors kitą, kai jis neteisingas.