VPN ബന്ധിപ്പിച്ചതിന് ശേഷവും Pi-hole പരസ്യങ്ങൾ തടയുന്നില്ല: അഞ്ച് പരിശോധനകൾ

ഒരു ക്ലയന്റിൽ പരസ്യങ്ങൾ ഇപ്പോഴും കാണുന്നു, Pi-hole തന്നെ ആരോഗ്യവാനാണെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, ടണൽ സജീവമാണ്, അതിനാൽ ആ ക്ലയന്റിന്റെ ട്രാഫിക് Pi വഴി അയയ്ക്കണം എന്ന തോന്നൽ ഉണ്ടാകും. അത് തെറ്റായ തിരിവാണ്. ഫിൽട്ടറിംഗിന് പാക്കറ്റുകളല്ല, ചോദ്യങ്ങളാണ് വേണ്ടത്, ചോദ്യങ്ങൾ ISP യുടെ റിസോൾവറിലേക്ക് പോകുന്ന ക്ലയന്റ് അതിന്റെ ട്രാഫിക് എവിടേക്ക് ഒഴുകിയാലും ഫിൽട്ടർ ചെയ്യപ്പെടാതെ തുടരും. ഈ പട്ടിക ക്രമത്തിൽ പൂർത്തിയാക്കി പരാജയപ്പെടുന്ന ആദ്യ ഘട്ടത്തിൽ നിർത്തുക, കാരണം മുൻ ഘട്ടം തകർന്നിരിക്കുമ്പോൾ അടുത്ത ഘട്ടത്തിന് നിങ്ങളോട് ഒന്നും പറയാനാകില്ല.

1. ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന റിസോൾവർ വായിക്കുക

റൗട്ടറിനോടല്ല, ക്ലയന്റിനോട് ചോദിക്കുക. Linux ൽ resolvectl status ഓരോ ലിങ്കിന്റെയും DNS സർവറുകളും ഏത് ലിങ്ക് വിജയിക്കുന്നു എന്നും പ്രിന്റ് ചെയ്യുന്നു; /etc/resolv.conf ഒറ്റയ്ക്ക് സാധാരണയായി 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; റൗട്ടറിന്റെ വെബ് 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, റിസോൾവർ മൂല്യങ്ങൾ സൂക്ഷിക്കുക; അത്താഴ സമയത്ത് വീട്ടിലെ ഇന്റർനെറ്റ് തകർക്കുന്ന മാറ്റം ഒരു മിനിറ്റിൽ മടക്കാവുന്ന മാറ്റത്തേക്കാൾ ഡീബഗ് ചെയ്യാൻ ഏറെ ബുദ്ധിമുട്ടാണ്.