AdGuard Home svarar WireGuard viðskiptavinum frá LAN-tölu þinni

Tunnellinn er virkur, eldveggurinn leyfir port 53, AdGuard Home er í gangi, en nöfn leysast enn ekki fyrir WireGuard viðskiptavininn. Fyrirspurnin kemur venjulega, og svar fer venjulega, svo talning pakka á lausnarkerfinu lítur heilbrigt út og þjónustan sýnist saklaus. Það sem fer úrskeiðis er heimilisfang upphafsins á því svari: það fer frá staðsettu heimilisfangi sem viðskiptavinurinn bað aldrei um, og stub-lausnarkerfi viðskiptavinarins hendir því. Ein listi í stillingum AdGuard Home ræður þessu, og venjulegur sjálfgefinn möguleiki felur ákvörðunina til kjarnans.

Fyrirspurnin kemur, svarið fer frá einhverjum öðrum stað

Viðskiptavinur sem er stilltur með 10.6.0.1 sem uppleysanda sendir UDP-fyrirspurn til 10.6.0.1 á porti 53. Sá pakkki fer í gegn um göngin og lenda á vélinni, og AdGuard Home svarar honum. Á leiðinni í gegnum netið er svarið þó nýr pakkki þar sem upphafsheimilisfang er valið af netstakk vélarinnar, ekki af væntingu viðskiptavinarins.

Þegar uppleysandi viðskiptavinarins er tengdur sokkur, sem er það sem systemd-resolved, dnsmasq og flest stub-upplýsingaforrit nota, samþykkir hann aðeins svör frá nákvæmlega þeim heimilisfangi sem það sendi á. Svar sem kemur frá 192.168.1.10 í viðbragð við fyrirspurn sem var send til 10.6.0.1 er hent áður en nokkur greining fer fram. Uppleysandinn skráir vel heppnað svar, viðskiptavinurinn skráir tímamörk, og bæði segja sannleikann.

Svo teljararnir ljúga ekki og hvorki viðskiptavinurinn. Sönnunin sem þú þarft er á þremur stöðum, í þessari röð: í síðunnarfangi sem hlustandinn er bundinn við, í leiðinni sem kjarninn myndi nota til að snúa aftur til viðskiptavinarins, og í upphafsfanginu á raunverulega svarsins pakka.

Hvernig kjarninn velur svarsfang

UDP-sokkur bundinn við0.0.0.0hefur ekkert eigið upphafsfang, svo hver útfarandi svarkall kallar á leiðsni fyrir áfangastaðinn. Kjarninn tekur síðan upphafið úr þeirri leið: það netfang sem leiðin festir eða aðalnetfang útfarandi tengi. Ekkert um áfangastaðspóstfang fyrirspurnarinnar er munað.

Á einhliða hýsli er þetta ósýnilegt, því aðeins eitt svar virðist sjálfsagt. Á vél sem hefur LAN-tölu, WireGuard-tölu og stjórnendatölu eru nokkur svör hugsanleg og valið fer eftir leiðartöflu á þeim tíma. Bættu við viðbótarleið, annarri tölu á sama tengi, NAT-endurvísa fyrir framan leitarþjóninn, eða keyrðu AdGuard í gámi með eigin nafnrými, og valið upphaf getur verið öðruvísi en það sem viðskiptavinurinn spurði um.

ss -lunp | grep :53sýnir í hvaða leik þú ert. Hlusta á0.0.0.0:53er algilt tilfelli; hlusta á10.6.0.1:53hefur þegar þrengt svarið. Að lesa sokkinn er hraðara en að lesa YAML, og það endurspeglar hvað er raunverulega í gangi frekar en hvað var síðast vistað.

Hvað bind_hosts í raun stjórnar

AdGuard Home'sdns.bind_hostser listi yfir staðbundnar heimilisföng sem DNS hlustandinn notar. Sjálfgefið sem fylgir er stjörnumerki, sem þýðir að samþykkja á hverju staðbundnu heimilisfangi og láta kjarna stýra upprunalegu heimilisfangi fyrir hvert svar. Þegar stjörnumerki er skipt út fyrir heimilisfang sem viðskiptavinir spyrja um breytist sokkurinn, og með honum upprunalega heimilisfangið á hverju svari.

