Nukreipti OpenVPN klientus į Pi-hole sprendėją kitame hoste

Pi-hole adreso įrašymas į OpenVPN profilį nesukuria kelio į jį, nesuteikia leidimo jo klausti ir negarantuoja, kad klientas jį naudos. Kai Pi-hole yra atskirame LAN kompiuteryje, turi sutapti keturi dalykai: kelias nuo kliento, persiuntimas iš tinklų sietuvos, grįžimo kelias į baseiną ir priėmimo politika pačiame Pi-hole. Kiekviena klaida žurnale atrodo kitaip. Jų tvarkymas šia tvarka yra greitesnis nei paskutinės taisymas pirmiausia. Įprastas trumpinys, rekursijos atidarymas visiems šaltiniams, keičia mažą problemą į nuolatinę.

Ką stumiamas DNS variantas daro ir ko ne

Serveris paskelbia sprendėją su žemiau pateikta direktyva, darydamas prielaidą, kad 192.168.50.53 yra Pi-hole hostas. Klientas gauna variantą ir, priklausomai nuo platformos ir sprendėjo integracijos , pritaiko jį tunelio sąsajai arba nepaiso jo naudodamas vietinį stub. Maršruto eilutė yra tokia pat svarbi kaip DNS eilutė, nes sprendėjas, kurio klientas negali pasiekti, nėra joks sprendėjas. Niekas iš to nėra matoma serverio pusėje.

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"

Gauti variantą nėra tas pats, kas jį naudoti. Linux klientas su sprendėjo tvarkykle gali priimti stumiamą serverį ir siųsti jam tik tam tikrus domenus; klientas, kuris pats valdo DNS, gali visiškai perrašyti nustatymą. Stumiami maršrutai kai kuriose platformose taip pat ribojami, todėl sprendėjas lieka nepasiekiamas net priėmus variantą. Tikrinkite kliente, kuris serveris atsako, o ne serveryje, kas buvo išsiųsta.

Variantas taip pat nieko nesako apie serverio pusę. DNS srautas vis tiek turi keliauti nuo kliento iki tinklų sietuvos ir nuo tinklų sietuvos iki Pi-hole, kol bet kuris variantas įgyja prasmę. Trūkstamas maršrutas ir atmestas užklausimas iš kliento pusės atrodo vienodai, todėl pirmiausia patvirtinkite persiuntimą tinklų sietuvoje.

Grįžimo kelias iš Pi-hole į baseiną

Jei kliento šaltinio adresas išsaugomas, Pi-hole atsako į adresą VPN baseine. Jo paties maršrutizavimo lentelė greičiausiai nieko nežino apie šį baseiną, todėl atsakymas nueina į jo numatytąją tinklų sietuvą ir dingsta. Užklausų žurnalas rodo užklausą be atitinkančio atsakymo, ką lengva supainioti su ugniasienės problema.

Suteikite LAN maršrutizatoriui statinį maršrutą į baseiną su OpenVPN tinklų sietuva kaip kitu šuoliu, arba išverskite šaltinį tinklų sietuvoje prieš persiųsdami į Pi-hole. Pirmasis išlaiko kiekvieno kliento adresus matomus Pi-hole užklausų žurnale. Antrasis pašalina grįžimo maršruto reikalavimą, bet kiekvieną užklausą padaro atrodančią tarsi ji atėjo iš tinklų sietuvos. Nė vienas nėra neteisingas; jie atsako į skirtingus klausimus.

Jei svarbus atskaitomybė ar politika pagal klientą, statinis maršrutas yra geresnis mainas. Jei LAN valdo kažkas kitas ir maršruto nėra, vertimas yra pragmatiškas variantas, su užrašytu kliento tapatybės praradimu. Užsirašykite, kurį pasirinkote, nes kiekvienas vėlesnis žurnalo klausimas nuo to priklauso.

Pi-hole klausymosi režimas maršrutizuotiems klientams

