OpenVPN клиентүүдийг өөр хост дээрх Pi-hole шийдвэрлэгч рүү чиглүүлэх

OpenVPN профайлд Pi-hole хаяг хийх нь түүн рүү зам үүсгэхгүй, түүнээс асуух зөвшөөрөл өгөхгүй, клиент үүнийг ашиглана гэдгийг баталгаажуулахгүй. Pi-hole тусдаа LAN машин дээр байх үед дөрвөн зүйл нийцэх ёстой: клиентээс гарах зам, гарцаас дамжуулах, усан сан руу буцах зам, Pi-hole өөр дээрх хүлээн авах бодлого. Алдаа бүр лог дотор өөрөөр харагдана. Тэдгээрийг энэ дарааллаар шийдэх нь сүүлийг эхэлж засахаас хурдан. Ердийн богино зам болох бүх эх үүсвэрт рекурс нээх нь жижиг асуудлыг байнгын асуудал болгон солино.

Түлхэгдсэн DNS сонголт юу хийдэг, юу хийдэггүй

Сервер доорх зааврын дагуу шийдвэрлэгчийг зарлаж, 192.168.50.53 нь Pi-hole хост гэж үзнэ. Клиент сонголтыг хүлээн авч, платформ болон шийдвэрлэгчийн интеграцаас хамааран , үүнийг туннелийн интерфейс дээр хэрэглэх эсвэл орон нутгийн stub-ын төлөө үл тоомсорлоно. Замын мөр нь DNS мөртэй адил чухал, учир нь клиент хүрч чадахгүй шийдвэрлэгч бол шийдвэрлэгч огт биш. Эдгээрийн аль нь ч серверийн талаас харагдахгүй.

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"

Сонголтыг хүлээн авах нь түүнийг ашиглахтай ижил биш. Шийдвэрлэгчийн менежертэй Linux клиент түлхэгдсэн серверийг хүлээн авч зөвхөн тодорхой домэйн илгээж болно; DNS-ийг өөрөө удирддаг клиент тохиргоог бүрэн дарж бичиж болно. Түлхэгдсэн замууд зарим платформ дээр хязгаарлагдмал байдаг бөгөөд сонголт хүлээн авсан ч шийдвэрлэгч хүрэхгүй хэвээр байна. Аль сервер хариу үйлдэж байгааг клиент дээр шалга, сервер дээр юу илгээснийг биш.

Сонголт серверийн талын тухай ч юу ч хэлэхгүй. DNS урсгал ямар ч сонголт утга учиртай болохоос өмнө клиентээс гарц руу, гарцаас Pi-hole руу явах ёстой. Алга болсон зам болон татгалзсан асуулга клиентийн талаас ижил харагдана, тиймээс эхлээд гарц дээрх дамжуулалтыг баталгаажуул.

Pi-hole-оос усан сан руу буцах зам

Хэрэв клиентийн эх хаяг хадгалагдвал Pi-hole нь VPN усан сан доторх хаяг руу хариулна. Түүний өөрийн маршрутын хүснэгт энэ усан сангийн тухай юу ч мэдэхгүй байх магадлалтай, тиймээс хариу нь түүний үндсэн гарц руу явж алга болно. Асуулгын лог тохирох хариугүй хүсэлтийг харуулдаг бөгөөд үүнийг галт хананы асуудал гэж амархан буруу ойлгож болно.

LAN чиглүүлэгчид усан сангийн хувьд OpenVPN гарцыг дараагийн хоп болгосон статик зам өг, эсвэл Pi-hole руу дамжуулахаас өмнө гарц дээр эхийг хөрвүүл. Эхнийх нь клиент бүрийн хаягийг Pi-hole-ийн асуулгын лог дээр харагдуулж үлдээнэ. Хоёр дахь нь буцах замын шаардлагыг арилгах боловч асуулга бүрийг гарцаас ирсэн мэт харагдуулна. Аль нь ч буруу биш; тэд өөр асуултад хариулдаг.

Клиент тус бүрийн тайлан эсвэл бодлого чухал бол статик зам нь илүү сайн солилцоо. Хэрэв LAN-ыг өөр хүн удирдаж, зам байхгүй бол хөрвүүлэлт нь практик сонголт бөгөөд клиентийн таних тэмдэг алдагдсаныг тэмдэглэнэ. Алийг нь сонгосноо бич, учир нь дараагийн лог асуулт бүр үүнээс хамаарна.

Чиглүүлсэн клиентүүдэд зориулсан Pi-hole-ийн сонсох горим

