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 மற்றும் தீர்வி மதிப்புகளை வைத்திருக்கவும்; இரவு உணவின் போது வீட்டு இணையத்தை உடைக்கும் மாற்றத்தைப் பிழைத்திருத்துவது ஒரு நிமிடத்தில் திரும்பப் பெறக்கூடிய மாற்றத்தை விட மிகக் கடினம்.