VPN હોસ્ટનામ નિષ્ફળ જાય છે, IP સરનામાં કામ કરે છે: ક્યાં જોવું

IP દ્વારા ઍક્સેસ કામ કરે છે જ્યારે નામ નિષ્ફળ જાય છે, જે રૂટ પર નહીં પરંતુ પ્રત્યય અને ઠેલાયેલા રિઝોલ્વર તરફ સંકેત કરે છે. સરનામું, FQDN, ટૂંકું નામ અને જૂનો માર્ગ પસાર કરો.

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

નામ એ પ્રશ્ન પૂછે છે જે સરનામું પૂછતું નથી

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

સરનામાથી બહાર તરફ કામ કરો: પહેલા પૂરું નામ, પછી નરી હોસ્ટનામ, અને ત્રણમાંથી કયું કામ કરે છે તે નોંધો. પેટર્ન તમને કહે છે કે એક પણ રૂપરેખાંકન સ્ક્રીન ખોલતા પહેલા કયું સ્તર તપાસવું. FQDN ઉકેલાય ત્યારે રૂટ વિશે અનુમાન કરવું વ્યર્થ શ્રમ છે.

ટનલે ખરેખર સ્થાપિત કરેલો રિઝોલ્વર વાંચો

ઓપરેટિંગ સિસ્ટમને પૂછો આંતરિક ઝોન માટેની ક્વેરી કયો રિઝોલ્વર સંભાળે છે, એ નહીં કે VPN ક્લાઇએન્ટનું ઇન્ટરફેસ કયો જાહેર કરે છે. જે સર્વર આંતરિક ઝોન વગર જાહેર રિઝોલ્વર ઠેલે છે તે બરાબર આ નિષ્ફળતા ઉત્પન્ન કરે છે, અને તે રૂટિંગ ખામી નહીં પણ રૂપરેખાંકન ભૂલ છે.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

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

Get-DnsClientNrptPolicy
ipconfig /all

જો આંતરિક ઝોન યોગ્ય સર્વર દ્વારા ઉકેલાય તો થોભો. રિઝોલ્વર તમારી સમસ્યા નથી.

પ્રત્યય નિષ્ફળ ટૂંકા નામ સમજાવે છે

ક્વેરી મોકલતા પહેલા એક-લેબલ નામ જોડાણની પ્રત્યય યાદી સાથે વિસ્તારવામાં આવે છે. જો VPN આંતરિક પ્રત્યય પહોંચાડે નહીં, તો fileserver ક્યારેય fileserver.corp.example બનતું નથી, અને ક્વેરી એવા નામ તરીકે નીકળે છે જે કોઈ જાહેર રિઝોલ્વર જાણતું નથી. પ્રત્યય ઠેલવો, અથવા પૂરું નામ લખવું, સર્વર પર કંઈ બદલ્યા વિના પરિકલ્પના ચકાસે છે.

nslookup fileserver.corp.example
ping -a 192.168.50.20

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

જો પ્રત્યય ઉમેરવાથી સુધરે, તો બાકીનું કામ દરેક વપરાશકર્તાને તે લખવા કહેવાને બદલે VPN પ્રોફાઇલ દ્વારા એ પ્રત્યય પહોંચાડવાનું છે.

NetBIOS અને WINS અલગ પ્રક્રિયા છે

જૂનું SMB હજી પણ NetBIOS નામ સેવા વડે નરી નામ શોધી શકે છે, જે બ્રૉડકાસ્ટ પર અથવા WINS સર્વર દ્વારા જવાબ આપે છે. બ્રૉડકાસ્ટ એક બ્રૉડકાસ્ટ ડોમેનની અંદર રહે છે અને પહેલા રાઉટર પર અટકે છે, તેથી ટનલ પાર કરી શકતું નથી; WINS કામ કરે છે કારણ કે ક્લાઇએન્ટ પાસે નોંધણી કરવા અને પૂછવા માટે યુનિકાસ્ટ સરનામું છે. તેથી ફક્ત IP વહન કરતું VPN પણ જૂનાં નામ ટેકો આપી શકે છે જ્યારે WINS રૂપરેખાંકિત અને પહોંચમાં હોય.

nbtstat -n
nbtstat -R

આધુનિક SMB માટે DNS અને પૂરા નામ પર આધાર રાખો, અને જૂનો માર્ગ નિવૃત્ત કરો. જો તે ખરેખર જૂનો હોય, તો WINS પૂરું પાડો અથવા ઍપ્લિકેશન બદલો; વચ્ચેનો માર્ગ એ સપોર્ટ કતાર છે જે ક્યારેય ખાલી થતી નથી.

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

સંબંધિત લેખો