શું VPN એ મારું DNS બદલ્યું? પહેલાં અને પછી સરખાવો
પ્રોફાઇલ તમારી લુકઅપને ઇરાદાપૂર્વક ખસેડી શકે છે. VPN કનેક્ટ થાય તે પહેલાં અને પછી રિઝોલ્વર નીતિ અને વાસ્તવિક જવાબની સરખામણી કરો, એક ચલ સ્થિર રાખીને.
તમે ટનલ કનેક્ટ કરો છો, ખાનગી ડેશબોર્ડ ખોલો છો, અને નામ એવા સરનામામાં ઉકેલાય છે જે તમે પહેલાં ક્યારેય જોયું નથી. અથવા ઊલટું થાય છે: બ્રાઉઝર કામ કરતું રહે છે જ્યારે કમાન્ડ-લાઇન સાધન અચાનક કંઈપણ ઉકેલતું નથી. બંને પરિણામ એક જ ફેરફારમાંથી આવે છે, અને લોકો સામાન્ય રીતે તેને VPN "પોતાનું DNS વાપરે છે" એવા એક વાક્યથી સમજાવે છે, જે ડિબગ કરવા કે ચકાસવા માટે પૂરતું સચોટ નથી. તે વાક્યમાં બે પ્રશ્નો છુપાયેલા છે: આ પ્રોફાઇલ કઈ લુકઅપ લેવાનું છે, અને તમારા મશીને ખરેખર તેને મળેલા રિઝોલ્વર પર મોકલી છે? તેમને અલગ રાખવું એ જ આખી પદ્ધતિ છે, કારણ કે જે પરીક્ષણ તેમને ભેગા કરે છે તે બંને દિશામાં આત્મવિશ્વાસપૂર્ણ ખોટો જવાબ આપે છે.
પ્રોફાઇલ કેમ રિઝોલ્વર આપે છે
ટનલની અંદર, દૂરના છેડા પાછળનાં નામ સામાન્ય રીતે એવાં સરનામાંમાં ઉકેલાય છે જે ફક્ત તે જ નેટવર્કમાં હોય છે. corp.internal જેવા ખાનગી ઝોનમાં જાહેર પ્રતિનિધિત્વ નથી, તેથી તેનો જવાબ આપતું રિઝોલ્વર ટનલની અંદરથી પહોંચી શકાય તેવું હોવું જોઈએ. એ જ મિકેનિઝમ બીજા હેતુ પણ પૂરો કરે છે: જ્યારે લુકઅપ અન્યથા તમારા ISP દ્વારા બહાર જાય, ત્યારે દૂરના છેડેનું રિઝોલ્વર ક્વેરીને એન્ક્રિપ્ટેડ માર્ગની અંદર રાખે છે. તેથી જ DNS સર્વરનું સરનામું કનેક્શનની નીતિના ભાગ રૂપે આવે છે, મશીન માટે એક વાર પસંદ કરેલી વૈશ્વિક સેટિંગ તરીકે નહીં.
સરનામું એકલું કંઈ નક્કી કરતું નથી. રિઝોલ્વર ત્યારે જ જવાબ આપી શકે છે જ્યારે ત્યાં સુધીનો માર્ગ હોય, અને સૌથી સામાન્ય નિષ્ફળતા એ છે કે રિઝોલ્વર ફક્ત ત્યારે જ પહોંચી શકાય જ્યારે ટનલ ચાલુ હોય. જ્યારે ટનલ પડી જાય અને નીતિ રહે, ત્યારે લુકઅપ માર્ગ વગરના સરનામે જાય છે, અને લક્ષણ સ્પષ્ટ ભૂલ નહીં પણ સમયસમાપ્તિ છે. તે તફાવત ત્યારે મહત્વનો છે જ્યારે તમે આગળનું પરીક્ષણ પરિણામ વાંચો છો, કારણ કે સમયસમાપ્તિ લોકોને એવી ટ્રાન્સપોર્ટ સેટિંગ્સમાં મોકલે છે જે ક્યારેય સંડોવાયેલી ન હતી.
જવાબોની સરખામણી પહેલાં બે ડિઝાઇનની સરખામણી કરો
સંપૂર્ણ ટનલ અને વિભાજિત DNS વિરોધી અપેક્ષાઓ ઉત્પન્ન કરે છે, અને બંનેય ખામી નથી. સંપૂર્ણ ટનલ હેઠળ દરેક લુકઅપ પ્રદાતા અથવા કોર્પોરેટ રિઝોલ્વર પર જઈ શકે છે, તેથી કનેક્ટ થયા પછી જાહેર નામો અલગ જવાબ આપે તે અપેક્ષિત છે. વિભાજિત DNS હેઠળ ફક્ત સૂચિબદ્ધ ડોમેન ખાનગી રિઝોલ્વર પર જાય છે જ્યારે બાકીનું બધું સ્થાનિક રહે છે; Windows માં ડોમેન યાદી Name Resolution Policy Table માં રહે છે, macOS માં DNS સેટિંગ્સના મેચ ડોમેનમાં, અને systemd-resolved હોસ્ટ પર લિંક-દીઠ રૂટિંગ ડોમેનમાં.
તે સરખામણી પહેલા કરવી જોઈએ, કારણ કે તે નક્કી કરે છે કે શું ખામી ગણાય. વિભાજિત DNS સાથે, નવા રિઝોલ્વરથી જવાબ આપતું જાહેર નામ તપાસવા લાયક છે, જ્યારે સાચી રીતે જવાબ આપતું આંતરિક નામ એ સિસ્ટમ પોતાનું કામ કરી રહી છે. સંપૂર્ણ ટનલ સાથે, અસામાન્યતા એ જાહેર નામ છે જે હજી પણ તમારા ISP રિઝોલ્વરથી જવાબ આપે છે. Microsoft નું VPN નામ ઉકેલ અંગેનું દસ્તાવેજીકરણ આ નિયમોનો Windows ક્રમ વર્ણવે છે, જેમાં એ પણ સમાવેશ છે કે મેળ ખાતી નીતિ એન્ટ્રી એડપ્ટરના પોતાના સર્વર પહેલાં કેવી રીતે જોવાય છે.
ઓરડામાં ત્રીજું રિઝોલ્વર પણ છે જે ભૂલવું સરળ છે. બ્રાઉઝરનું સુરક્ષિત DNS પોતે નામ ઉકેલે છે અને ટનલે ઓપરેટિંગ સિસ્ટમની નીતિ બદલ્યા પછી પણ જવાબ આપવાનું ચાલુ રાખી શકે છે, તેથી લોડ થતું પૃષ્ઠ સાબિત કરે છે કે બ્રાઉઝરનું રિઝોલ્વર કામ કર્યું, પ્રોફાઇલ લાગુ થયું તે નહીં. જો તમે ફક્ત બ્રાઉઝર જે દેખાડે છે તેની સરખામણી કરો, તો અડધા સમય તમે ખોટું સ્તર ચકાસી રહ્યા છો.
ફક્ત એક ચલ સાથે આધારરેખા નોંધો
ટનલ બદલો. એ જ પગલામાં નામ, સાધન કે શોધ પ્રત્યય પણ બદલશો નહીં. એવું નામ પસંદ કરો જેની પૂછપરછ કરવાની તમને પરવાનગી હોય, કઈ એપ્લિકેશન વાપરી તે નોંધો, અને ક્યાં તો પાછું આવેલું સરનામું અથવા ચોક્કસ ભૂલ લખો. Windows માં Get-DnsClientServerAddress -AddressFamily IPv4 દરેક એડપ્ટર માટેના સર્વર છાપે છે અને Get-DnsClientNrptPolicy નીતિ એન્ટ્રીઓ છાપે છે; systemd-resolved સાથે Linux માં resolvectl status લિંક-દીઠ DNS સર્વર અને રૂટિંગ ડોમેન દેખાડે છે; macOS માં scutil --dns સિસ્ટમ ખરેખર અનુસરશે તે રિઝોલ્વર ક્રમ છાપે છે.
પછી ક્લાયન્ટના સામાન્ય નિયંત્રણો દ્વારા કનેક્ટ કરો અને બરાબર એ જ આદેશોનું પુનરાવર્તન કરો. પહેલું આઉટપુટ યાદ રાખવાને બદલે સાચવો, કારણ કે સરખામણી એ જ આખો મુદ્દો છે અને કેશ સાફ કર્યા પછી લીધેલું બીજું વાંચન પહેલેથી જ બીજું માપ છે. જો આધારરેખા બ્રાઉઝર સામે રાખીને લેવાઈ હોય અને કનેક્શન પછીની કામગીરી ટર્મિનલમાં થાય, તો તમે બે રિઝોલ્વરની સરખામણી કરો છો, એક રિઝોલ્વરની બે સ્થિતિની નહીં.
સ્પષ્ટ ક્વેરી અને એપ્લિકેશન લુકઅપ અલગ પરીક્ષણો છે
એક ચોક્કસ સર્વરને પૂછવું, nslookup name 10.20.0.1 અથવા dig @10.20.0.1 name વડે, એક જ વાત સાબિત કરે છે: તમે જે સર્વરનું નામ આપ્યું તે ત્યારે જવાબ આપે છે જ્યારે તમે તેને પહોંચી શકો. તે પસંદગીની લોજિકને સંપૂર્ણપણે ટાળે છે, તેથી તે તમને કહી શકતું નથી કે સિસ્ટમ આ નામ માટે તે સર્વર પસંદ કરતી કે નહીં. તેનો ઉપયોગ સોંપાયેલ રિઝોલ્વર પહોંચવા યોગ્ય છે કે નહીં તે ચકાસવા કરો, અને નીતિ ચકાસવા તેનો ઉપયોગ ન કરો.
સ્થાનિક રિઝોલ્વર દ્વારા લુકઅપ ખરેખર પસંદગીનો ઉપયોગ કરે છે. resolvectl query name એ જ રૂટિંગ-ડોમેન નિયમો પર ચાલે છે અને જે પ્રોટોકોલે જવાબ આપ્યો તે જણાવે છે, Windows માં Resolve-DnsName નીતિ કોષ્ટક અને ક્લાયન્ટ કેશમાંથી પસાર થાય છે, અને scutil --dns લુકઅપ અનુસરશે તે ક્રમ દેખાડે છે. બંને પ્રકાર ચલાવો અને તેમને તમારી નોંધની અલગ કૉલમમાં રાખો. સફળ સ્પષ્ટ ક્વેરીની બાજુમાં નિષ્ફળ એપ્લિકેશન લુકઅપ એ રૂટિંગ કે પસંદગીની સમસ્યા છે, કામ કરવાનો ઇનકાર કરતું રિઝોલ્વર નહીં.
કેશ તમારી અને જવાબ વચ્ચે ઊભું રહે છે. ઓપરેટિંગ સિસ્ટમ, સ્થાનિક સ્ટબ રિઝોલ્વર, બ્રાઉઝર અને નકારાત્મક કેશ બધા પરિણામ રાખે છે, તેથી એક પણ પેકેટ મશીન છોડ્યા વિના લુકઅપ સફળ થઈ શકે છે. કંઈપણ સાફ કરતાં પહેલાં પરિણામ નોંધો: ipconfig /flushdns, resolvectl flush-caches અથવા macOS માં sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. આ તબક્કે વ્યાપક નેટવર્ક રીસેટ છોડી દો, કારણ કે તે તમે હજી એકઠા કરી રહ્યા છો તે પુરાવા નષ્ટ કરે છે.
તફાવતનો અર્થ શું છે
તમે નોંધેલી બે પંક્તિઓની સરખામણી કરો અને એક પણ સેટિંગને સ્પર્શ કરતાં પહેલાં ફેરફારનું વર્ગીકરણ કરો.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
એક પંક્તિ ખાસ ભારને લાયક છે. જે નામ ઉકેલાય છે તે કામ કરતી સેવા નથી, અને DNS ની સફળતા ફક્ત એટલું કહે છે કે સરનામું મળ્યું. તે ફોરવર્ડિંગ, ફાયરવોલ નિયમો કે તમારું ખાતું આ સેવા વાપરી શકે છે કે નહીં તે વિશે કંઈ કહેતું નથી, તેથી નિષ્ફળતા જાતે ખસી ગઈ એમ ધારવાને બદલે વાસ્તવિક એપ્લિકેશન ચકાસીને પૂરું કરો.
આધારરેખા પુનઃસ્થાપિત કરો અને ચકાસો
પ્રક્રિયા મારવાને બદલે ક્લાયન્ટના પોતાના નિયંત્રણો દ્વારા ડિસ્કનેક્ટ કરો, પછી એ જ ત્રણ આદેશો ફરી વાંચો. લિંક-દીઠ સર્વર, નીતિ એન્ટ્રીઓ અને તમારા પરીક્ષણ નામનો જવાબ પહેલાં લખેલી આધારરેખા પર પાછા આવવા જોઈએ. સ્વચ્છ ડિસ્કનેક્શન પછી બાકી રહેલી નીતિ એન્ટ્રી એ નોંધવા લાયક વાસ્તવિક ખામી છે, અને તેથી જ જનરેટ થયેલી રિઝોલ્વર ફાઇલમાં હાથે ફેરફાર કરવો ખરાબ આદત છે: ફાઇલ ફરી લખાય છે અને ફેરફાર અદૃશ્ય થાય છે, અથવા ફેરફાર ટકી રહે છે અને હવે માર્ગ ન હોય તેવા રિઝોલ્વરને પિન કરે છે.
આ યાદી એક વાર, ક્રમમાં કરો. કોઈપણ પરિણામનો નિર્ણય કરતાં પહેલાં પ્રોફાઇલ કઈ ડિઝાઇન લાગુ કરે છે તે નક્કી કરો. બંને રનમાં નામ, સાધન અને પ્રત્યય સ્થિર રાખો. સ્પષ્ટ ક્વેરીને એપ્લિકેશન લુકઅપથી અલગ રાખો. ફક્ત જવાબ નહીં, અસરકારક નીતિ વાંચો. સરખામણી લખાયા પછી કેશ છેલ્લે સાફ કરો. વાસ્તવિક એપ્લિકેશનથી ચકાસો, પછી એક વાર રીબૂટ કરો અને ખાતરી કરો કે ડિસ્કનેક્ટ થયેલી સ્થિતિ હજી સ્વચ્છ છે.