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

શોધને ખરેખર શું જોઈએ

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

ક્લાયન્ટ પોતાનું રિઝોલ્વર VPN પ્રોફાઇલમાંથી, ટનલ પરના DHCPમાંથી અથવા પોતાના રૂપરેખાંકનમાંથી શીખે છે, અને કયો સ્રોત જીતશે તે પ્લેટફોર્મ પર આધાર રાખે છે. Windows પર, ipconfig /all દરેક એડેપ્ટર માટે DNS સર્વર દર્શાવે છે, તેથી તમે જોઈ શકો કે મોકલેલું મૂલ્ય ખરેખર પહોંચ્યું છે કે નહીં. જે મૂલ્ય ક્યારેય ઓપરેટિંગ સિસ્ટમ સુધી પહોંચ્યું નથી તે શાંત અને સામાન્ય નિષ્ફળતા છે. પ્રોફાઇલને સ્પર્શ કરતાં પહેલાં ગોઠવેલું મૂલ્ય વાંચો.

Linux અને macOS એ જ પ્રશ્નનો જુદા આદેશોથી જવાબ આપે છે, અને જવાબ એ જ રીતે વાંચવા લાયક છે: resolvectl status અને scutil --dns બંને દરેક ઇન્ટરફેસ માટે સર્વરની યાદી આપે છે. તે યાદીને પ્રોફાઇલ જે સરનામું મોકલવાનો દાવો કરે છે તેની સાથે સરખાવો. અહીંની અસંગતિ નીચેનું બધું સમજાવે છે, તેથી નામ ચકાસતાં પહેલાં તેને નક્કી કરો.

એક જાહેર અને એક ખાનગી નામ ચકાસો

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

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

nslookup જે સર્વરને પૂછ્યું તે અને જે જવાબ મળ્યો તે બંને દર્શાવે છે, અને તે જ તમને જોઈતી જોડી છે. તેને એ જ શેલમાં બે વાર ચલાવો અને દરેક જવાબની બાજુમાં જવાબ આપનારું સરનામું લખો.

nslookup example.com
nslookup host.corp.example 10.20.30.53

ક્લાયન્ટ ખરેખર તે સર્વર સુધી પહોંચી શકે છે તેની ખાતરી કરો

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

દરેક પ્લેટફોર્મ તેનો જવાબ એક લીટીમાં આપે છે, અને આઉટપુટમાં દર્શાવેલું ઇન્ટરફેસ આખો જવાબ છે. જો તે ભૌતિક એડેપ્ટર તરફ ઇશારો કરે જ્યારે રિઝોલ્વર ટનલ પાછળ હોય, તો પ્રોફાઇલ એવું પ્રીફિક્સ મોકલતું નથી જે તેને આવરી લે.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

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

યાદ રાખો કે બ્રાઉઝર સિસ્ટમ રિઝોલ્વરને ટાળી શકે છે

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

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

કૅશ ખાલી કરો અને અસલી કાર્ય ફરી ચકાસો

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

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

પછી કૃત્રિમ શોધને બદલે મૂળ કાર્યનું પુનરાવર્તન કરો, કારણ કે કાર્ય એ છે જે વપરાશકર્તાને મહત્ત્વનું છે. એક વાર ફરી જોડાઓ પણ જેથી પુનઃચકાસણી એ સ્થિતિને આવરી લે જેમાં વપરાશકર્તા ખરેખર હશે. Microsoftનું nslookup સંદર્ભ પ્રશ્નના આર્ગ્યુમેન્ટ માટે રાખવા જેવું પૃષ્ઠ છે.

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

સંબંધિત લેખો