Listinn tekur fleiri en eitt atriði, sem skiptir máli fyrir lausnara sem þjónar tveimur netum. Að skrá10.6.0.1og192.168.1.10gefur tvo bundna sokka, og fyrirspurn sem kemur á hvorn sem er verður svarað frá heimilisfanginu sem hún kom á. Þetta er hegðun sem flestir halda að stjörnumerkið sjái nú þegar fyrir.

YAML er einfalt, og heimilisfangið í því er það sem tunluviðskiptavinir þínir voru sagt að nota, ekki aðalheimilisfang hýsingarvélarinnar:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Af hverju tvær uppsetningar af einni lausnara eru ósammála

Í þessu samhengi þýðir „viðbótarstýrt“ að lausnaraðilinn var settur upp og er stjórnað af öðrum pakka: pakkaforrit fyrir leið, NAS pakka, eða viðbótarforrit fyrir heimilisstýringar. Sá pakki sendir yfirleitt með sér eigið eintak af YAML skjali AdGuard Home og endurræsir ferlið samkvæmt eigin áætlun, á meðan sjálfstætt eintak er tilvikið sem þú stillir sjálfur, hvort sem það er hrindbúnaðar-binary eða gáma. Hvor leið sem er ertu að horfa á tvær sjálfstæðar ferlar með aðskildar stillingarskrár og aðskildar bind-samsetningar, jafnvel þótt báðir lesi sama upprunalega lista og sömu síu-lista. Annað getur bundið tiltekinn göngugáttarleið (tunnel address) á meðan hitt erfir staðlaða villumerkjagáttina, og vefviðmótið lítur nákvæmlega eins út hvort heldur sem er.

Þess vegna sannað ekkert um núverandi bindingu að „sami lausnaraðilinn virkaði áður en flutningurinn var gerður“. Athugaðu sokkann, skoðaðu síðan stillingarskrána sem keyrandi ferlið hlaðaði raunverulega. Gamaldags afrit í öðru skráarsafni er algeng ástæða þess að breytingin virðist engan áhrif hafa.

Festu það, prófaðu síðan frá göngunum

Breyttubind_hostsí göngutengslanetfangið, ræstu þjónustuna aftur og staðfestu að sokkinn hafi fært sig:ss -lunp | grep :53ætti nú að sýna10.6.0.1:53og engin almenn skrá. Ef það sýnir enn0.0.0.0,er keyrandi ferlið ekki að lesa skrána sem þú breyttir.

Prófaðu síðan frá viðskiptavininum, vegna þess að það er eina hliðin sem skiptir máli. Fyrirspurn meðdig @10.6.0.1 example.comfer eftir þeirri leið sem notandinn fer, og sýni á gestgjafanum meðtcpdump -ni wg0 udp port 53sýnir heimilisfang svarsins á netvírunni. Berðu það saman við heimilisfangið í stillingu lausnarvélar viðskiptavinarins; þegar þau eru jöfn hættir tímamörkunin að vera dularfull.

ip route get 10.6.0.2skýrir allar eftirfylgjandi skrýtnar aðstæður, því hún prentar upp tengi og heimilisfang sem hýsingarvélin myndi nota til baka til viðskiptavinarins. Ef sú úttak nefnir LAN-tengi, er breyting á bind ekki allt sem þarf og leiðsögutaflan er næsta skref sem þarf að lesa.

Hvað bind-stillingin getur ekki lagað

Festing hlustanda lagar ekki aðgangslista sem sleppir tunlu-undirneti, eldveggareglu sem leyfir fyrirspurnina en ekki svarið, eða vantar leið til baka í WireGuard-poolinn. Þessar mistök koma á undan eða á eftir heimilisfanginu, og hver hefur mismunandi aðila.

Það breytir heldur ekkihvaða uppstreymislausn lausnari vísar á, hvort vernd gegn endurtengingu hafnar einkasvörum fyrir einkanafn, eða hvernig viðskiptavinurinn notar eigin leitarsvæði. Þetta eru aðskildir stjórnarþættir. Breyttu bindumslóðinni þegar svarheimildin er röng, og breyttu einhverju öðru þegar hún er ekki það.