VPN холбогдсоны дараа Pi-hole зар сурталчилгааг блоклохгүй байна: таван шалгалт

Клиент дээр зар сурталчилгаа харагдаж байна, Pi-hole өөрийгөө эрүүл гэж мэдээлж байна, туннель ажиллаж байна, тиймээс тэр клиентийн урсгалыг Pi-ээр дамжуулах сэтгэл төрнө. Энэ нь буруу эргэлт юм. Шүүлтүүрт пакет биш, асуулга хэрэгтэй бөгөөд асуулга нь ISP-ийн шийдэгч рүү явдаг клиент урсгал нь хаашаа урсаж байсан ч шүүлтүүргүй үлддэг. Энэ жагсаалтыг дараалан хийж, бүтэлгүйтсэн эхний алхамд зогсо, учир нь өмнөх алхам эвдэрсэн байхад дараагийн алхам юу ч хэлж чадахгүй.

1. Клиентийн бодитоор ашиглаж буй шийдэгчийг унш

Роутерээс биш, клиентээс асуу. Linux дээр resolvectl status холбоос бүрийн DNS сервер болон аль холбоос ялахыг хэвлэнэ; /etc/resolv.conf дангаараа ихэвчлэн 127.0.0.53 рүү заасан stub байдаг. Windows дээр ipconfig /all адаптер бүрт DHCP-ийн өгсөн серверүүдийг жагсаана, macOS дээр scutil --dns мөн адил зүйлийг хамрах хүрээгээр харуулна. Хэрэв хариулт нь Pi-hole-ийн хаяг биш бол танд хуваарилалтын асуудал байгаа бөгөөд 2-р алхам нь түүний байрлаж буй газар.

Системийн шийдэгчийг зөв тохируулсан ч хоёр зүйл түүнийг ялдаг. Өөрийн аюулгүй DNS-тэй хөтчүүд (Chrome-ийн “Use secure DNS” сонголт, Firefox-ийн network.trr.mode) асуулгыг HTTPS-ээр нийтийн шийдэгч рүү илгээж, 53 портыг хэзээ ч онгойлгодоггүй. Мөн клиент дээрх VPN клиент өөрийн туннелийн интерфэйс дээр ~. чиглүүлэлтийн домэйнтэй DNS сервер суулгаж болох бөгөөд энэ нь тухайн холбоосыг бүх нэрэнд эрх бүхий болгоно.

Аппликейшнүүдийн явдаг замыг шалга, дибаг хэрэгслийн явдаг замыг биш. resolvectl query example.com аль холбоос хариулсныг харуулж, getent hosts example.com аппликейшний явдаг ижил NSS замаар явна; macOS дээр dscacheutil -q host -a name example.com нь scutil --dns-ийн жагсаасан хамрах хүрээний шийдэгчүүдийг уншина. Энгийн dig үүнийг хийдэггүй: тэр /etc/resolv.conf-ыг уншиж, холбоосоор сонгохыг алгасдаг тул бүх аппликейшн түлхэгдсэн шийдэгчийг ашиглаж байхад Pi-hole-оос хариулж болно, энэ бол яг энэ жагсаалтын барих зорилготой алдаа юм. Тодорхой нэг серверийг шалгахын тулд dig @192.168.1.53-ыг үлдээ.

2. Хариултыг хэн тарааж байгааг батал

Хуваарилалт нь DHCP-д хариулдаг зүйлээс ирдэг. dnsmasq дээр энэ нэг мөр, dhcp-option=6,192.168.1.53; роутерийн вэб интерфэйс дээр энэ нь LAN DHCP хэсгийн DNS талбар. Клиентүүд үүнийг харахаасаа өмнө шинэчлэх ёстой. Олон хоног ажиллаж байгаа төхөөрөмж хуучин түрээсийг хэвээр барьж, шийдэгчийг гараар бичсэн төхөөрөмж үүнийг үүрд барьдаг. Тархалтыг таамаглахын оронд туршилтын клиент дээр шинэчил.

