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

તમે શું બદલ્યું, અને ખરેખર શું નક્કી કરે છે

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

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

ટેબલ નામ કેવી રીતે મેળવે છે

નિયમો નેમસ્પેસ પ્રમાણે કી થયેલા છે, અને સૌથી ચોક્કસ મેળ જીતે છે. corp.example માટેનો નિયમ vpn.corp.example પર લાગુ પડે છે અને example.net પર લાગુ પડતો નથી. . નેમસ્પેસવાળો નિયમ બીજા નિયમો ન ઢાંકે તે બધું ઢાંકે છે, જે તેને યાદીની સૌથી જોખમી એન્ટ્રી બનાવે છે અને જ્યારે અસંબંધિત સાઇટ ટનલ દ્વારા ઉકેલાય ત્યારે તપાસવા જેવી એન્ટ્રી પણ.

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

ઇચ્છાની યાદી નહીં, અસરકારક ટેબલ વાંચો

કન્ફિગર કરેલા નિયમો અને અસરકારક નિયમો બે અલગ પ્રશ્નો છે. Get-DnsClientNrptRule મશીન પર શું છે તેની યાદી આપે છે. Get-DnsClientNrptPolicy -Effective ક્લાયન્ટ ખરેખર શું લાગુ કરશે તે બતાવે છે, નીતિ અને સ્થાનિક સેટિંગ્સમાંથી મળીને બનેલા મૂલ્યો સાથે.

તે આઉટપુટમાંનું સફિક્સ તમે પરીક્ષણ કરી રહ્યા છો તે નામ સાથે અક્ષરે અક્ષર સરખાવો. corp.example માટેનો નિયમ corp.example.com થી અંત આવતું નામ પકડતો નથી, અને એક જગ્યાએ અંતમાં બિંદુ હોવું અને બીજી જગ્યાએ ન હોવું મેળ બદલવા માટે પૂરતું છે.

નિયમ વિના, Windows એક કરતાં વધુ એડેપ્ટરને પૂછે છે

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

બે રસ્તા છે. નિર્ણય સ્પર્ધા રહે નહીં તે માટે નેમસ્પેસ માટે નિયમ ઉમેરો, અથવા DNS ક્લાયન્ટ નીતિ દ્વારા સમાંતર વર્તન બંધ કરો અને ધીમું પણ નિશ્ચિત ઉકેલન સ્વીકારો. પ્રથમ સામાન્ય રીતે સ્પ્લિટ-ટનલ VPN માટે વધુ યોગ્ય છે, કારણ કે તે ક્રમ પર આધાર રાખવાને બદલે ઉદ્દેશ દસ્તાવેજ કરે છે.

રિઝોલ્વરને સંપૂર્ણ છોડી દેતા રસ્તા

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

એ પણ તપાસો કે એપ પહેલાના સેશનના કેશ કરેલા સરનામે કનેક્ટ થાય છે કે નહીં. Clear-DnsClientCache અને પછી એ જ લુકઅપ જૂના પરિણામ પરથી અનુમાન કરવા કરતાં વધુ સ્વચ્છ જવાબ આપે છે.

જે નામ નિષ્ફળ ગયું તેનાથી પરીક્ષણ કરો

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

જો નામ ઉકેલાય અને સેવા હજી પણ ના પાડે, તો DNS સંપાદિત કરવાનું બંધ કરો. આગળનું ઉપયોગી પગલું સરનામું અને ત્યાં સુધીનો રસ્તો છે, કારણ કે નામ ઉકેલવાનું કામ પહેલેથી પૂરું થઈ ગયું છે.

સંબંધિત લેખો