VPN DNS કામ કરે છે, પણ .local નામો હજી પણ નિષ્ફળ જાય છે: તેમને કોણ ઉકેલે છે?

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

બે રિઝોલ્વર, બે અલગ જવાબો

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

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

કયા આદેશે ખરેખર તમારા રિઝોલ્વરને પૂછ્યું

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

કેમ .local તમારા unicast ઝોનને છોડી જાય છે

systemd-resolved નો સંદર્ભ કહે છે કે .local થી અંત થતા બહુ-લેબલ નામો, mDNS સક્ષમ હોય ત્યારે સામાન્ય unicast DNS ને બદલે સામાન્ય રીતે multicast DNS પર જાય છે. RFC 6762 તે નામ જગ્યાને link-local multicast માટે અલગ રાખે છે, તેથી કોર્પોરેટ ઝોન સાચો રેકોર્ડ રાખી શકે છે જે તે સફિક્સ માટે કદી પૂછવામાં આવતો નથી. ટનલ રિઝોલ્વરને સંપૂર્ણ રીતે રૂટ કરી શકે અને તો પણ રેસ હારી શકે. કેશમાંથી સફળ ping હમણાં જ થયેલી શોધ વિશે કંઈ કહેતું નથી.

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

સાંકડો અપવાદ વૈશ્વિક પુનર્ગઠનને હરાવે છે

તમે નામ બદલી શકતા નથી તેવા હાલના ઝોન માટે, રિઝોલ્વર અને VPN માલિકોને તે ડોમેન તેનું વહન કરતા કનેક્શન પર જાહેર કરવા કહો. તે એક સફિક્સ માટે રાઉટિંગ-ડોમેન એન્ટ્રી ઉપરાંત ઇચ્છિત સર્વર સરનામું એ નામવાળા માલિક સાથેનો નાનો ફેરફાર છે, અને તે હાથે સંપાદિત ફાઇલમાં નહીં, લિંક સાથે જીવે છે.

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

ફેરફાર પછી શું સાબિત કરવું

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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