Pi-hole VPN જોડાયા પછી જાહેરાતો બ્લોક કરતું નથી: પાંચ તપાસ

એક ક્લાયન્ટ પર હજી જાહેરાતો દેખાય છે, 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 અને રિઝોલ્વર મૂલ્યો રાખો; રાત્રિભોજન વખતે ઘરનું ઇન્ટરનેટ તોડી નાખતા ફેરફારને ડિબગ કરવો એક મિનિટમાં પાછો ફેરવી શકાય એવા ફેરફાર કરતાં ઘણો અઘરો છે.