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 සහ විසඳුම්කරු අගයන් රඳවා ගන්න; රාත්‍රී ආහාරයේදී ගෘහස්ථ අන්තර්ජාලය කැඩෙන වෙනසක් විනාඩියකින් ආපසු හැරවිය හැකි වෙනසකට වඩා නිදොස් කිරීම බෙහෙවින් අපහසු ය.