Beindu OpenVPN-biðlurum að Pi-hole-uppflettara á öðrum vélum

Að setja Pi-hole-vistfang í OpenVPN-sniðmát býr ekki til leið að því, veitir ekki heimild til að spyrja þess og tryggir ekki að biðlarinn noti það. Þegar Pi-hole er á sérstakri LAN-vél verða fjórir hlutir að stemma: leiðin frá biðlaranum, framsendingin frá gáttinni, endurkomuleiðin að safninu og móttökustefnan á Pi-hole sjálfu. Hver bilun lítur öðruvísi út í annál. Að fara í gegnum þær í þeirri röð er fljótlegra en að laga þá síðustu fyrst. Venjulega flýtileiðin, að opna endurkvæma uppflettingu fyrir hverja uppsprettu, skiptir litlu vandamáli fyrir varanlegu.

Hvað ýtti DNS-valkosturinn gerir og gerir ekki

Netþjónninn auglýsir uppflettara með tilskipuninni hér að neðan, að því gefnu að 192.168.50.53 sé Pi-hole-vélin. Biðlarinn tekur við valkostinum og, eftir kerfinu og samþættingu uppflettarans , beitir honum á göngutengið eða hunsar hann í þágu staðbundins stubs. Leiðarlínan skiptir jafn miklu máli og DNS-línan, því uppflettari sem biðlarinn nær ekki til er enginn uppflettari. Ekkert af þessu er sýnilegt frá netþjónshliðinni.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

Að taka við valkosti er ekki það sama og að nota hann. Linux-biðlari með uppflettarastjóra gæti samþykkt ýtta netþjóninn og sent honum aðeins ákveðin lén; biðlari sem stýrir DNS sjálfur gæti skrifað yfir stillinguna algjörlega. Ýttar leiðir eru líka takmarkaðar á sumum kerfum, sem lætur uppflettarann óaðgengilegan þótt valkosturinn hafi verið samþykktur. Athugaðu á biðlaranum hvaða netþjónn svarar, ekki á netþjónnum hvað var sent.

Valkosturinn segir líka ekkert um netþjónshliðina. DNS-umferð verður samt að ferðast frá biðlaranum að gáttinni og frá gáttinni að Pi-hole áður en nokkur valkostur skiptir máli. Vantaða leið og hafnaðri fyrirspurn lítur eins út frá biðlaranum, svo staðfestu fyrst framsendinguna á gáttinni.

Endurkomuleiðin frá Pi-hole að safninu

Ef upprunavistfang biðlarans er varðveitt svarar Pi-hole á vistfang inni í VPN-safninu. Eigin leiðatöflu þess er líklega ekkert kunnugt um það safn, svo svarið fer á sjálfgefna gátt þess og hverfur. Fyrirspurnarannállinn sýnir beiðni án samsvarandi svars, sem er auðvelt að misskilja sem eldveggsvandamál.

Gefðu LAN-beininum kyrra leið fyrir safnið með OpenVPN-gáttinni sem næsta stökki, eða þýddu uppsprettuna á gáttinni áður en framsent er til Pi-hole. Sú fyrri heldur vistföngum hvers biðlara sýnilegum í fyrirspurnarannálinu Pi-hole. Sú síðari fjarlægir kröfuna um endurkomuleið en lætur hverja fyrirspurn líta út eins og hún komi frá gáttinni. Hvorug er röng; þær svara mismunandi spurningum.

Ef skýrslugerð eða stefna fyrir hvern biðlara skiptir máli er kyrra leiðin betri skiptin. Ef LAN er stýrt af öðrum og leið er ekki tiltæk er þýðing hagnýtur kosturinn, með tap á auðkenni biðlarans skráð. Skráðu hvora þú valdir, því hver síðari annálsspurning veltur á því.

Hlustunarmáti Pi-hole fyrir beindar biðlara

Fellilistinn fyrir hlustunarhegðun tengja á stillingasíðunni undir DNS ræður því hvaða uppsprettum Pi-hole svarar. Strangasti valkosturinn tekur aðeins við biðlurum á beintengdum netum; valkosturinn sem leyfir tækjum að vera í mesta lagi eitt stökk í burtu útvíkkar það á undirnet bak við aðliggjandi beini, og beindur VPN-biðlari lítur nákvæmlega þannig út. Pakkinn berst vissulega á LAN-tengið, en upprunavistfang hans tilheyrir öðru undirneti. Þetta er stefnuleg höfnun en ekki leiðarbilun, og munurinn skiptir máli þegar þú lest annála.

Hlustunarhandbók Pi-hole aðgreinir staðtengdar uppsprettur frá beindum uppruna, og komutengið er ekki mælikvarðinn. Veldu máta sem leyfir VPN-safnið án þess að leyfa allt internetið, og paraðu hann svo við eldveggsreglu sem tekur aðeins við DNS úr safninu.

Að opna endurkvæma uppflettingu fyrir allar uppsprettur svo fyrsta fyrirspurnin virki er röng viðgerð. Það gerir einkanlegan uppflettara að opnum, og leiðréttingin er takmörkuð heimild, ekki alheims.

Láttu svarið passa við fyrirspurnarannálinn

Spurðu biðlarann, athugaðu svo netþjóninn og berðu saman. Á systemd-resolved-biðlara segja skipanirnar hér að neðan hvaða uppflettari framleiddi svar og hvaða netþjónar eru stilltir fyrir hverja tengingu. Notaðu nafn sem aðeins Pi-hole þekkir, því bein fyrirspurn á Pi-hole-vistfangið sannar aðgengi, ekki stillingu.

resolvectl query intranet.example.lan
resolvectl dns

Væntað svar nefnir 192.168.50.53 sem netþjón og skilar vistfangi sem aðeins sá uppflettari myndi þekkja. Líttu svo á eigið yfirlit Pi-hole: pihole -t fylgir fyrirspurnarannálinum í beinni, og hver lína ber upprunavistfangið. Ef uppsprettan er gönguvistfang biðlarans er leið safnsins heil. Ef það er LAN-vistfang gáttarinnar er upprunanþýðing í gangi og eigið vistfang biðlarans mun aldrei birtast.

Ef ekkert birtist í annálnum náði fyrirspurnin aldrei Pi-hole og næsta atriði til að athuga er framsendingin á gáttinni. Ef fyrirspurnin birtist en ekkert svar kemur til baka er vandamálið endurkomuleiðin, það er fyrri kaflinn. Að skipta biluninni svona kemur í veg fyrir að leiðarvilla sé tekin fyrir eldveggsreglu.

Athugaðu framsendingarreglu gáttarinnar

Gáttin verður að framsenda DNS-pakka biðlarans til Pi-hole, og reglan sem gerir það er þess virði að lesa frekar en að gera ráð fyrir. Skipanirnar hér að neðan telja upp reglurnar sem snerta port 53 með teljurum, á nftables-vél og á iptables-vél. Regla sem er til en sýnir núll samsvörun er merkið um að umferð sé hent áður en hún er þýdd.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Lestu teljurana, ekki bara reglurnar. Regla sem passar aldrei þýðir að pakkinn fer út um annað tengi, eða að biðlarinn sendi hann aldrei. Regla sem passar við hverja fyrirspurn þýðir að framsendingin virkar og vandamálið er lengra fram eftir leiðinni.

Hvaða tól sem vélin notar, haltu athuguninni þröngri: safnið sem uppspretta, port 53 sem áfangastaður og Pi-hole sem eina leyfða skotmark. Breið framsendingarregla sem leyfir líka port 80 er annað vandamál sem bíður þess að gerast.