AdGuard Home svarer WireGuard-klienter fra din LAN-adresse

Tunnelen er oppe, brannmuren tillater port 53, AdGuard Home kjører, og navn blir fortsatt ikke løst for WireGuard-klienten. Forespørselen kommer normalt frem og et svar går normalt tilbake, så pakketellere på resolveren ser sunne ut og tjenesten fremstår som uskyldig. Det som går galt, er kildadressen på det svaret: det sendes fra en lokal adresse som klienten aldri spurte om, og klientens stub resolver kaster det. Én liste i AdGuard Homes konfigurasjon avgjør dette, og standardinnstillingen overlater vanligvis avgjørelsen til kjernen.

Forespørselen kommer frem, svaret går tilbake fra et annet sted

En klient konfigurert med 10.6.0.1 som sin resolver sender en UDP-forespørsel til 10.6.0.1 port 53. Den pakken krysser tunnelen og lander på verten, og AdGuard Home svarer på den. På linjen, derimot, er svaret en ny pakke hvis kildeadresse velges av vertsstakken, ikke av klientens forventning.

Når klientens resolver er en tilkoblet socket, som er det systemd-resolved, dnsmasq og de fleste stub-resolvers bruker, godtar den bare svar fra den eksakte adressen den sendte til. Et svar med kilde fra 192.168.1.10 til en forespørsel sendt til 10.6.0.1 blir droppet før noen parsing skjer. Resolveren logger et vellykket svar, klienten logger en tidsavbrudd, og begge sier faktisk sannheten.

Så tellerne lyver ikke, og det gjør ikke klienten heller. Beviset du trenger er på tre steder, i denne rekkefølgen: adressen lytteren er bundet til, ruten kjernen ville bruke tilbake til klienten, og kildeadressen på det faktiske svarpaketet.

Hvordan kjernen velger svar-kilden

En UDP-socket bundet til0.0.0.0har ingen egen kildeadresse, så hvert utgående svar utløser et rutekall for destinasjonen. Kjernen tar deretter kilden fra den ruten: adressen som er festet av ruten, eller hovedadressen til det utgående grensesnittet. Ingenting om destinasjonsadressen i forespørselen blir husket.

På en enkeltstående vert er dette usynlig, fordi det bare finnes ett plausibelt svar. På en maskin som har en LAN-adresse, en WireGuard-adresse og en administrasjonsadresse, er flere svar plausible, og vinneren avhenger av rutingtabellen på det tidspunktet. Legg til en ekstra rute, en andre adresse på samme grensesnitt, en NAT-omdirigering foran resolveren, eller kjør AdGuard i en container med sitt eget navnerom, og den valgte kilden kan avvike fra den klienten spurte.

ss -lunp | grep :53viser hvilket spill du er i. En lytter på0.0.0.0:53er wildcard-tilfellet; en lytter på10.6.0.1:53har allerede fastlåst svaret. Å lese sokkelen er raskere enn å lese YAML, og det gjenspeiler hva som faktisk kjører, heller enn hva som sist ble lagret.

Hva bind_hosts faktisk kontrollerer

AdGuard Homesdns.bind_hostser listen over lokale adresser som DNS-lytteren bruker. Standardinnstillingen som følger med er jokertegn (*), som betyr aksepter på alle lokale adresser og la kjernen velge kilden per svar. Å erstatte jokertegnet med adressen klientene spør om endrer sokkelen, og med den kildens adresse på hvert svar.

Listen kan inneholde mer enn én oppføring, noe som er viktig for en løser som betjener to nettverk. Å liste10.6.0.1og192.168.1.10gir to bundne sokler, og en forespørsel som kommer til en av dem besvares fra adressen den kom inn på. Det er oppførselen de fleste antar at jokertegnet allerede gir.

YAML-en er enkel, og adressen i den er den tunneleringsklientene dine ble bedt om å bruke, ikke vertens primæradresse:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Hvorfor to installasjoner av en løser er uenige

Plugin-administrert, i denne sammenhengen, betyr at resolveren ble installert og overvåkes av en annen pakke: en ruter-firmwarepakke, en NAS-pakke eller et tillegg for hjemmeautomasjon. Den pakken leverer vanligvis sin egen kopi av AdGuard Homes YAML og starter prosessen på sitt eget skjema, mens en frittstående instans er leverandørens binærfil eller container som du konfigurerer selv. Uansett ser du på to uavhengige prosesser med separate konfigurasjonsfiler og separate bind-valg, selv når begge leser den samme oppstrømslisten og de samme filterlistene. Den ene kan binde den spesifikke tunneladressen mens den andre arver jokertegnet, og webgrensesnittet ser identisk ut fra begge sider.

Det er derfor "den samme resolveren fungerte før migreringen" ikke beviser noe om den nåværende bindingen. Sjekk socketen, og deretter konfigurasjonsfilen som den kjørende prosessen faktisk lastet. En foreldet kopi i en annen katalog er en vanlig grunn til at endringen ser ut til å ikke ha noen effekt.

Fest den, og test deretter fra tunnelsiden

Byttbind_hoststil tunneladressen, start tjenesten på nytt, og bekreft at socketen ble flyttet:ss -lunp | grep :53skal nå vise10.6.0.1:53og ingen jokertegnoppføring. Hvis den fortsatt viser0.0.0.0,leser ikke den kjørende prosessen filen du redigerte.

Test deretter fra klienten, fordi det er den eneste siden som betyr noe. En spørring meddig @10.6.0.1 example.comutprøver banen brukeren bruker, og en opptak på verten medtcpdump -ni wg0 udp port 53viser svaradressens kildeadresse på nettverket. Sammenlign den med adressen i klientens resolver-innstilling; når de er like, slutter timeout å være et mysterium.

ip route get 10.6.0.2forklarer enhver gjenværende uregelmessighet, fordi den skriver ut grensesnittet og kilden verten ville bruke tilbake til klienten. Hvis den utdataen navngir LAN-grensesnittet, er ikke bind-endringen hele løsningen, og rutetabellen er det neste som må leses.

Hva bind-innstillingen ikke kan fikse

Å feste lytteren reparerer ikke en tilgangsliste som utelater tunnel-subnettet, en brannmurregel som tillater forespørselen men ikke svaret, eller en manglende rute tilbake til WireGuard-poolen. Disse feiler tidligere eller senere enn kildeadressen, og hver har en annen eier.

Den endrer heller ikkehvilken upstream resolveren videresender til, enten om beskyttelse mot re-binding avviser et privat svar for et privat navn, eller hvordan klienten bruker sine egne søkedomener. Dette er separate kontroller. Endre bind-adressen når svar-kilden er feil, og endre noe annet når den ikke er det.