DNS-ийн доорх тохиргооны хуудас дээрх интерфейсүүдийн сонсох зан үйлийн унадаг цэс нь Pi-hole аль эх үүсвэрт хариулахыг тодорхойлно. Хамгийн хатуу сонголт нь шууд холбогдсон сүлжээн дэх клиентүүдийг л хүлээн авна; төхөөрөмжийг хамгийн ихдээ нэг хоп зайд зөвшөөрдөг сонголт үүнийг хажуугийн чиглүүлэгчийн ард байх дэд сүлжээнд хүртэл өргөтгөдөг бөгөөд чиглүүлсэн VPN клиент яг ийм харагдана. Пакет үнэхээр LAN интерфейс дээр ирдэг ч түүний эх хаяг өөр дэд сүлжээнд хамаарна. Энэ нь бодлогын татгалзал бөгөөд маршрутын алдаа биш, лог уншихад энэ ялгаа чухал.

Pi-hole-ийн сонсох гарын авлага орон нутгийн холбогдсон эх үүсвэрийг чиглүүлсэн гарал үүслээс ялгадаг бөгөөд ирэх интерфейс нь шалгуур биш. Бүх интернэтийг зөвшөөрөхгүйгээр VPN усан санг зөвшөөрдөг горим сонго, дараа нь усан сангаас л DNS хүлээн авдаг галт хананы дүрэмтэй хослуул.

Эхний асуулга ажиллахын тулд бүх гарал үүсэлд рекурс нээх нь буруу засвар. Энэ нь хувийн шийдвэрлэгчийг нээлттэй болгодог бөгөөд засвар нь хязгаарлагдмал зөвшөөрөл, дэлхийн биш.

Хариуг асуулгын логтой тааруул

Клиентээс асуу, дараа нь серверийг шалгаж, хоёрыг харьцуул. systemd-resolved клиент дээр доорх командууд аль шийдвэрлэгч хариу үүсгэсэн, холбоос бүрт ямар серверүүд тохируулагдсаныг мэдээлнэ. Зөвхөн Pi-hole мэддэг нэрийг ашигла, учир нь Pi-hole хаяг руу шууд асуулга хүрэх боломжийг баталдаг, тохиргоог биш.

resolvectl query intranet.example.lan
resolvectl dns

Хүлээгдэж буй хариу 192.168.50.53-ыг сервер гэж нэрлэж, зөвхөн тэр шийдвэрлэгч мэдэх хаягийг буцаана. Дараа нь Pi-hole-ийн өөрийн харагдацыг хар: pihole -t асуулгын логийг шууд дагаж, мөр бүр эх хаягийг агуулна. Эх нь клиентийн туннелийн хаяг бол усан сангийн зам бүрэн бүтэн. Хэрэв гарцын LAN хаяг бол эхийн хөрвүүлэлт явагдаж байгаа бөгөөд клиентийн өөрийн хаяг хэзээ ч харагдахгүй.

Лог дээр юу ч харагдахгүй бол асуулга Pi-hole-д хэзээ ч хүрээгүй бөгөөд дараагийн шалгах зүйл нь гарц дээрх дамжуулалт. Асуулга харагдаж, хариу буцаж ирэхгүй бол асуудал буцах замд, өөрөөр хэлбэл өмнөх хэсэгт байна. Алдааг ингэж хуваах нь маршрутын алдааг галт хананы дүрэм гэж андуурахаас сэргийлнэ.

Гарцын дамжуулах дүрмийг шалга

Гарц клиентийн DNS пакетыг Pi-hole руу дамжуулах ёстой бөгөөд үүнийг хийдэг дүрмийг таамаглахын оронд унших нь зүйтэй. Доорх командууд 53 портыг хөндөх дүрмүүдийг тоолууртайгаар жагсаана, nftables хост болон iptables хост дээр. Байгаа боловч тэг тохирол харуулж буй дүрэм нь урсгалыг хөрвүүлэхээс өмнө хаяж байгаагийн дохио.

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

Тоолуурыг унш, зөвхөн дүрмийг биш. Хэзээ ч тохирохгүй дүрэм нь пакет өөр интерфейсээр гарч байгаа эсвэл клиент үүнийг хэзээ ч илгээгээгүй гэсэн үг. Асуулга бүрт тохирдог дүрэм нь дамжуулалт ажиллаж байгаа бөгөөд асуудал замын цаагуур байгаа гэсэн үг.

Хост ямар хэрэгсэл ашигласан ч шалгалтыг нарийн бари: усан санг эх үүсвэр, 53 портыг очих газар, Pi-hole-ийг цорын ганц зөвшөөрөгдсөн зорилт болго. 80 портыг ч зөвшөөрдөг өргөн дамжуулах дүрэм нь тохиолдохыг хүлээж буй өөр асуудал.