Pi-hole-ը VPN-ի միանալուց հետո գովազդները չի արգելափակում. հինգ ստուգում

Գովազդները դեռ ցուցադրվում են որոշակի կլիենտում, Pi-hole-ը իրեն առողջ է հայտարարում, և թունելը ակտիվ է, ուստի բնազդը հուշում է այդ կլիենտի երթևեկությունն անցկացնել Pi-ի միջով։ Դա սխալ շրջադարձ է։ Զտումը պահանջում է հարցերը, ոչ թե փաթեթները, և այն կլիենտը, ում հարցումները գնում են մատակարարի լուծիչին, մնում է չզտված՝ անկախ նրանից, թե ուր է հոսում նրա երթևեկությունը։ Անցեք այս ցանկը հերթականությամբ և կանգ առեք առաջին քայլի վրա, որը ձախողվում է, որովհետև ավելի ուշ քայլը ոչինչ չի կարող ասել, քանի դեռ ավելի վաղ քայլը կոտրված է։

1. Կարդացեք այն լուծիչը, որն իրականում օգտագործում է կլիենտը

Հարցրեք կլիենտին, ոչ թե երթուղիչին։ Linux-ում resolvectl status-ը տպում է DNS սերվերները յուրաքանչյուր կապի համար և այն, թե որ կապն է հաղթում; /etc/resolv.conf-ը ինքնին սովորաբար stub է, որը ցույց է տալիս 127.0.0.53-ին։ 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; երթուղիչի վեբ ինտերֆեյսում դա DNS դաշտն է LAN DHCP բաժնում։ Կլիենտները պետք է նորոգեն մինչև դա տեսնելը։ Օրեր շարունակ աշխատող սարքը դեռ պահում է հին վարձակալությունը, իսկ ձեռքով մուտքագրված լուծիչ ունեցող սարքը պահում է այն ընդմիշտ։ Նորոգեք փորձնական կլիենտի վրա՝ տարածումը ենթադրելու փոխարեն։

IPv6-ը այն կեսն է, որը բաց է թողնվում։ Երթուղիչի հայտարարությունները կարող են կրել իրենց սեփական DNS սերվերը (RDNSS), և OpenWrt-ում դա odhcpd-ի ra_dns ընտրանքն է; այն կլիենտը, որը նախընտրում է IPv6-ը, օգտագործում է այդ սերվերը, մինչդեռ հենց նոր սահմանված DHCPv4 ընտրանքը մնում է չօգտագործված։ Եթե պատրաստ չեք IPv6 DNS մատուցել, մաքրեք միայն DNS հայտարարությունը՝ ra_dns-ը odhcpd-ում, կամ RDNSS ընտրանքը այն ամենում, ինչը պատասխանում է երթուղիչի հայտարարություններին։ Ամբողջ հայտարարությունը անջատելը հեռացնում է նաև IPv6 հասցեավորումը LAN-ից, ինչը շատ ավելի մեծ փոփոխություն է, քան նախատեսել էիք, մինչդեռ միայն 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-ի կանոնով։ Բոլոր աղբյուրներին թույլատրելը սովորական լուծումն է՝ զուգորդված firewall-ի կանոնով, որը 53 պորտը սահմանափակում է ձեր սեփական ենթացանցերով։

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 և լուծիչ արժեքները, մինչև փորձարկումը երկու անգամ անցնի; փոփոխությունը, որը կտրում է տնային ինտերնետը ընթրիքի ժամին, շատ ավելի դժվար է կարգաբերել, քան այն, որը կարող եք հետ շրջել մեկ րոպեում։