AdGuard Home svarer WireGuard-klienter fra din LAN-adresse

Tunnelen er oppe, firewallen tillader port 53, AdGuard Home kører, og navne bliver stadig ikke opløst for WireGuard-klienten. Forespørgslen når normalt frem, og et svar sendes normalt tilbage, så pakketællere på resolveren ser sunde ud, og tjenesten fremstår uskyldig. Det, der går galt, er kildeadressen på det svar: det sendes fra en lokal adresse, som klienten aldrig har bedt om, og klientens stub resolver smider det væk. Én liste i AdGuard Homes konfiguration bestemmer dette, og dens sædvanlige standard giver beslutningen videre til kernen.

Forespørgslen når frem, svaret sendes fra et andet sted

En klient konfigureret med 10.6.0.1 som sin resolver sender en UDP-forespørgsel til 10.6.0.1 port 53. Den pakke krydser tunnelen og lander på værten, og AdGuard Home besvarer den. På ledningen er svaret dog en ny pakke, hvis kildeadresse vælges af værtens stack, ikke af klientens forventning.

Når klientens resolver er en tilsluttet socket, hvilket er hvad systemd-resolved, dnsmasq og de fleste stub-resolvers bruger, accepterer den kun svar fra den eksakte adresse, den sendte til. Et svar med kilde fra 192.168.1.10 til en forespørgsel sendt til 10.6.0.1 bliver droppet, før nogen parsing sker. Resolveren logger et vellykket svar, klienten logger en timeout, og begge fortæller sandheden.

Så tællerne lyver ikke, og det gør klienten heller ikke. De beviser, du har brug for, findes tre steder, i denne rækkefølge: den adresse, som lytteren er bundet til, den rute, som kernen ville bruge tilbage til klienten, og kildeadressen på den faktiske svarpakke.

Hvordan kernen vælger svar-kilde

En UDP-socket bundet til0.0.0.0har ingen egen kildeadresse, så hvert udgående svar udløser et ruteopslag for destinationen. Kernen tager derefter kilden fra den rute: adressen fastsat af ruten, eller den primære adresse på den udgående grænseflade. Intet om forespørgslens destinationsadresse gemmes.

På en enkeltstående vært er dette usynligt, fordi der kun er ét sandsynligt svar. På en maskine med en LAN-adresse, en WireGuard-adresse og en administrationsadresse er flere svar plausible, og vinderen afhænger af routingtabelen på det pågældende tidspunkt. Tilføj en ekstra rute, en anden adresse på samme interface, en NAT-omdirigering foran resolveren, eller kør AdGuard i en container med sit eget namespace, og den valgte kilde kan afvige fra den, klienten forespurgte.

ss -lunp | grep :53viser, hvilket spil du er i. En lytter på0.0.0.0:53er wildcard-tilfældet; en lytter på10.6.0.1:53har allerede fastlagt svaret. At læse socketten er hurtigere end at læse YAML, og det afspejler, hvad der faktisk kører, snarere end hvad der sidst blev gemt.

Hvad bind_hosts faktisk styrer

AdGuard Homesdns.bind_hostser listen over lokale adresser, som DNS-lytteren bruger. Standardindstillingen, der følger med, er jokertegnet, hvilket betyder, at den accepterer på alle lokale adresser og lader kernen vælge kilden pr. svar. Erstatning af jokertegnet med den adresse, som klienterne forespørger, ændrer soklen og dermed kildens adresse på hvert svar.

Listen kan indeholde mere end én indgang, hvilket er vigtigt på en resolver, der betjener to netværk. Ved at opstille10.6.0.1og192.168.1.10får man to bundne sokler, og en forespørgsel, der kommer på en af dem, besvares fra den adresse, den kom på. Det er den adfærd, som de fleste antager, jokertegnet allerede giver.

YAML'en er enkel, og adressen i den er den, som dine tunnelklienter blev bedt om at bruge, ikke værtens primære adresse:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Hvorfor to installationer af én resolver er uenige

Plugin-styret, i denne sammenhæng, betyder, at resolveren blev installeret og overvåges af en anden pakke: en router-firmwarepakke, en NAS-pakke eller et hjemmeautomations-tilføjelsesprogram. Den pakke leverer normalt sin egen kopi af AdGuard Homes YAML og genstarter processen efter sin egen tidsplan, mens en selvstændig instans er leverandørens binære fil eller container, som du selv konfigurerer. Uanset hvad ser du på to uafhængige processer med separate konfigurationsfiler og separate bindingvalgmuligheder, selv når begge læser den samme upstream-liste og de samme filterlister. Den ene kan binde den specifikke tunneladresse, mens den anden arver wildcard-adressen, og webgrænsefladen ser identisk ud fra begge sider.

Det er derfor, at "den samme resolver virkede før migreringen" ikke beviser noget om den nuværende binding. Tjek stikket, og tjek derefter konfigurationsfilen, som den kørende proces faktisk har indlæst. En forældet kopi i en anden mappe er en almindelig årsag til, at ændringen ser ud til at have ingen effekt.

Fastgør det, og test derefter fra tunnelen

Skiftbind_hoststil tunneladressen, genstart tjenesten, og bekræft, at stikket er flyttet:ss -lunp | grep :53burde nu vise10.6.0.1:53og ingen wildcard-post. Hvis det stadig viser0.0.0.0,læser den kørende proces ikke den fil, du redigerede.

Test derefter fra klienten, fordi det er den eneste side, der betyder noget. En forespørgsel meddig @10.6.0.1 example.comanvender den sti, som brugeren anvender, og en optagelse på værten medtcpdump -ni wg0 udp port 53viser svarrets kildeadresse på nettet. Sammenlign det med adressen i klientens resolverindstilling; når de er ens, ophører timeout med at være et mysterium.

ip route get 10.6.0.2forklarer enhver tilbageværende mærkelighed, fordi det udskriver den grænseflade og kilde, som værten ville bruge tilbage til klienten. Hvis den udskrift navngiver LAN-grænsefladen, er bind-ændringen ikke hele løsningen, og routningstabellen er det næste, man skal kigge på.

Hvad bind-indstillingen ikke kan rette

At fastlåse lytteren reparerer ikke en adgangsliste, der udelader tunnelnetværket, en firewallregel, der tillader forespørgslen men ikke svaret, eller en manglende rute tilbage til WireGuard-poolen. Disse fejler tidligere eller senere end kildeadressen, og hver har en anden ejer.

Det ændrer heller ikkehvilken upstream resolveren videresender til, om rebinding-beskyttelse afviser et privat svar for et privat navn, eller hvordan klienten anvender sine egne søgedomæner. Det er separate kontroller. Skift bind-adressen, når svar-kilden er forkert, og skift noget andet, når den ikke er.