Pi-hole haizuii matangazo baada ya VPN kuunganishwa: ukaguzi tano

Matangazo bado yanaonekana kwenye mteja, Pi-hole inajitangaza kuwa nzima, na handaki iko hai, kwa hiyo silika ni kuelekeza trafiki ya mteja huyo kupitia Pi. Hiyo ni zamu isiyo sahihi. Uchujaji unahitaji maswali, si pakiti, na mteja ambaye maulizo yake yanaenda kwa kitatuzi cha mtoa huduma hubaki bila kuchujwa popote trafiki yake inapita. Pitia orodha hii kwa mpangilio na usimame kwenye hatua ya kwanza inayoshindikana, kwa sababu hatua ya baadaye haiwezi kukuambia chochote wakati hatua ya awali imevunjika.

1. Soma kitatuzi ambacho mteja anakitumia kwa kweli

Muulize mteja, si kipanga njia. Kwenye Linux resolvectl status huchapisha seva za DNS kwa kila kiungo na kiungo kipi kinashinda; /etc/resolv.conf peke yake kwa kawaida ni stub inayoelekeza kwa 127.0.0.53. Kwenye Windows ipconfig /all huorodhesha seva zilizotolewa na DHCP kwa kila adapta, na kwenye macOS scutil --dns huonyesha kitu kimoja kwa wigo. Ikiwa jibu si anwani ya Pi-hole, una tatizo la ugawaji na hatua 2 ni mahali inapoishi.

Mambo mawili hushinda kitatuzi cha mfumo hata kikiwa kimewekwa sawa. Vivinjari vyenye DNS yao salama (chaguo la “Use secure DNS” la Chrome, network.trr.mode la Firefox) hutuma maulizo kwa HTTPS kwa kitatuzi cha umma na kamwe hazifungui lango 53. Na mteja wa VPN kwenye mteja mwenyewe anaweza kusakinisha seva ya DNS kwenye kiolesura chake cha handaki na kikoa cha uelekezaji ~., jambo linalofanya kiungo hicho kuwa na mamlaka kwa kila jina.

Jaribu njia ambayo programu hupitia, si njia ambayo chombo cha utatuzi hupitia. resolvectl query example.com huonyesha ni kiungo kipi kilijibu, na getent hosts example.com hupitia njia ile ile ya NSS kama programu; kwenye macOS dscacheutil -q host -a name example.com husoma vitatuzi vya wigo ambavyo scutil --dns huorodhesha. dig tupu haifanyi hivi: husoma /etc/resolv.conf na huruka uchaguzi kwa kiungo, kwa hiyo inaweza kujibu kutoka Pi-hole wakati kila programu inatumia kitatuzi kilichosukumwa, na hilo ndilo hasa shindwa ambalo orodha hii ipo kulinasa. Weka dig @192.168.1.53 kwa kujaribu seva moja maalum.

2. Thibitisha nani anasambaza jibu

Ugawaji hutoka kwa kitu chochote kinachojibu DHCP. Kwenye dnsmasq ni mstari mmoja, dhcp-option=6,192.168.1.53; kwenye kiolesura cha wavuti cha kipanga njia ni sehemu ya DNS katika sehemu ya DHCP ya LAN. Wateja lazima wafanye upya kabla ya kuiona. Kifaa kilichowaka kwa siku nyingi bado kinashikilia ukodishaji wa zamani, na kifaa chenye kitatuzi kilichoandikwa kwa mkono hukishikilia milele. Fanya upya kwenye mteja wa majaribio badala ya kudhani kuenea.

IPv6 ni nusu inayokosekana. Matangazo ya kipanga njia yanaweza kubeba seva yao ya DNS (RDNSS), na kwenye OpenWrt hilo ni chaguo la ra_dns la odhcpd; mteja anayependelea IPv6 hutumia seva hiyo wakati chaguo la DHCPv4 uliloweka sasa linabaki bila kutumika. Ikiwa hujawa tayari kuhudumia DNS kwa IPv6, futa tangazo la DNS pekee: ra_dns katika odhcpd, au chaguo la RDNSS katika chochote kinachojibu matangazo ya kipanga njia. Kuzima tangazo lote pia huondoa anwani za IPv6 kwenye LAN, jambo ambalo ni badiliko kubwa zaidi kuliko ulilokusudia, wakati kufuta chaguo la DNS pekee kunahifadhi anwani salama na kufanya RDNSS inayokosekana ionekane katika kunasa pakiti.

3. Thibitisha kwamba ulizo unafika Pi-hole

