AdGuard Thús beantwurdet WireGuard-klienten fan jo LAN-adres

De tunnel is heech, de firewall tastiet poarte 53, AdGuard Home draait, en nammen wurde noch net oplost foar de WireGuard klient. De fraach komt normaal oan en in antwurd giet normaal wei, dus pakket-tellers op de oplosser sjogge sûn út en de tsjinst liket skuldleas. Wat mis giet is it boarne-adres op dat antwurd: it giet wei fan in lokaal adres dat de klient nea frege hat, en de stub-oplosser fan de klient smyt it fuort. In list yn de konfiguraasje fan AdGuard Home beslút dit, en syn gewoane standert jout de beslissing oan de kernel.

De fraach komt oan, it antwurd giet wei fan in oare lokaasje

In klant dy't ynsteld is mei 10.6.0.1 as syn resolver stjoert in UDP-fraach oan 10.6.0.1 poarte 53. Dat pakket krúst de tunnle en komt oan op de host, en AdGuard Home beantwurdet it. Op de line, lykwols, is it antwurd in nij pakket dêr't it boarne-adres keazen wurdt troch de stack fan de host, net troch de ferwachting fan de klant.

As de resolver fan de klant in ferbûn socket is, wat systeemd-resolve, dnsmasq en de measte stub-resolvers brûke, akseptearret it allinnich antwurden fan it krekte adres wêrnei't it stjoerde. In antwurd dat fan 192.168.1.10 komt op in fraach stjoerd nei 10.6.0.1 wurdt ferwiderje foardat der parsearring plakfynt. De resolver logt in suksesfol antwurd, de klant logt in timeout, en beiden fertelle de wierheid.

Sadwaande ljie de counters net en ek de klant net. De bewiis dy't jo nedich binne is op trije plakken, yn dizze folchoarder: it adres dêr't de harker oan bûn is, de rûte dy't de kernel werom nei de klant brûke soe, en it boarne-adres op it echte antwurdpakket.

Hoe't de kernel de antwurdboarne kiest

In UDP-sokke bûn oan0.0.0.0hat gjin boarneadres fan syn eigen, dus elk útgeand reaksje jout in rûte-ynsicht foar it bestimmingsadres. De kernel nimt dan it boarneadres út dy rûte: it adres fêstset troch de rûte, of it haadadres fan de útgeande ynterface. Niks oer it bestimmingsadres fan de query wurdt ûnthâlden.

Op in host mei ien thúsadres is dit ûnsichtber, om't der mar ien plauzibele antwurd is. Op in masine mei in LAN-adres, in WireGuard-adres en in behearadres, binne ferskate antwurden plauzibel, en de winner hinget ôf fan de routingtabel op dat stuit. Foegje in ekstra rûte ta, in twadde adres op itselde ynterface, in NAT-omlieding foar de resolver, of rint AdGuard yn in container mei eigen namespace, en de keazen boarne kin ferskille fan dy't de kliïnt freegde.

ss -lunp | grep :53toant hokker spultsje jo spylje. In listener op0.0.0.0:53is it wildcard-gefal; in listener op10.6.0.1:53hat it antwurd al fêststeld. It lêzen fan de socket is flugger as it lêzen fan de YAML, en it reflektearret wat echt draait yn stee fan wat lêst opslein waard.

Wat bind_hosts eins kontrolearret

AdGuard Home'sdns.bind_hostsis de list fan lokale adressen dy't de DNS-luisteraar brûkt. It standert dy't meikommen is, is de wildcard, wat betsjut akseptearje op elk lokaal adres en de kernel lit de boarne per antwurd kieze. It ferfangen fan de wildcard mei it adres dêr't kliïnten op freegje feroaret de sok, en mei it ek it boarneadres op elk antwurd.

De list kin mear as ien ynfiering hawwe, wat wichtich is foar in resolver dy't twa netwurken tsjinnet. It neamen fan10.6.0.1en192.168.1.10jout twa bound sockets, en in freegje dy't oankomt op ien fan beide wurdt beantwurde fan it adres wêrop it oankommen is. Dat is it gedrach dat measten minsken oannimme dat de wildcard al leveret.

De YAML is gewoan, en it adres dêryn is dejinge dy't jo tunnelkliïnten sein waarden te brûken, net it primêre adres fan de host:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Wêrom twa ynstallaasjes fan ien resolver it net iens binne

Plugin-beheard, yn dizze kontekst, betsjut dat de resolver ynstalleare waard en wurdt tafersjoen troch in oar pakket: in router-firmwarepakket, in NAS-pakket, of in thús-automatisaasje-add-on. Dat pakket levert meast syn eigen kopy fan AdGuard Home syn YAML en herstart it proses op syn eigen skema, wylst in selsstannich ynstânsje de leveransier-binary of container is dy't jo sels konfigurearje. Hoe dan ek sjochst nei twa ûnôfhinklike prosessen mei aparte konfiguraasjebestannen en aparte bind opsjes, sels as beide deselde upstream-list en deselde filterlist lêze. Ien kin it spesifike tunnel-adres binde wylst de oare it wildcard oernimt, en de webynterface liket identyk fan beide kanten.

Dêrom befet de útdrukking "deselde resolver hie al wurke foar de migraasje" neat oer de hjoeddeistige bining. Kontrolearje de socket, dan kontrolearje it konfiguraasjefiel dat it rinnende proses yn echt laden hat. In âlde kopy yn in oare map is in mienskiplike reden wêrom't de wiziging liket gjin effekt te hawwen.

Pin it, dan test fan 'e túnnelkant

Changebind_hostsnei it tunneladres, start de tsjinst opnij, en befestig dat de socket ferhûze isss -lunp | grep :53should now show10.6.0.1:53en gjin wildcard-ynfier. As it noch altyd werjûn wurdt0.0.0.0,it rinnende proses lêst it bestân net dat jo bewurke hawwe.

Dan test fan de kliïnt, om't dat de iennichste kant is dy't der ta docht. In oanfraach meidig @10.6.0.1 example.comoefenet it paad dat de brûker oefenet, en in opfang op de host meitcpdump -ni wg0 udp port 53toant it antwurd syn boarne-adres op de line. Fergelykje it mei it adres yn 'e resolverynstelling fan' e kliïnt; as se lyk binne, stopt de timeout mei in mystearje te wêzen.

ip route get 10.6.0.2ferklearret elke oerbleaune ûnrêst, om't it de ynterface en boarne drukke dy't de host werom nei de kliïnt brûke soe. As dy útfiersnamme de LAN-ynterface neamt, is de bind-wijziging net de folsleine oplossing en de rútetabel is it folgjende ding om te lêzen.

Wat de bindynstelling net reparearje kin

It penne fan de listener reparearret gjin tagongslist dy't it tunnel-subnet easket, in firewallregel dy't de query tastiet mar net it antwurd, of in miste rûte werom nei it WireGuard-pool. Dy mislearje earder of letter as it boarne-adres, en elk hat in oar eigenhawwer.

It feroaret ek nethokker upstream de resolver trochstjoert, oft it werbûn beskerming in privee antwurd foar in privee namme ôfwiist, of hoe de kliïnt syn eigen sykgebieten tapast. Dat binne aparte kontrôles. Feroarje it bûn-adres as de antwurdboarne ferkeard is, en feroarje wat oars as dat net sa is.