VPN DNS ફિલ્ટર: નામ બ્લોક કરવાથી જાહેરાતો બ્લોક થતી નથી

એક જ dnsmasq લાઇન નામને NXDOMAIN સાથે જવાબ આપી શકે છે, અને આખી ક્રિયાવિધિ આટલી જ છે. તે ક્યારેય HTML વાંચતી નથી, વિનંતીનો માર્ગ તપાસતી નથી, અને એવું પણ જોતી નથી કે એપ્લિકેશન પહેલેથી ખોલેલા કનેક્શન સાથે શું કરે છે. તેથી તેની બ્રાઉઝર એક્સ્ટેન્શન સાથે સરખામણી કરવી એ બે જુદા કામોની સરખામણી છે. એક નક્કી કરે છે કે નામ ઉકેલાય છે કે નહીં; બીજું નક્કી કરે છે કે પછી શું થાય છે.

નામ ફિલ્ટર ખરેખર શું નિયંત્રિત કરે છે

છેલ્લા સ્લેશ પછી કંઈ ન હોય એવો address=/metrics.example/ વિકલ્પ રિઝોલ્વરને તે નામ અને તેના સબડોમેન માટે NXDOMAIN પરત કરવા મજબૂર કરે છે. સરનામું ખાલી રાખવું એ મહત્વનો ભાગ છે: તેનાથી ક્લાયન્ટને અસંબંધિત રિપ્લેસમેન્ટ સર્વર પર મોકલવાનું અથવા લૂપબેક સરનામાને સાચી ગંતવ્ય તરીકે દર્શાવવાનું ટળે છે. dnsmasq નું માર્ગદર્શિકા આ સ્વરૂપને રીડાયરેક્ટ નહીં, પણ નકારાત્મક જવાબ તરીકે વર્ણવે છે.

નિયમ જે કંઈ કરી શકે તે આ એક જ નિર્ણયમાંથી આવે છે. જે ક્લાયન્ટ આ રિઝોલ્વરને પૂછે છે તેને નકારાત્મક જવાબ મળે છે; જે ક્લાયન્ટ બીજા રિઝોલ્વરને પૂછે છે તેને તે રિઝોલ્વર જે કહે તે મળે છે. એપ્લિકેશન કયો માર્ગ, ક્વેરી સ્ટ્રિંગ કે એકાઉન્ટ વાપર્યું હોત તે ફિલ્ટર જાણતું નથી.

આ ઝીણવટ મહત્વની છે, કારણ કે એક હોસ્ટનામ ઘણી વાર ઘણા હેતુઓ પૂરા કરે છે. સાઇન-ઇન એન્ડપોઇન્ટ, ચિત્રો અને ટ્રેકિંગ એક ડોમેન વહેંચી શકે છે, અને આખું નામ દૂર કરતો નિયમ તેની સાથે કોઈ કાર્યપ્રવાહ પણ દૂર કરી શકે છે. નામ-સ્તરની નીતિએ આ સોદો સ્વીકારવો પડે અથવા વધુ સાંકડા નામ પસંદ કરવા પડે.

ક્લાયન્ટ-સાઇડ બ્લોકર ક્યાં અલગ પડે છે

બ્રાઉઝર એક્સ્ટેન્શન વિનંતી બહાર નીકળતા પહેલાં જુએ છે, તેથી તે URL માર્ગ સાથે મેળ કરી શકે, ચોક્કસ વિનંતી રદ કરી શકે અને પરિણામ દર્શાવતું તત્વ છુપાવી શકે. તે example.com/article ને મંજૂરી આપીને example.com/ads/ ને નકારી શકે, જે કોઈ DNS જવાબ વ્યક્ત કરી શકતો નથી. માર્ગ-સ્તરની આ દૃષ્ટિ એ જ ક્ષમતા છે જે રિઝોલ્વર પાસે જ નથી. એટલે જ એક સાધન માટે બનેલી ફિલ્ટર યાદી બીજામાં ભાગ્યે જ એકસરખી વર્તે છે.

