Itutok ang mga kliyente ng OpenVPN sa Pi-hole resolver sa ibang host

Ang paglalagay ng address ng Pi-hole sa profile ng OpenVPN ay hindi gumagawa ng daan patungo rito, hindi nagbibigay ng pahintulot na tanungin ito, at hindi ginagarantiyahan na gagamitin ito ng kliyente. Kapag ang Pi-hole ay nasa hiwalay na LAN machine, apat na bagay ang dapat magtugma: ang ruta mula sa kliyente, ang pagpapasa mula sa gateway, ang daang pabalik sa pool, at ang patakaran sa pagtanggap sa Pi-hole mismo. Iba ang hitsura ng bawat pagkabigo sa log. Mas mabilis ang paghawan sa kanila sa ayos na iyon kaysa ayusin muna ang huli. Ang karaniwang shortcut, ang pagbukas ng recursion para sa lahat ng pinagmulan, ay nagpapalit ng maliit na problema sa permanente.

Ano ang ginagawa at hindi ginagawa ng itinulak na opsyon sa DNS

Inaanunsyo ng server ang isang resolver sa direktiba sa ibaba, sa pag-aakalang ang 192.168.50.53 ay host ng Pi-hole. Natatanggap ng kliyente ang opsyon at, depende sa platform at integrasyon ng resolver , inilalapat ito sa tunnel interface o binabalewala ito pabor sa lokal na stub. Ang linya ng ruta ay kasinghalaga ng linya ng DNS, dahil ang resolver na hindi maabot ng kliyente ay hindi resolver. Wala sa mga ito ang nakikita mula sa panig ng server.

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"

Ang pagtanggap ng opsyon ay hindi katulad ng paggamit nito. Ang kliyenteng Linux na may tagapamahala ng resolver ay maaaring tumanggap ng itinulak na server at magpadala lamang ng ilang domain dito; ang kliyenteng sariling namamahala ng DNS ay maaaring ganap na patungan ang setting. Ang mga itinulak na ruta ay limitado rin sa ilang platform, kaya nananatiling hindi maabot ang resolver kahit tinanggap ang opsyon. Suriin sa kliyente kung aling server ang sumasagot, hindi sa server kung ano ang ipinadala.

Wala ring sinasabi ang opsyon tungkol sa panig ng server. Kailangan pa ring bumiyahe ng trapikong DNS mula sa kliyente patungo sa gateway at mula sa gateway patungo sa Pi-hole bago maging makabuluhan ang anumang opsyon. Magkamukha ang nawawalang ruta at tinanggihang query mula sa kliyente, kaya tiyakin muna ang pagpapasa sa gateway.

Ang daang pabalik mula sa Pi-hole patungo sa pool

Kung pinapanatili ang source address ng kliyente, sumasagot ang Pi-hole sa isang address sa loob ng pool ng VPN. Malamang walang alam ang sariling routing table nito tungkol sa pool na iyon, kaya pumupunta ang sagot sa default gateway nito at nawawala. Nagpapakita ang query log ng kahilingang walang tugmang sagot, na madaling maling unawain bilang problema sa firewall.

Bigyan ang LAN router ng static na ruta para sa pool na ang OpenVPN gateway ang susunod na hop, o isalin ang source sa gateway bago magpasa sa Pi-hole. Pinapanatili ng una na makita ang address ng bawat kliyente sa query log ng Pi-hole. Tinatanggal ng pangalawa ang pangangailangan sa return route ngunit ginagawang parang galing sa gateway ang bawat query. Wala sa dalawa ang mali; magkaibang tanong ang sinasagot nila.

Kung mahalaga ang pag-uulat o patakaran kada kliyente, ang static na ruta ang mas mabuting palitan. Kung ibang tao ang namamahala sa LAN at walang ruta, ang pagsasalin ang pragmatikong opsyon, na nakatala ang pagkawala ng pagkakakilanlan ng kliyente. Itala kung alin ang pinili mo, dahil nakasalalay dito ang bawat kasunod na tanong sa log.

Ang listening mode ng Pi-hole para sa mga rutadong kliyente