Ulizo kutoka Pi huthibitisha chochote kuhusu njia ya mtandao. Lianza kutoka kwa mteja na soma msimbo wa majibu:

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

Muda kuisha huashiria uchujaji au njia; REFUSED huashiria kanuni ya ufikiaji; SERVFAIL huashiria kitatuzi cha juu nyuma ya Pi-hole; jibu sahihi ambalo haliwahi kuonekana kwenye kumbukumbu ya maulizo humaanisha mteja aliuliza kitu kingine. Kagua UDP na TCP 53, kwa sababu majibu makubwa na baadhi ya vitatuzi hurudi kwa TCP, na uchapisha zote mbili wakati Pi-hole inaendeshwa kwenye kontena. Ramani inayoshughulikia UDP pekee huzalisha kushindwa kwa vipindi kunakofanana na upotevu wa pakiti.

Kisha hali ya kusikiliza ya Pi-hole huamua kama inajibu kabisa. Katika hali ya ndani pekee dnsmasq hupuuza maulizo kutoka vyanzo visivyo kwenye subneti iliyounganishwa moja kwa moja, na ndivyo mteja aliye nyuma ya kipanga njia kingine au anayekuja kupitia handaki anavyoonekana: mteja hukosa muda na ulizo hufika kwenye kumbukumbu. Ulizo ambao bado unaonekana kama REFUSED ulikataliwa na orodha ya ufikiaji au kanuni ya firewall. Kuruhusu vyanzo vyote ndiyo suluhisho la kawaida, pamoja na kanuni ya firewall inayoweka lango 53 kwa subneti zako mwenyewe.

4. Kagua kama handaki ilibadilisha au ilimeza jibu

Hii ndiyo kesi ambayo dalili zote mbili hujificha. Wakati kipanga njia chenyewe ni mteja wa VPN, chaguo la DNS lililosukumwa linaweza kupindua mpangilio wa LAN pale handaki inapoinuka: seva za OpenVPN husukuma dhcp-option DNS, na wasifu wa WireGuard hubeba ingizo lao la DNS. Soma kitatuzi halisi cha kipanga njia wakati handaki iko hai, si kabla, na puuza kile ukurasa wa LAN unadai.

Hitilafu nyingine ni ufikikaji, si uingizwaji. Ikiwa viambishi vilivyoruhusiwa vya handaki vinajumuisha subneti yako ya LAN, kipanga njia kina njia inayotuma maulizo ya 192.168.1.53 ndani ya handaki, na upande wa pili hauna njia ya kurudi: maulizo hukosa muda ingawa handaki iko nzima. Kinyume chake hutokea wakati Pi-hole iko kwenye subneti ambayo handaki haibebi. Linganisha anwani na viambishi vilivyoruhusiwa vya handaki na jedwali la njia la kipanga njia kabla ya kugusa DNS tena.

Chagua suluhisho moja, si yote mawili. Ama weka handaki mbali na DNS — kwa pull-filter ignore “dhcp-option DNS” kwenye OpenVPN na bila kiambishi cha LAN kwenye AllowedIPs kwenye WireGuard —, au kubali kitatuzi kilichosukumwa na uachane na uchujaji wa ndani kwa wateja walio nyuma ya kipanga njia hicho. Uchague chochote, kiandike kando ya wasifu, kwa sababu mtu anayefuata kuubadilisha atageuza uamuzi kwa bahati mbaya.

5. Rudia jaribio baada ya kuunganisha upya

Uliza kutoka kwa mteja, thibitisha kwamba mteja huyo anaonekana kwenye kumbukumbu ya Pi-hole, kisha tatua kikoa kinachopaswa kuzuiwa na uangalie kwamba unapata jibu la kuzuia badala ya lile halisi. Unganisha handaki tena na endesha maulizo yale yale mawili, kwa sababu mpangilio wa kitatuzi unaodumu hadi muunganisho unaofuata tu ndiyo tokeo la kawaida la suluhisho lililotumika kwenye tabaka isiyo sahihi.

Acha njia ya pili ya kitatuzi isiyotegemea handaki, ili hitilafu ya Pi-hole ishuke hadi kuvinjari bila kuchujwa badala ya kutokuwa na kuvinjari kabisa. Weka thamani za awali za DHCP na kitatuzi hadi jaribio lipite mara mbili; badiliko linalovunja intaneti ya nyumbani wakati wa chakula cha jioni ni gumu zaidi kutafuta hitilafu kuliko lile unaloweza kurudisha kwa dakika moja.