ડાયલ-ઇન પછી સર્વરનું નામ તેના VPN સરનામામાં કેમ રિઝોલ્વ થાય છે

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

બે સરનામાં, એક નામ, ત્રણ શરતો

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

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

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

રજિસ્ટ્રાર બદલતા પહેલા રેકોર્ડ વાંચો

સમસ્યા જણાવતા નેટવર્કથી ચોક્કસ સંપૂર્ણ લાયક નામ પૂછો અને જવાબોને સર્વરના વાસ્તવિક ઇન્ટરફેસ અને શ્રોતાઓ સાથે સરખાવો. એક નામ ઘણાં સરનામાં પરત કરે તે સામાન્ય છે; પ્રશ્ન એ છે કે દરેક સરનામું તેને મેળવતા ક્લાયન્ટ માટે વાપરી શકાય તેવું છે.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

પ્રથમ ક્વેરી સ્થાનિક રિઝોલ્વર વાપરે છે, બીજી સીધી ચોક્કસ DNS સર્વરને પૂછે છે, અને ત્રીજી Windows પર PowerShell થી એ જ કરે છે. તેમની તુલના જૂની ક્લાયન્ટ કેશને સત્તાવાર જવાબથી અલગ કરે છે. જો સીધી ક્વેરી પહેલેથી ટનલ સરનામું પરત કરે, તો સમસ્યા પ્રકાશિત ડેટામાં છે, સ્થાનિક કેશિંગમાં નહીં.

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

પ્રકાશક સુધારો કે રેકોર્ડ, પણ કયું તે જાણો

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

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

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

જે ક્લાયન્ટ નેટવર્ક નિષ્ફળ ગયું તેમાંથી ચકાસો

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

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

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

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