Sąsajų klausymosi elgsenos išskleidžiamasis sąrašas nustatymų puslapyje skiltyje DNS nusprendžia, kuriems šaltiniams Pi-hole atsako. Griežčiausias variantas priima tik tiesiogiai prijungtų tinklų klientus; variantas, leidžiantis įrenginiams būti ne toliau kaip vieną šuolį, išplečia tai potinkliams už gretimo maršrutizatoriaus, ir maršrutizuotas VPN klientas atrodo būtent taip. Paketas tikrai pasiekia LAN sąsają, bet jo šaltinio adresas priklauso kitam potinkliui. Tai politikos atmetimas, o ne maršrutizavimo gedimas, ir skirtumas svarbus skaitant žurnalus.

Pi-hole klausymosi vadovas atskiria vietoje prijungtus šaltinius nuo maršrutizuotos kilmės, o atvykimo sąsaja nėra kriterijus. Pasirinkite režimą, kuris leidžia VPN baseiną neleisdamas viso interneto, tada suderinkite jį su ugniasienės taisykle, kuri priima DNS tik iš baseino.

Rekursijos atidarymas visiems šaltiniams, kad pirmoji užklausa veiktų, yra neteisingas taisymas. Tai paverčia privatų sprendėją atviru, o pataisymas yra apribotas leidimas, ne globalus.

Suderinkite atsakymą su užklausų žurnalu

Paklauskite kliento, tada patikrinkite serverį ir palyginkite abu. systemd-resolved kliente žemiau pateiktos komandos praneša, kuris sprendėjas sukūrė atsakymą ir kurie serveriai sukonfigūruoti kiekvienai nuorodai. Naudokite vardą, kurį žino tik Pi-hole, nes tiesioginė užklausa Pi-hole adresui įrodo pasiekiamumą, o ne konfigūraciją.

resolvectl query intranet.example.lan
resolvectl dns

Laukiamas atsakymas nurodo 192.168.50.53 kaip serverį ir grąžina adresą, kurį žinotų tik tas sprendėjas. Tada pažiūrėkite į paties Pi-hole vaizdą: pihole -t seka užklausų žurnalą realiuoju laiku, ir kiekviena eilutė neša šaltinio adresą. Jei šaltinis yra kliento tunelio adresas, baseino maršrutas yra sveikas. Jei tai tinklų sietuvos LAN adresas, vyksta šaltinio vertimas ir paties kliento adresas niekada nepasirodys.

Jei žurnale nieko nepasirodo, užklausa niekada nepasiekė Pi-hole, o kitas tikrinamas dalykas yra persiuntimas tinklų sietuvoje. Jei užklausa pasirodo, bet atsakymas negrįžta, problema yra grįžimo kelyje, tai yra ankstesniame skyriuje. Toks gedimo padalijimas neleidžia maršrutizavimo klaidos palaikyti ugniasienės taisykle.

Patikrinkite tinklų sietuvos persiuntimo taisyklę

Tinklų sietuva turi persiųsti kliento DNS paketus Pi-hole link, o taisyklė, kuri tai daro, verta skaitymo, o ne prielaidos. Žemiau pateiktos komandos išvardija taisykles, kurios liečia 53 prievadą, su skaitikliais, nftables hoste ir iptables hoste. Taisyklė, kuri egzistuoja, bet rodo nulį atitikimų, yra signalas, kad srautas metamas prieš jį išverčiant.

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

Skaitykite skaitiklius, ne tik taisykles. Taisyklė, kuri niekada neatitinka, reiškia, kad paketas išeina per kitą sąsają arba klientas jo niekada neišsiuntė. Taisyklė, kuri atitinka kiekvieną užklausą, reiškia, kad persiuntimas veikia ir problema yra toliau kelyje.

Kad ir kokį įrankį hostas naudotų, laikykite patikrinimą siaurą: baseinas kaip šaltinis, 53 prievadas kaip paskirties vieta ir Pi-hole kaip vienintelis leidžiamas tikslas. Plati persiuntimo taisyklė, leidžianti ir 80 prievadą, yra kita problema, laukianti įvyksiant.