AdGuard Home svarar WireGuard-klientar frå LAN-adressa di

Tunnelen er oppe, brannmuren tillèt port 53, AdGuard Home køyrer, og namna blir framleis ikkje løyste for WireGuard-klienten. Spørjinga kjem normalt fram og eit svar går normalt ut, så pakketeljarane på resolvaren ser friske ut og tenesta verkar uskuldig. Det som går gale, er kjeldeadressa i det svaret: det går ut frå ei lokal adresse som klienten aldri bad om, og stub-resolvaren til klienten kastar det bort. Éi liste i konfigurasjonen til AdGuard Home avgjer dette, og det vanlege standardvalet overlèt avgjerda til kjernen.

Spørjinga kjem fram, svaret går ut frå ein annan stad

Ein klient som har 10.6.0.1 som resolvar, sender ei UDP-spørjing til 10.6.0.1 port 53. Den pakken går gjennom tunnelen og landar på verten, og AdGuard Home svarar på han. På linja er svaret likevel ein ny pakke der kjeldeadressa blir vald av stakken på verten, ikkje av det klienten venta.

Når resolvaren til klienten er ein tilkopla sokkel, som er det systemd-resolved, dnsmasq og dei fleste stub-resolvarar brukar, godtek han berre svar frå den nøyaktige adressa han sende til. Eit svar med kjelde 192.168.1.10 på ei spørjing send til 10.6.0.1 blir sleppt før noko tolking skjer. Resolvaren loggar eit vellukka svar, klienten loggar tidsavbrot, og begge fortel sanninga.

Så teljarane lyg ikkje, og ikkje klienten heller. Beviset du treng, ligg tre stader, i denne rekkjefølgja: adressa lyttaren er bunden til, ruta kjernen ville bruke tilbake til klienten, og kjeldeadressa på den faktiske svarpakken.

Korleis kjernen vel kjelda for svaret

Ein UDP-sokkel bunden til 0.0.0.0 har inga kjeldeadresse sjølv, så kvart utgåande svar utløyser eit ruteoppslag for mottakaren. Kjernen tek så kjelda frå den ruta: adressa som er fest i ruta, eller primæradressa til det utgåande grensesnittet. Ingenting om mottakaradressa i spørjinga blir hugsa.

På ein vert med eitt grensesnitt er dette usynleg, fordi det berre finst eitt truverdig svar. På ein maskin med ei LAN-adresse, ei WireGuard-adresse og ei administrasjonsadresse er fleire svar truverdige, og vinnaren avheng av rutetabellen i det augeblikket. Legg til ei ekstra rute, ei andre adresse på same grensesnitt, ei NAT-omdirigering framfor resolvaren, eller køyr AdGuard i ein container med sitt eige namnerom, og den valde kjelda kan bli ei anna enn den klienten spurde.

ss -lunp | grep :53 syner kva spel du er i. Ein lyttar på 0.0.0.0:53 er jokerteikn-tilfellet; ein lyttar på 10.6.0.1:53 har alt fest svaret. Å lese sokkelen går raskare enn å lese YAML, og det speglar det som faktisk køyrer, ikkje det som vart lagra sist.

Kva bind_hosts faktisk styrer

dns.bind_hosts i AdGuard Home er lista over lokale adresser DNS-lyttaren brukar. Standardverdien som følgjer med, er jokerteiknet, som tyder å ta imot på kvar lokal adresse og la kjernen velje kjelda for kvart svar. Å byte jokerteiknet ut med adressa klientane spør, endrar sokkelen, og med han kjeldeadressa på kvart svar.

Lista tek meir enn éin oppføring, noko som tel på ein resolvar som tenar to nett. Å liste 10.6.0.1 og 192.168.1.10 gjev to bundne sokklar, og ei spørjing som kjem inn på kven som helst av dei, blir svara frå adressa ho kom inn på. Det er åtferda folk flest trur jokerteiknet alt gjev.

YAML-en er enkel, og adressa i han er den tunnelklientane dine fekk beskjed om å bruke, ikkje primæradressa til verten:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Kvifor to installasjonar av same resolvar er usamde

Pluginstyrt tyder i denne samanhengen at resolvaren vart installert og blir overvaka av ein annan pakke: ein rutar-fastvarepakke, ein NAS-pakke eller eit tillegg for heimautomatisering. Den pakken leverer vanlegvis sin eigen kopi av YAML-en til AdGuard Home og startar prosessen på nytt etter sitt eige skjema, medan ein frittståande instans er leverandørbinæret eller containeren du konfigurerer sjølv. Same kva, du ser på to uavhengige prosessar med kvar sine konfigurasjonsfiler og kvar sine bind-val, jamvel når begge les same oppstraumsliste og same filterlister. Éin kan binde den spesifikke tunneladressa medan den andre arvar jokerteiknet, og webgrensesnittet ser identisk ut frå begge sider.

Det er derfor «same resolvaren fungerte før migreringa» ikkje bevisar noko om den noverande bindinga. Sjekk sokkelen, og sjekk så konfigurasjonsfila som den køyrande prosessen faktisk lasta. Ein utdatert kopi i ei anna mappe er ein vanleg grunn til at endringa ser ut til å ikkje ha nokon verknad.

Fest han, og test så frå tunnelsida

Endre bind_hosts til tunneladressa, start tenesta på nytt og stadfest at sokkelen flytta seg: ss -lunp | grep :53 skal no syne 10.6.0.1:53 og inga jokerteikn-oppføring. Viss han framleis syner 0.0.0.0, les den køyrande prosessen ikkje fila du endra.

Test så frå klienten, fordi det er den einaste sida som tel. Ei spørjing med dig @10.6.0.1 example.com prøver den vegen brukaren prøver, og ein fangst på verten med tcpdump -ni wg0 udp port 53 syner kjeldeadressa til svaret på linja. Samanlikn ho med adressa i resolvarinnstillinga til klienten; når dei er like, er ikkje tidsavbrotet lenger noko mysterium.

ip route get 10.6.0.2 forklarar kvar gjenverande raritet, fordi han skriv ut grensesnittet og kjelda verten ville bruke tilbake til klienten. Viss utdata nemner LAN-grensesnittet, er ikkje bind-endringa heile rettinga, og rutetabellen er det neste du bør lese.

Kva bind-innstillinga ikkje kan rette

Å feste lyttaren reparerer ikkje ei tilgangsliste som utelèt tunnel-subnettet, ei brannmurregel som tillèt spørjinga men ikkje svaret, eller ei manglande rute tilbake til WireGuard-poolen. Dei feilar før eller etter kjeldeadressa, og kvar av dei har ein annan eigar.

Det endrar heller ikkje kva oppstraum resolvaren videresender til, om rebinding-vern avviser eit privat svar for eit privat namn, eller korleis klienten brukar sine eigne søkjedomene. Det er separate kontrollar. Endre bind-adressa når kjelda til svaret er feil, og endre noko anna når ho ikkje er det.