કિંમત વ્યાપ છે. એ રક્ષણ એક બ્રાઉઝરમાં, એક પ્રોફાઇલમાં, એક ઉપકરણ પર રહે છે, અને વપરાશકર્તા બીજી એપ્લિકેશન પર જાય ત્યારે અદૃશ્ય થાય છે. ગેટવે પર ગોઠવાયેલ DNS ફિલ્ટર ગેટવેના રિઝોલ્વરનો ઉપયોગ કરતા દરેક ઉપકરણને આવરી લે છે, જેમાં એવા ઉપકરણો પણ આવે છે જ્યાં કોઈ એક્સ્ટેન્શન સ્થાપિત કરી શકાતું નથી.

બંનેમાંથી એક પણ એકલું પૂર્ણ નથી. DNS ફિલ્ટર પૃષ્ઠ પહેલેથી મોકલી ચૂકેલું ઓળખકર્તા દૂર કરી શકતું નથી, અને બ્રાઉઝર એક્સ્ટેન્શન એવી એપ્લિકેશનને સુરક્ષિત કરી શકતું નથી જે તેને ક્યારેય લોડ કરતી નથી.

રિઝોલ્વરનો માર્ગ નક્કી કરે છે કે આમાંથી કંઈ લાગુ પડે છે કે નહીં

VPN DNS સર્વરની જાહેરાત કરીને પણ દરેક ક્વેરી ન મેળવી શકે. એન્ક્રિપ્ટેડ DNS ગોઠવેલું બ્રાઉઝર, પોતાનું રિઝોલ્વર ધરાવતી એપ્લિકેશન, અથવા ગેટવેને બાકાત રાખતા નેટવર્ક માર્ગ પરનું ઉપકરણ—બધા બીજે જ જોશે. મોબાઇલ પ્લેટફોર્મ વધુ ને વધુ ખાનગી-DNS સેટિંગ આપે છે જે ટનલ સૂચવે છે તેને શાંતિથી બાજુ પર કરે છે.

તેથી નીતિ નહીં, માર્ગ ચકાસો. ગેટવેથી સીધા ઇચ્છિત રિઝોલ્વરને પૂછો, પછી ક્લાયન્ટથી પૂછો અને તુલના કરો, અને પછી જુઓ કે બ્લોક થવું જોઈએ એવું નામ વપરાશકર્તા ચલાવતી એપ્લિકેશનમાં ખરેખર નિષ્ફળ જાય છે કે નહીં.

કેશ કરેલા જવાબો અને ખુલ્લા સોકેટ આને ઘોંઘાટભર્યું બનાવે છે. જે પૃષ્ઠ તેના સ્રોત પહેલેથી લોડ કરી ચૂક્યું છે તે નિયમ બદલાયા પછી પણ કામ ચાલુ રાખશે, તેથી જૂની ટૅબ ફરી લોડ કરવા કરતાં નવું કનેક્શન સારી કસોટી છે.

પરિણામ જાહેર કરતા પહેલાં બંને દિશા ચકાસો

ઇરાદાપૂર્વક બ્લોક કરેલું દસ્તાવેજી નામ, મંજૂર જાહેર નામ અને સેવાને જરૂરી ખાનગી નામ વાપરો:

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

બ્લોક કરેલા નામ માટે ખાલી જવાબ, જાહેર નામ માટે સામાન્ય સરનામું અને આંતરિક નામ માટે ખાનગી સરનામું—સાથે મળીને દર્શાવે છે કે ફિલ્ટરિંગ, અપસ્ટ્રીમ રિઝોલ્યુશન અને સ્થાનિક રેકોર્ડ બધા કામ કરે છે. જો ત્રણેય નિષ્ફળ જાય, તો તમે ફિલ્ટર નહીં, અપસ્ટ્રીમ કે લિસનરની સમસ્યા જોઈ રહ્યા છો.

તમે આંતરિક રીતે પ્રકાશિત કરો તે દરેક વસ્તુમાં દાવાને સાંકડો રાખો. આ રિઝોલ્વર પર ડોમેન ફિલ્ટરિંગ છે, સામગ્રી નિરીક્ષણ નહીં, માર્ગ ફિલ્ટરિંગ નહીં, અને કોઈ ટ્રેક નથી થતું એવું વચન પણ નહીં. નીતિનો માલિક, અપવાદનો માર્ગ અને ક્વેરી રાખવાનો સમયગાળો નિયમોની બાજુમાં જણાવો, કારણ કે દરેક શોધ લોગ કરતા ફિલ્ટરનો પોતાનો ગોપનીયતા ખર્ચ છે.