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; రౌటర్ వెబ్ UI లో అది 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 గా కనిపించే ప్రశ్నను యాక్సెస్ జాబితా లేదా ఫైర్వాల్ నియమం తిరస్కరించింది. అన్ని మూలాలకు అనుమతి ఇవ్వడం సాధారణ పరిష్కారం, పోర్ట్ 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 మరియు రిజాల్వర్ విలువలను ఉంచండి; రాత్రి భోజన సమయంలో ఇంటి ఇంటర్నెట్ను విచ్ఛిన్నం చేసే మార్పును డీబగ్ చేయడం ఒక నిమిషంలో తిరిగి తీసుకురాగల మార్పు కంటే చాలా కష్టం.