તમારી /etc/hosts એન્ટ્રી VPN ના DNS સુધી કેમ પહોંચતી નથી

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

Hosts એ સ્થાનિક ઓવરરાઇડ છે, ઝોન અપડેટ નથી

ફાઇલ એ મેપિંગની યાદી છે જે નામ-સેવા લાઇબ્રેરીઓ DNS સર્વરને પૂછવાના પહેલાં અથવા તેના બદલે જુએ છે. 10.40.0.20 build.corp.example જેવી લાઇન ફક્ત તે એક મશીન પરની એપ્લિકેશનો શું નિષ્કર્ષ કાઢે છે તે બદલે છે. તે રેકોર્ડ બનાવતી નથી, ટનલમાંથી પસાર થતી નથી, અને ટનલ જે DNS સર્વર તરફ ઇશારો કરે છે તેને તેના અસ્તિત્વની કોઈ ખબર નથી.

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

બે આદેશો, બે અલગ ઘટકો

આ ચર્ચા બંધ કરવાનો સૌથી ઝડપી રસ્તો એ છે કે તફાવતને બે આદેશોમાં દૃશ્યમાન બનાવવો, બંને hosts એન્ટ્રી ધરાવતા ક્લાઇન્ટ પર ચલાવવામાં આવે છે:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

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

ક્રમ ગોઠવી શકાય છે, અને કોઈ ચોક્કસ ડિસ્ટ્રિબ્યુશન વિશે નિષ્કર્ષ કાઢતા પહેલાં તે ચકાસવા યોગ્ય છે. /etc/nsswitch.conf માં hosts: લાઇન જુઓ; hosts: files dns પહેલાં ફાઇલો જુએ છે. ફક્ત ક્રમ બદલવા માટે તે ઉદાહરણને કાર્યરત કન્ફિગરેશન પર નકલ કરશો નહીં, કારણ કે વાસ્તવિક સિસ્ટમો ઘણી વાર વધારાના સ્રોતો અને શરતી સેવા એન્ટ્રીઓની યાદી આપે છે જે ઉદાહરણમાં નથી.

systemd-resolved પરીક્ષણને ધૂંધળું કરે છે

systemd-resolved વાપરતી સિસ્ટમમાં સ્થાનિક સ્ટબ hosts ડેટાબેઝમાંથી પણ નામો પરોવે છે. તેથી 127.0.0.53 ને ક્વેરી કરવી દૂરસ્થ સર્વરની સ્વતંત્ર પરીક્ષા નથી, જોકે તે DNS ક્વેરી જેવી લાગે છે અને એવી જ રીતે વર્તે છે. રિઝોલ્વર શું જાણે છે અને કયા સર્વરોને પૂછશે તે તમે આ રીતે ખાતરી કરી શકો છો:

resolvectl query build.corp.example
resolvectl status

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

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

VPN આખરે શું નામ વહેંચે છે

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

hosts ફાઇલોનું વિતરણ કરવું એ કાયદેસર વિકલ્પ છે, અને તે નામ-સેવા નહીં પરંતુ એન્ડપોઇન્ટ મેનેજમેન્ટ છે. જો તમે તે પસંદ કરો, તો ફાઇલ ફ્લીટનું સંચાલન કરતું હોય તેના દ્વારા ડિપ્લોય, વર્ઝન અને દૂર કરવી પડશે, અને ડિઝાઇનમાં એ જ રીતે વર્ણવવી જોઈએ. “VPN આ સંભાળે છે” એ તે પ્રક્રિયાનું વર્ણન નથી.

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

રિઝોલ્વ થયેલું નામ રૂટ નથી

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

તેથી જ્યારે અહેવાલ હોય કે “નામ રિઝોલ્વ થાય છે પણ સેવા પહોંચી શકાય તેવી નથી”, ત્યારે સિસ્ટમ લુકઅપને VPN DNS સર્વરની સ્પષ્ટ ક્વેરી સાથે સરખાવો, પછી તમને મળેલા સરનામાને સેવા ખરેખર જે વાપરે છે તેની સાથે તપાસો. systemd-resolved સંદર્ભ તે જે સ્થાનિક સ્રોતો જુએ છે તેનું દસ્તાવેજીકરણ કરે છે, અને તે સરખામણી માટે આ જ નકશો જરૂરી છે.

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