MagicDNS ઉપકરણો ઉકેલે છે પણ ઓફિસ હોસ્ટનામો કેમ નહીં

MagicDNS tailnet ના દરેક ઉપકરણને તેના મશીન નામ અને tailnet ના DNS ડોમેન પરથી લીધેલું નામ આપે છે. એ નામ Tailscale બનાવે છે અને Tailscale ના રિઝોલ્વર માર્ગે તેનો જવાબ મળે છે. files.office.example જેવું ઓફિસ હોસ્ટનામ એ ઝોનનું છે જે Tailscale એ કદી લખ્યું નથી, તેથી ઉપકરણનું નામ બદલવાથી તે બની શકતું નથી. બંને નામાવકાશ સાથે અસ્તિત્વ ધરાવે છે; ફક્ત તેમના માલિક અલગ છે.

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

બે નામાવકાશ, બે માલિક

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

સબનેટ રાઉટરનું મશીન નામ બદલવાથી ઓફિસ ઝોન માટે કંઈ થતું નથી. તે એક Tailscale ઉપકરણનું નામ બદલે છે અને ઓફિસ સર્વર પરનો રેકોર્ડ અસ્પૃશ્ય રાખે છે, તેથી નામ બદલીને ફરી પ્રયાસ કરવો કદી પરિણામે પહોંચતો નથી.

ઓફિસ ઝોનને તેના રિઝોલ્વર તરફ દોરો

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

મર્યાદિત નામ સર્વર તેની સાથે જોડાયેલા ડોમેન માટે સત્તાવાર હોવું જોઈએ, નહીં તો જવાબ સરનામા પરત્વે સંદર્ભ હશે.

પહોંચ ઉકેલ પહેલાં આવે છે

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

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

નામની નિષ્ફળતાને સેવાની નિષ્ફળતાથી અલગ કરો

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

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

ઝોન, રિઝોલ્વરનું સરનામું અને ક્વેરી લઈ જતો રૂટ નોંધો. આ ત્રણ વધુ એક નામ બદલવાના રાઉન્ડ વિના મોટાભાગના MagicDNS આશ્ચર્ય સમજાવે છે.