Ang dropdown ng gawi sa pakikinig ng interface sa pahina ng settings sa ilalim ng DNS ang nagtatakda kung aling pinagmulan sumasagot ang Pi-hole. Ang pinakamahigpit na opsyon ay tumatanggap lamang ng mga kliyente sa direktang konektadong network; ang opsyong nagpapahintulot ng mga device na hindi lalampas sa isang hop ay nagpapalawak nito sa mga subnet sa likod ng katabing router, at ganyan talaga ang hitsura ng rutadong kliyente ng VPN. Nakakarating talaga ang packet sa interface ng LAN, ngunit kabilang ang source address nito sa ibang subnet. Ito ay pagtanggi sa patakaran, hindi pagkabigo sa routing, at mahalaga ang pagkakaiba kapag nagbabasa ng log.

Ang gabay sa pakikinig ng Pi-hole ay naghihiwalay ng mga pinagmulang konektado lokal sa mga rutadong pinagmulan, at ang interface ng pagdating ay hindi ang pamantayan. Pumili ng mode na nagpapahintulot sa pool ng VPN nang hindi pinapayagan ang buong internet, pagkatapos ipares ito sa firewall rule na tumatanggap ng DNS mula sa pool lamang.

Ang pagbukas ng recursion para sa lahat ng pinagmulan upang gumana ang unang query ay maling pagkukumpuni. Ginagawa nitong bukas ang isang pribadong resolver, at ang tamang ayos ay limitadong pahintulot, hindi pandaigdigan.

Itugma ang sagot sa query log

Tanungin ang kliyente, pagkatapos suriin ang server at ihambing ang dalawa. Sa kliyenteng systemd-resolved, iniuulat ng mga command sa ibaba kung aling resolver ang gumawa ng sagot at aling mga server ang naka-configure kada link. Gumamit ng pangalang alam lamang ng Pi-hole, dahil ang direktang query sa address ng Pi-hole ay nagpapatunay ng maabot, hindi ng configuration.

resolvectl query intranet.example.lan
resolvectl dns

Ang inaasahang sagot ay nagpapangalan sa 192.168.50.53 bilang server at nagbabalik ng address na alam lamang ng resolver na iyon. Pagkatapos tingnan ang sariling view ng Pi-hole: pihole -t sinusundan ang query log nang live, at bawat linya ay may dalang source address. Kung ang pinagmulan ay tunnel address ng kliyente, buo ang ruta ng pool. Kung address ng LAN ng gateway, may pagsasalin ng source na nagaganap at hinding-hindi lalabas ang sariling address ng kliyente.

Kung wala talagang lumalabas sa log, hindi kailanman nakarating ang query sa Pi-hole at ang susunod na dapat suriin ay ang pagpapasa sa gateway. Kung lumalabas ang query at walang sagot na bumabalik, ang problema ay ang daang pabalik, ibig sabihin ang naunang seksyon. Ang paghahati ng pagkabigo sa ganitong paraan ay pumipigil sa pagkakamali sa routing na mapagkamalang firewall rule.

Suriin ang forwarding rule ng gateway

Dapat ipasa ng gateway ang mga DNS packet ng kliyente patungo sa Pi-hole, at ang rule na gumagawa nito ay dapat basahin, hindi ipagpalagay. Inililista ng mga command sa ibaba ang mga rule na humahawak sa port 53 kasama ang counter, sa host na nftables at sa host na iptables. Ang rule na umiiral ngunit nagpapakita ng zero na tugma ay senyales na itinatapon ang trapiko bago pa ito isalin.

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

Basahin ang counter, hindi lang ang rule. Ang rule na hindi kailanman tumutugma ay nangangahulugang lumalabas ang packet sa ibang interface, o hindi kailanman ito ipinadala ng kliyente. Ang rule na tumutugma sa bawat query ay nangangahulugang gumagana ang pagpapasa at mas malayo pa sa ruta ang problema.

Anuman ang tool na gamitin ng host, panatilihing makitid ang pagsusuri: ang pool bilang source, port 53 bilang destinasyon, at Pi-hole bilang nag-iisang pinapayagang target. Ang malawak na forwarding rule na pinapayagan din ang port 80 ay ibang problemang naghihintay mangyari.