IPv6 бол мартагддаг хагас юм. Роутерийн зарлалууд өөрийн DNS серверийг авч явж болно (RDNSS), OpenWrt дээр энэ нь odhcpd-ийн ra_dns сонголт; IPv6-г илүүд үздэг клиент тэр серверийг ашиглаж, саяхан тавьсан DHCPv4 сонголт ашиглагдаагүй үлддэг. Хэрэв IPv6 DNS үйлчлэхэд бэлэн биш бол зөвхөн DNS зарлалыг арилга: odhcpd дэх ra_dns, эсвэл роутерийн зарлалд хариулдаг зүйл дэх RDNSS сонголт. Бүх зарлалыг унтраах нь LAN-аас IPv6 хаяглалтыг ч хасдаг бөгөөд энэ нь таны зорьсноос хамаагүй том өөрчлөлт; харин зөвхөн DNS сонголтыг арилгах нь хаяглалтыг хөндөгдөөгүй үлдээж, дутуу RDNSS-ийг пакет барилтад харагдахуйц болгоно.

3. Асуулга Pi-hole-д хүрч байгааг нотол

Pi-ээс хийсэн асуулга сүлжээний замын талаар юу ч нотолдоггүй. Үүнийг клиентээс ажиллуулж, хариултын кодыг унш:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

Хугацаа хэтрэх нь шүүлтүүр эсвэл зам руу заана; REFUSED нэвтрэх дүрэм рүү; SERVFAIL Pi-hole-ийн ард байгаа дээд шийдэгч рүү; асуулгын логт хэзээ ч харагдахгүй зөв хариулт нь клиент өөр зүйл асуусан гэсэн үг. UDP болон TCP 53-ыг шалга, учир нь том хариулт болон зарим шийдэгч TCP руу буцдаг, Pi-hole контейнерт ажиллаж байхад хоёуланг нь нийтэл. Зөвхөн UDP-г хамарсан зураглал нь пакет алдагдахтай төстэй хааяа алдаа үүсгэдэг.

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

4. Туннель хариултыг орлуулсан эсвэл залгичихсан эсэхийг шалга

Энэ бол хоёр шинж тэмдэг нуугдаж буй тохиолдол. Роутер өөрөө VPN клиент байхад, түлхэгдсэн DNS сонголт туннель босох мөчид LAN тохиргоог дарж болно: OpenVPN серверүүд dhcp-option DNS-ийг түлхэж, WireGuard профайлууд өөрийн DNS бичлэгийг агуулна. Роутерийн үр дүнтэй шийдэгчийг туннель ажиллаж байхад унш, түүнээс өмнө биш, LAN хуудасны мэдэгдлийг үл тоомсорло.

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

Хоёулыг биш, нэг засварыг сонго. Нэг бол туннелийг DNS-ээс хол байлга — OpenVPN дээр pull-filter ignore “dhcp-option DNS”, WireGuard дээр AllowedIPs дотор LAN префиксгүйгээр —, эсвэл түлхэгдсэн шийдэгчийг хүлээн авч, тэр роутерийн ард байгаа клиентүүдэд локал шүүлтүүрээс татгалз. Аль нэгийг сонгосон ч профайлын хажууд бичиж үлдээ, эс бөгөөс дараагийн засварлагч санамсаргүйгээр шийдвэрийг эргүүлнэ.

5. Дахин холбогдсоны дараа туршилтыг давт

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

Туннелээс хамааралгүй хоёрдогч шийдэгчийн зам үлдээ, ингэснээр Pi-hole-ийн доголдол огт хөтлөхгүй байхын оронд шүүлтүүргүй хөтлөлт рүү буурна. Туршилт хоёр удаа давтагдах хүртэл өмнөх DHCP болон шийдэгчийн утгуудыг хадгал; оройн хоолны үеэр гэрийн интернэтийг эвдэх өөрчлөлтийг нэг минутад буцаах боломжтой өөрчлөлтөөс хамаагүй хэцүү засаж засна.