AdGuard Home beantwoord WireGuard-kliente vanaf jou LAN-adres

Die tonnel is op, die firewall laat poort 53 toe, AdGuard Home loop, en name los steeds nie vir die WireGuard-kliënt nie. Die navraag kom normaalweg aan en 'n antwoord gaan normaalweg uit, so pakkettellers op die resolver lyk gesond en die diens lyk onskuldig. Wat verkeerd gaan, is die bronadres op daardie antwoord: dit gaan uit van 'n plaaslike adres wat die kliënt nooit gevra het nie, en die kliënt se stub-resolver gooi dit weg. Een lys in AdGuard Home se konfigurasie bepaal dit, en die gewone standaard gee die besluit aan die kern.

Die navraag kom aan, die antwoord vertrek van elders

‘n Kliënt wat gekonfigureer is met 10.6.0.1 as sy oplosser, stuur ‘n UDP-navraag na 10.6.0.1 poort 53. Daardie pakkie kruiseer die tonnel en beland op die gasheer, en AdGuard Home antwoord daarop. Op die draad, egter, is die reaksie ‘n nuwe pakkie waarvan die bronadres deur die gasheer se stapel gekies word, nie volgens die kliënt se verwagting nie.

Wanneer die kliënt se oplosser 'n gekoppelde been is, wat dit is wat systemd-resolved, dnsmasq en die meeste stub-oplossers gebruik, aanvaar dit slegs antwoorde van die presiese adres waarheen dit gestuur is. 'n Antwoord afkomstig van 192.168.1.10 na 'n navraag wat aan 10.6.0.1 gestuur is, word verwerp voordat enige ontleding plaasvind. Die oplosser log 'n suksesvolle antwoord, die kliënt log 'n tydsverloop, en albei vertel die waarheid.

Dus lieg die telers nie en die kliënt ook nie. Die bewys wat jy nodig het, is op drie plekke, in hierdie volgorde: die adres waaraan die luisteraar gebonde is, die roete wat die kern terug na die kliënt sou gebruik, en die bronadres op die werklike antwoordpakket.

Hoe die kern die antwoordbron kies

‘n UDP-sok wat gebind is aan0.0.0.0het geen eie bronadres nie, daarom veroorsaak elke uitgaande antwoord 'n roete-opsoek vir die bestemming. Die kern neem dan die bron vanaf daardie roete: die adres wat deur die roete vasgestel is, of die primêre adres van die uitgaande koppelvlak. Niks van die navraag se bestemmingsadres word onthou nie.

Op 'n enkel-gashere is dit onsigbaar, omdat daar net een geloofwaardige antwoord is. Op 'n masjien wat 'n LAN-adres, 'n WireGuard-adres en 'n bestuur-adres het, is verskeie antwoorde geloofwaardig, en die wenner hang af van die roeteringstabel op daardie oomblik. Voeg 'n ekstra roete by, 'n tweede adres op dieselfde koppelvlak, 'n NAT-omleiding voor die oplosser, of hardloop AdGuard in 'n houer met sy eie naamruimte, en die gekose bron kan verskil van die een wat die kliënt gevra het.

ss -lunp | grep :53wys in watter spel jy is. 'n luisteraar op0.0.0.0:53is die jokergeval; 'n luisteraar op10.6.0.1:53het die antwoord reeds vasgemaak. Om die sok aan te lees is vinniger as om die YAML te lees, en dit weerspieël wat eintlik aan die gang is eerder as wat laas gestoor is.

Wat bind_hosts eintlik beheer

AdGuard Home sedns.bind_hostsis die lys van plaaslike adresse wat die DNS-luisteraar gebruik. Die gestuurde standaard is die jokerteken, wat beteken dat dit op elke plaaslike adres aanvaar en die kern die bron per antwoord laat kies. Om die jokerteken met die adres te vervang wat kliënte navraag doen, verander die sok, en daarmee die bronadres op elke antwoord.

Die lys neem meer as een item aan, wat saak maak op 'n resolver wat twee netwerke bedien. Lys10.6.0.1en192.168.1.10gee twee gebonde sokkels, en 'n navraag wat op enigiemand van hulle aankom, word beantwoord vanaf die adres waarvandaan dit aangekom het. Dit is die gedrag wat die meeste mense aanneem dat die joker reeds bied.

Die YAML is eenvoudig, en die adres daarin is die een wat jou tonnelkliënte gesê is om te gebruik, nie die gasheer se primêre adres nie:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Waarom twee installasies van een oplosser nie saamstem nie

Plugin-beheerd, in hierdie konteks, beteken dat die resolver geïnstalleer is en deur 'n ander pakket toesig gehou word: 'n router-firmware-pakket, 'n NAS-pakket, of 'n huis-outomatisering-byvoeging. Daardie pakket stuur gewoonlik sy eie kopie van AdGuard Home se YAML en herbegin die proses op sy eie skedule, terwyl 'n selfstandige instansie die verkoper-binarie of houer is wat jy self opstel. In elk geval kyk jy na twee onafhanklike prosesse met afsonderlike konfigurasielêers en afsonderlike bind-keuses, selfs wanneer albei dieselfde opstroomlys en dieselfde filterlyste lees. Een kan die spesifieke tonneladres bind terwyl die ander die wildkaart erf, en die webkoppelvlak lyk identies vanaf beide kante.

Daar is hoekom "die selfde oplosser het voor die migrasie gewerk" niks bewys oor die huidige binding nie. Kontroleer die sok, en dan die konfigurasielêer wat die lopende proses regtig gelaai het. 'n Stowwerige kopie in 'n ander gids is 'n algemene rede waarom die wysiging geen effek het nie.

Pen dit vas, en toets dan van die tonnelkant af

Veranderbind_hostsna die tonneladres, herbegin die diens, en bevestig dat die sok geverskuif het:ss -lunp | grep :53moet nou wys10.6.0.1:53en geen joker-invoer nie. As dit steeds wys0.0.0.0,die lopende proses lees nie die lêer wat jy gewysig het nie.

Toets dan vanaf die kliënt, want dit is die enigste kant wat saak maak. 'n Navraag metdig @10.6.0.1 example.comoefen die pad wat die gebruiker oefen, en 'n vaslegging op die gasheer mettcpdump -ni wg0 udp port 53wys die antwoord se bronadres op die draad. Vergelyk dit met die adres in die kliënt se oplosinstelling; wanneer hulle gelyk is, hou die tydsverloop op om 'n raaisel te wees.

ip route get 10.6.0.2verklaar enige oorblywende vreemdheid, want dit druk die koppelvlak en bron wat die gasheer aan die kliënt sou gebruik, terug. As daardie uitvoer die LAN-koppelvlak benoem, is die bind-verandering nie die hele oplossing nie en die roeteringstabel is die volgende ding om te lees.

Wat die bind-instelling nie kan regmaak nie

Om die luisteraar te pen herstel nie 'n toeganglys wat die tonnel-subnet oorslaan nie, 'n firewall-reël wat die navraag toelaat maar nie die antwoord nie, of 'n ontbrekende roete terug na die WireGuard-pool nie. Daardie faal vroeër of later as die bronadres, en elkeen het 'n ander eienaar.

Dit verander ook nieaan watter opwaaier die oplosser stuur nie, of herbindingbeskerming 'n privaat antwoord vir 'n privaat naam verwerp, of hoe die kliënt sy eie soekdomeine toepas nie. Dit is aparte beheer. Verander die bind-adres wanneer die antwoordbron verkeerd is, en verander iets anders wanneer dit nie is nie.